[Nfd-dev] Fwd: NFD mgmt: eliminate double-dispatch

[Junxiao Shi]

This proposal describes the original design intention of the Interest
dispatch mechanism of NFD management.
This message was originally sent on Jun 02. This version is a correction.

Current implemented approach:
NFD management module consists of:

   - several Managers, such as FaceManager, FibManager,
   StrategyChoiceManager
   - an InternalFace
   - a configuration parser

To process an Interest:

   - InternalFace receives ndn:/localhost/nfd Interests from forwarding,
   looks at the third component (management module), and dispatch it to a
   Manager.
   - Upon Interest arrival, Manager looks at the fourth component, and do
   one of the following:
      - for command verb: validate Command Interest, and then dispatch the
      Interest to the function that handles this command
      - for dataset: dispatch the Interest to the function that generates
      data for this dataset
      - for notification stream: drop the Interest
   - Replies are directly written to InternalFace

Drawback of this design:

   - Each Interest is dispatched twice: once in InternalFace, again in
   Manager.
   - Authentication is scattered across Managers.
   - Reply encryption is non-existent.


Design intention:

partial interface InternalFace {
  // reply(const Data& data, bool isFinal);
  //   data: unsigned and unencrypted Data
  //   isFinal: true if this is that last Data to send
  typedef function<void(const Data&, bool)> ReplyFunc;

  // process(const Interest& interest, const Name& identity, ReplyFunc
reply);
  //   identity: verified identity of requester, if available; otherwise
empty
  //   reply: a function to send replies
  typedef function<void(const Interest&, const Name&, ReplyFunc)>
InterestHandler;

  // accept(const Name& identity)
  //   identity: verified identity of requester, if available; otherwise
empty
  typedef function<void(const Name&)> AcceptContinuation;

  // reject(bool reply401)
  //   send401: whether to reply 401 or silently drop
  typedef function<void(bool)> RejectContinuation;

  // authorize(const Name& prefix, const Interest& interest,
AcceptContinuation accept, RejectContinuation reject);
  //   accept: function to call if authentication succeeds
  //   reject: function to call if authentication fails
  typedef function<void(const Name&, const Interest&, AcceptContinuation,
RejectContinuation)> Authorization;

  // encryptReply(const Name& identity, shared_ptr<Data> data);
  typedef function<void(const Name&, shared_ptr<Data>)> ReplyEncryption

  void register(const Name& prefix, Authorization, ReplyEncryption,
InterestHandler handler);
}


   - During initialization, Manager should register its commands, datasets,
   and notification streams into InternalFace
      - examples:
      face->register("ndn:/localhost/nfd/faces/create",
      CommandInterestAuthorization("faces"), NullReplyEncryption(),
      bind(&FaceManager::onCreateCommand, this, _1, _2, _3));
      face->register("ndn:/localhost/nfd/faces/list",
      DatasetAuthorization(), NullReplyEncryption(),
      bind(&FaceManager::generateFaceList, this, _3));
      face->register("ndn:/localhost/nfd/faces/events",
      DropAllAuthorization(), nullptr, nullptr);
   - InternalFace receives ndn:/localhost/nfd Interests from forwarding,
   perform a longest prefix match on registered prefixes
      - if no registration is found, record to log, and drop the Interest
   - Perform authorization as requested
      - CommandInterestAuthorization(const std::string& privilege) accepts
      valid Command Interests with this privilege, and rejects with
401 otherwise
      - DatasetAuthorization accepts Interests with Name equal to the
      prefix, and drops other Interests (they should be satisfied by
ContentStore)
      - DropAllAuthorization drops all Interests; this is used with
      notification streams because Interests should wait until notification is
      delivered
   - Dispatch to the handler
   - Handler calls ReplyFunc zero or more times with unsigned and
   unencrypted Data
   - ReplyFunc is a bound function that knows the ReplyEncryption; it
   encrypts Data as requested, and then sign and send it


In addition, derive a ndn::Face subclass (which has the same API as a
client face in ndn-cxx), so that the same Dataset publisher and
Notification Stream publisher can be used both in external app and within
NFD management.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141008/a5f6ba11/attachment.html>