Project

General

Profile

Task #2370

Implement emulation of ndn-cxx `ndn::Face`

Added by Alex Afanasyev almost 5 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
apps
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Related issues

Blocks ndnSIM - Task #3119: Add (at least partial) unit-test coverage for ndn-cxx FaceClosed2015-08-20

History

#1 Updated by Junxiao Shi over 4 years ago

Connecting a nfd::Face to a ndn::util::DummyClientFace is easy.
Example: topology-tester TopologyAppLink

I'm attempting something similar in my experiments.
I feel the difficult part is:

ndn::Face is designed to be asynchronous and requires io_service, but ns-3 doesn't run io_service as its main loop.

One solution is to invoke face.processEvents(time::milliseconds(-1)) after every operation (including but not limited to expressInterest put setInterestFilter), which requires extensive changes in applications.

Another solution is to use a global io_service, and schedule a periodical event in ns-3 to poll it; but the frequency of polling would be a trade-off between accuracy and wallclock performance.

#2 Updated by Anil Jangam over 4 years ago

In attempt to understand this, I did some investigations. Below are my questions and findings:

  • In a real NLSR deployment, each host (router) running NLSR runs its NFD instance. Faces are managed by the application and network admin (nfdc command I mean).

    • In ndnSIM setup, does every node has its simulated NFD instance or the entire simulator has just one for all nodes in the simulation setup? I presume ndnSIM contains just has one instance of simulated NFD.
  • Interest messages are dispatched to the application and to NFDs depending on the registered prefixes in the FIB by application and by the forwarder.

    • We need an equivalent of the above in NFD in ndnSIM and IMO it need not be asynchronous in nature unlike in real NFD case, correct?
    • As per an update in redmine task #2370, do we really need to monitor the activity on face in simulated NFD? Can't it just dispatch the Interest messages just looking at the registered prefix?
    • This dispatched Interest event then eventually be handled in ndnSIM's event handler.
    • I might be oversimplifying this. Please provide your comments.
  • In 2.0 version, when we are creating the links between the nodes, does it actually creates the faces on NFD?

  • In NLSR code, face management is done by util::FaceController. This is the class takes care of creating and destroying the faces.

    • In ndnSIM NFD, IMO, there is an equivalent class called FaceManager. This internally uses the ProtocolFactory to createFace. However, I did not find any destroyFace API.
    • Please comment if FaceManager is the class we need to enhance to support the handling of Interest messages in ndnSIM.
    • Please comment on when NLSR application in ndnSIM registers any prefix, will it be handled by FaceManager and registered into the FIB of simulated NFD.
    • As mentioned above, please comment if faces created by creating links between the nodes (based topology) are also handled by the FaceManager.

I am not sure how much time this ndnSIM face implementation would take. If there is a workaround to this, I can proceed with the further testing of nlsrsim.

Let me know your feedback.

#3 Updated by Anil Jangam over 4 years ago

Did some further fact finding.. Here are my observations.

  • In helper/ndn-stack-helper.cpp, I see that the NDN stack (L3Protocol) is installed on each NDN node.
  • In the same helper class, I see that all the faces are added to the FaceContainer.
  • In the same helper class, I see a FibManager, which belongs to the NFD package in the simulator. This is used to register the name prefix in the FIB and associate the face to handle the Interest/Data packet.

Is there any relationship between the faces in the FaceContainer and that of faces to be created on NFD? If I am correct, the FaceContainer contains the faces between the application and NFD. And the links between the nodes are the faces connecting the nodes.

Do we have to write a FaceManager (similar to the FibManager) for the management of the faces on the NFD. This will then replace the Link based logic connecting the nodes. Kindly please comment.

#4 Updated by Spyros Mastorakis about 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Spyros Mastorakis

#5 Updated by Spyros Mastorakis about 4 years ago

  • % Done changed from 0 to 40

#6 Updated by Spyros Mastorakis about 4 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 40 to 90

@Alex, it works now. I will push the updated code soon to the repo. Could you please take a look and let me know if you like the structure? Instead of deleting what I think we do not need in ndn-cxx Face, I have commented the lines out.

#7 Updated by Alex Afanasyev about 4 years ago

  • Blocks Task #3119: Add (at least partial) unit-test coverage for ndn-cxx Face added

#8 Updated by Alex Afanasyev about 4 years ago

  • Status changed from Feedback to Code review
  • % Done changed from 90 to 100

#9 Updated by Alex Afanasyev about 4 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF