[Nfd-dev] NFD mgmt: eliminate double-dispatch
Junxiao Shi
shijunxiao at email.arizona.edu
Mon Jun 2 18:47:27 PDT 2014
This proposal describes the original design intention of the Interest
dispatch mechanism of NFD management.
Current implemented design:
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
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&)> 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);
typedef function<void(const Name&, const Interest&)> Authorization;
// ReplyEncryption: I don't have a good design for now
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
Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140603/15ebbc83/attachment.html>
More information about the Nfd-dev
mailing list