NFD

Eliminate double-dispatch describes the design intention of NFD Management system, which can achieve the first three goals.

Since basic mechanisms are increasingly reused in other projects, and some are available from the library, it's also desirable to make the underlying Face compatible with both nfd::Face and ndn::Face, so that code can be reused.

I'll present the basic idea sometime later.

@Steve, don't rush on implementation.

There are design issues to solve: goal 4 is incompatible with the design in Eliminate double-dispatch.

I have a lot of other things going on right now (especially with the run up to the retreat). I do not plan to resume work on this task until after the retreat.

I would prefer to refactor the unit tests as a separate task with a later version target (a v0.3 minor release?) so that I can get through the other v0.3 management tasks. I haven't had a chance to look over the tasks and no refactoring plan has been proposed.

I would prefer to refactor the unit tests as a separate task with a later version target (a v0.3 minor release?) so that I can get through the other v0.3 management tasks. I haven't had a chance to look over the tasks and no refactoring plan has been proposed.

Refactoring management system involves changes to class interfaces, which inevitably requires changes to unit tests. Therefore, unit testing refactoring has to be in this Task as well.

I will take more care on test cases in code reviews.
Test cases must be well designed, and code duplication should be avoided.

What's the recommended way to test sending Interests and receiving Data in ndn-cxx? Specifically, I want to test ManagementDispatcher::addControlCommand and making sure the handler gets called.

I'm looking at DummyClientFace, but I don't think it does what I want.

DummyClientFace will do everything what you need. You can emulate reception of external interests/data using DummyClientFace::receive methods.

For simple example, you can check https://github.com/named-data/ndn-cxx/blob/master/tests/unit-tests/test-face.cpp.

For complex example, check https://github.com/named-data/NFD/blob/master/tests/daemon/fw/topology-tester.hpp

I've looked over the examples, but I'm still stuck. For example, the dispatcher needs to call Face.setInterestFilter to register prefixes. However, I think this needs the io service to run for a bit, otherwise the filter table will be empty when I call receive in the test case. I know NFD has LimitedIo for this sort of thing, but is there something equivalent in cxx? (...or am I overcomplicating things?)

I think this needs the io service to run for a bit, otherwise the filter table will be empty when I call receive in the test case. I know NFD has LimitedIo for this sort of thing, but is there something equivalent in cxx?

io.poll()

I saw http://gerrit.named-data.net/#/c/2048. Why is it part of ndn-cxx library? Are we expecting this management dispatcher to be used anywhere else except NFD?

I guess this is one of the design objectives.

"Basic mechanisms can be reused inside and outside NFD."

Are we expecting this management dispatcher to be used anywhere else except NFD?

The intention is to allow using ManagementDispatcher in any application that adopts a management protocol similar to NFD Management.

As pointed out in #2200 note-30 item 1, this goal isn't fulfilled in current design.
I'm thinking about a solution.

@Yanbiao, please feel free to send me an email to setup a Skype/hangout time. I'm pretty available tomorrow. Otherwise, we can try sometime during the week. (Anyone else interested is welcome to attend, too...not sure this is worth taking time from an NFD call.)

@Yanbiao, please feel free to send me an email to setup a Skype/hangout time. I'm pretty available tomorrow. Otherwise, we can try sometime during the week. (Anyone else interested is welcome to attend, too...not sure this is worth taking time from an NFD call.)

Thanks Steve, I has sent an email to you.

One problem in dispatcher implementation is: how to emit error logs.

Background:

• The dispatcher lives in ndn-cxx library which does not have an logging facility.
• The dispatcher may be used in various applications that have different logging systems: NFD has NFD_LOG_ERROR macro, NLSR has log4cxx.
• Some functions are executed from io.run() so they shouldn't throw exceptions unless a fatal error (+ program termination) is desired.

Option 1: use log4cxx

• benefit: powerful logging facility, used by many projects
• benefit: reusable among all ndn-cxx components
• drawback: extra dependency

Option 2: emit an logError signal from Dispatcher

• benefit: works without dependency
• drawback: log lines are generated even if no logging facility is connected (note: dispatcher emits logError only in error conditions; it's not for debug logs)

Option 3: have a global logError signal

• benefit: works without dependency
• benefit: reusable among all ndn-cxx components
• drawback: log lines are generated even if no logging facility is connected (no problem with dispatcher, but other components can easily abuse this)

20150727 conference call decides:

• Put a // #define NDN_CXX_MGMT_DISPATCHER_ENABLE_LOGGING at the top of dispatcher.hpp.
• Dispatcher can write error logs into std::clog.
• All logging commands should be wrapped in #ifdef NDN_CXX_MGMT_DISPATCHER_ENABLE_LOGGING #endif // NDN_CXX_MGMT_DISPATCHER_ENABLE_LOGGING.

Reply to #2200 note-76 item 2:

When publishing face status, we should avoid the old data be fetched if there is a newer version. Shall we do this by setting NO CACHY policy or setting a freshnessPeriod?

In this Task, a FreshnessPeriod consistent with older version should be set.

Setting NO_CACHE would cause StatusDataset with multiple segments to stop working, because there's no internal cache in Dispatcher, and responding to subsequent segments relies on the ContentStore.

#2182 will add an internal cache, and then NO_CACHE will be set.

From Alex:

I have briefly checked FibManager, FaceManager, and StrategyChoiceManager test cases. I do not see how they are affected by the refactoring of the management. What is mostly tested there is the effects how manager reacts on the incoming commands: this behavior is not changing.
@Junxiao: what exactly you see the problem with fib-manager.t.cpp, face-manager.t.cpp, strategy-choice-manager.t.cpp? They are not ideal, but I cannot say they completely wrong and unreadable. Most test cases have self-explanatory names; actual checks I would agree are not very straightforward, but they should do the job.

I didn't say the current test cases are wrong. They just have too much duplication and are hard to maintain.

If test cases are not broken in this task, I could agree to split test case improvements into a separate task, but that needs to be done sometime.

From note-9:

There are large amounts of code duplication in the test suite. The test suite needs to be consolidated so that they are easier to maintain.

At 20150821 conference call, Alex disagrees with deferring unit testing improvements, because existing test cases will be broken when changing into the new dispatcher.

There are two possible options:

• Delete all test cases, and re-add them.
• Modify existing test cases BEFORE changing dispatcher, so that they feed Interests into the InternalFace instead of XManager. When changing into the new dispatcher, test cases should not be broken.

Yanbiao is to explore the second option.

I notice a small issue with Dispatcher design: StatusDatasetContext isn't marked noncopyable. I'll upload another Change to fix this problem, as well as changing some function-by-value to function-by-const-reference.

http://gerrit.named-data.net/2432

There is a problem with ForwarderStatusManager and specifically ForwarderStatus dataset.

ForwarderStatus is encoded as

    21 (Content) (size: 75)
      128 (APP_TAG_1) (size: 20) [[0.3.4-commit-c9b26a3]]
      ...
      152 (APP_TAG_1) (size: 1) [[%00]]

and then appended to the context, resulting in two nested Content blocks in the data packet:

  21 (Content) (size: 77)
    21 (Content) (size: 75)
      128 (APP_TAG_1) (size: 20) [[0.3.4-commit-c9b26a3]]
      ...
      152 (APP_TAG_1) (size: 1) [[%00]]

Is this urgent? Since the remote registration also needs to update the Developer's Guide. Can I do their documentation together?

I have written the documentation of Dispatcher in #2200 note-91.

Yanbiao should write documentation for NFD's usage of Dispatcher as part of this issue; I can't write this part because I'm unfamiliar with Managers.

Where to put this documentation? NFD developer guider?

Answer to note-47:

Dispatcher itself is already documented in ndn-cxx Application Developer Guide.

NFD Management and its usage of Dispatcher should be documented in NFD Developer Guide.

Contact Alex for repository permission.