Task #1942
closed
NextHopFaceId test scenario
Added by Junxiao Shi about 10 years ago.
Updated almost 8 years ago.
Category:
Integration Tests
Description
Develop an IntegrationTests scenario to test NDNLPv2 NextHopFaceId field.
Topology:
B--A--C
Procedure:
- start NFD on A,B,C
- on A, create a route for prefix
ndn:/P toward B and C, where the cost toward B is lower than the cost toward C
- on B, start traffic generator producer on
ndn:/P prefix, serving payload "BBBBBBBB"
- on C, start traffic generator producer on
ndn:/P prefix, serving payload "CCCCCCCC"
- on A, execute a consumer to enable NextHopFaceId feature and then express an Interest for
ndn:/P/1 without NextHopFaceId tag, expect Data with payload "BBBBBBBB"
- on A, execute a consumer to enable NextHopFaceId feature and then express an Interest for
ndn:/P/2 tagged NextHopFaceId=faceB, expect Data with payload "BBBBBBBB"
- on A, execute a consumer to enable NextHopFaceId feature and then express an Interest for
ndn:/P/3 tagged NextHopFaceId=faceC, expect Data with payload "CCCCCCCC"
- on A, execute a consumer to enable NextHopFaceId feature and then express an Interest for
ndn:/P/4 tagged NextHopFaceId=null-face, expect either a timeout or a Nack
- on A, execute a consumer to disable NextHopFaceId feature and then express an Interest for
ndn:/P/5 tagged NextHopFaceId=faceC, expect either a timeout or Data with payload "BBBBBBBB"
Files
- Description updated (diff)
- Assignee set to Junxiao Shi
I'll write the design.
After that, this Task needs reassigned for implementation.
- Description updated (diff)
- Assignee deleted (
Junxiao Shi)
- Target version changed from v0.3 to v0.5
- Assignee set to Eric Newberry
- Status changed from New to In Progress
I believe this task may require modifications to ndn-traffic-generator to allow the client to attach local fields to the Interests. Otherwise, I can't think of a way to tag NextHopFaceId.
Should I create a new issue to reference on the ndn-traffic-generator Github page for the patch?
Answer to note-7:
You MAY do that.
I'm still working on this task, but further progress has been delayed until I complete #3074.
I believe this task will also require Nack processing in ndn-traffic-generator. I'll work on a patch for that.
It seems that the local fields must be enabled on each connection through a separate management Interest sent before the Interest containing (or not containing) NextHopFaceId. Therefore, ndnping, ndnpeek, and ndn-traffic-generator don't seem to fit this use case.
My current plan is to write a simple consumer in either C++ (compiling it with the integration test suite) or Python (requiring the addition of PyNDN to the integration testing environment). Any thoughts on this or any other suggestions?
Reply to note-11:
A consumer using ndn-cxx is better than additional PyNDN dependency, because PyNDN code has not been reviewed by NFD developers.
I am currently waiting on the refactoring of local fields in NFD management to be completed before making further progress on this task.
- Blocked by Feature #3731: FaceManager commands: LocalFieldsEnabled added
I am currently waiting on the refactoring of local fields in NFD management to be completed before making further progress on this task.
Agreed. #3731 changes how "enable NextHopFaceId feature" is performed, and will affect the consumer program in this issue.
- Subject changed from ClientControlStrategy test scenario to NextHopFaceId test scenario
- Description updated (diff)
ClientControlStrategy is deprecated in #3783, and NextHopFaceId field is honored universally. Thus, setting strategy step is deleted.
I have recently resumed work on this task.
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by