Project

General

Profile

Task #1662

RIB dataset publisher

Added by Alex Afanasyev over 7 years ago. Updated over 7 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 datasetClosedChengyu Fan

Actions
Blocked by NFD - Task #1684: RIB enumeration protocolClosedJunxiao Shi

Actions
Blocks NFD - Task #1717: Route expiration test scenarioClosedVince Lehman

Actions
Blocked by ndn-cxx - Task #1764: Add RibEntry and Route data structuresClosedVince Lehman

Actions
#1

Updated by Vince Lehman over 7 years ago

  • Assignee set to Vince Lehman
#2

Updated by Junxiao Shi over 7 years ago

  • Blocked by Task #1684: RIB enumeration protocol added
#3

Updated by Junxiao Shi over 7 years ago

  • Blocks Task #1717: Route expiration test scenario added
#4

Updated by Junxiao Shi over 7 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 over 7 years ago

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

Updated by Vince Lehman over 7 years ago

  • Status changed from New to In Progress
#7

Updated by Chengyu Fan over 7 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 over 7 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 over 7 years ago

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

Updated by Vince Lehman over 7 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 over 7 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 over 7 years ago

I agree with proposal in note-11.

#13

Updated by Anonymous over 7 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 over 7 years ago

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

#15

Updated by Anonymous over 7 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 over 7 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 over 7 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 over 7 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 over 7 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 over 7 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 over 7 years ago

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

#22

Updated by Vince Lehman over 7 years ago

  • % Done changed from 80 to 90
#23

Updated by Vince Lehman over 7 years ago

  • Status changed from In Progress to Code review
#24

Updated by Vince Lehman over 7 years ago

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

Also available in: Atom PDF