Project

General

Profile

Task #1662

RIB dataset publisher

Added by Alex Afanasyev over 5 years ago. Updated about 5 years ago.

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

100%

Estimated time:
3.00 h

Description

Develop a publisher of RIB dataset.


Related issues

Related to NFD - Task #1749: nfd-status: RIB datasetClosed

Blocked by NFD - Task #1684: RIB enumeration protocolClosed

Blocks NFD - Task #1717: Route expiration test scenarioClosed

Blocked by ndn-cxx - Task #1764: Add RibEntry and Route data structuresClosed

History

#1 Updated by Vince Lehman over 5 years ago

  • Assignee set to Vince Lehman

#2 Updated by Junxiao Shi about 5 years ago

  • Blocked by Task #1684: RIB enumeration protocol added

#3 Updated by Junxiao Shi about 5 years ago

  • Blocks Task #1717: Route expiration test scenario added

#4 Updated by Junxiao Shi about 5 years ago

  • Subject changed from Listing content of RIB to RIB dataset publisher
  • Description updated (diff)
  • Estimated time set to 3.00 h

#5 Updated by Junxiao Shi about 5 years ago

  • Related to Task #1749: nfd-status: RIB dataset added

#6 Updated by Vince Lehman about 5 years ago

  • Status changed from New to In Progress

#7 Updated by Chengyu Fan about 5 years ago

Vince, have you implemented the RibEntry data structures? If so, could you give me a pointer to it?

BTW, probably the implementation of RibEntry data structure should be a separate task, so that tasks #1749 and #1662 can proceed in parallel?

#8 Updated by Vince Lehman about 5 years ago

Yes, I am currently implementing the RibEntry data structure in ndn-cxx. I will create a new task for the implementation.

#9 Updated by Vince Lehman about 5 years ago

  • Blocked by Task #1764: Add RibEntry and Route data structures added

#10 Updated by Vince Lehman about 5 years ago

  • % Done changed from 0 to 80

Since RibManager uses an ndn::Face and a SegmentPublisher expects a pointer to an AppFace, will I need to write a wrapper class for ndn::Face which implements AppFace or is there an easier way?

#11 Updated by Alex Afanasyev about 5 years ago

As of right now, you will not be able to use segment publisher at all (since it is part of daemon/).

One option is to move it to core/ and make templated, so it can be used with AppFace (in NFD internally) and anywhere else with ndn::Face. Junxiao, does this sound reasonable or we should do something else?

#12 Updated by Junxiao Shi about 5 years ago

I agree with proposal in note-11.

#13 Updated by Anonymous about 5 years ago

No objection to moving SegmentPublisher to core, but it relies on AppFace because SegmentPublisher::publishSegment calls AppFace::sign (only AppFaces have an associated keychain). If you want it to use a generic Face, then you will need provide the keychain some other way.

#14 Updated by Alex Afanasyev about 5 years ago

What if we make KeyChain global? Like we do with scheduler and io_service?

#15 Updated by Anonymous about 5 years ago

That may be an option. I think the current implementation was part of the effort to avoid global things to help future porting to ndnsim. Just keep in mind that some management things will also need corresponding tweaks:

  • ManagerBase::sendResponse (2 args)
  • StatusServer::onInterest
  • NotificationStream::postNotification (should this also be moved to core?)

#16 Updated by Alex Afanasyev about 5 years ago

Alternative is to explicitly provide KeyChain in constructors of all managers (technically, there should be one KeyChain in the application) and streams... This seems to be much more intrusive change and not sure how much beneficial...

#17 Updated by Anonymous about 5 years ago

Agreed. I don't have any objections to making the keychain global like the scheduler and io service. My intention in #15 was to mention the original design choice.

#18 Updated by Junxiao Shi about 5 years ago

I disagree with having a global KeyChain.
I also withdraw the agreement with note-11.
It's okay to have a global Scheduler, because it deals with relative time only, which is same across nodes (unless we model hardware clock drift which is generally invisible).
It's unacceptable to have a global key chain, because the possession of keys on different nodes are different.

To use SegmentPublisher with both AppFace and ndn::Face:

  1. rename AppFace to AppFaceBase, abstract sending and receiving to InternalFace; AppFaceBase constructor takes a KeyChain, and can sign Data with the KeyChain (or simply has a getKeyChain method
  2. change SegmentPublisher to take AppFaceBase
  3. create a new AppFace class which derives from AppFaceBase; its constructor takes ndn::Face and KeyChain, and passes the KeyChain to base class constructor, but uses the ndn::Face for sending and receiving

#19 Updated by Junxiao Shi about 5 years ago

20140716 conference call decides that nfd::AppFace shouldn't own a KeyChain.
Instead, a KeyChain is created in main.cpp and passed to managers.

This makes note-11 feasible without adding a global KeyChain.

#20 Updated by Lan Wang about 5 years ago

Which task corresponds to these changes in Note #19? Vince is willing to work on it if no one is assigned to work on that.

#21 Updated by Junxiao Shi about 5 years ago

Changes in note-19 could be completed as part of this Task.

#22 Updated by Vince Lehman about 5 years ago

  • % Done changed from 80 to 90

#23 Updated by Vince Lehman about 5 years ago

  • Status changed from In Progress to Code review

#24 Updated by Vince Lehman about 5 years ago

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

Also available in: Atom PDF