Task #1244
closed
Face status change notification publisher
Added by Junxiao Shi about 10 years ago.
Updated about 10 years ago.
Description
Implement a publisher of face status change notification stream.
Initial design is below.
Assignee is permitted to make reasonable changes to the design.
API¶
interface NotificationStream
{
__construct(AppFace, Name prefix)
template<typename Notification>
void postNotification(Notification notification)
}
enum FaceEventKind
struct FaceEventNotification
{
FaceEventKind
FaceId
Uri
FaceFlags
Block wireEncode()
wireDecode(Block)
}
Operations¶
- Caller creates a
NotificationStream instance, which is the publisher of a notification stream.
- Caller constructs a
Notification class (FaceEventNotification for face status change), and pass wireEncode'd of it to NotificationStream::postNotification
NotificationStream::postNotification further encloses the payload into a Data packet, and puts the Data packet through the AppFace.AppFace::put will cause InternalFace to receive this Data packet. Since InternalFace is trusted, this unsolicited Data packet will be placed into the ContentStore, waiting for client to retrieve.
Note:
NotificationStream does not store Notification, payload, or Data packet. It generates Data packet and puts to ContentStore, and then relies on ContentStore to keep it.
- Description updated (diff)
- Assignee set to Anonymous
ContentStore is not ready yet, so this task cannot be tested end-to-end.
Unit testing could watch for the Data packet being passed to AppFace::put or InternalFace::onReceive.
Is the face manager the intended publisher or does it a has-a relationship? Description sounds like the latter.
I see that the protocol has both a version and segments. Does something trigger a new version or is just acting as a timestamp? (i.e. if there are multiple notifications within the version granularity then produce segments, else each notification has a distinct version, segment 0)
FaceManager has a NotificationStream whose prefix is set to "ndn:/localhost/nfd/faces/events".
NotificationStream need not check the type of Notification.
It makes a Data whose Name is prefix+seq, and Content is notification.wireEncode().
Data Name has no version or segment. Its last component is a sequence number.
("List faces" on the same page is Task #1245 and it has version and segment)
- Status changed from New to In Progress
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
I noticed that this protocol and face management share a common prefix (/localhost/nfd/faces). While the notification protocol states that ChildSelector=1 and exclusions should typically be used, it's not a hard requirement and an Interest could wind up at the FaceManager. I believe this would trigger some kind of "unsigned command" control response from the manager and could be confusing. Ideally, nothing should happen (or potentially a NACK at some later stage?).
Would it be possible to change the notification protocol's namespace? I think /localhost/nfd/events/faces (simply swapping the order of faces/events) would solve this problem and provide a common namespace for other notification stream publishers.
The namespace is chosen by semantics. It will not be changed due to the reason stated in note-6.
Any Interest under ndn:/localhost/nfd/faces/events namespace should be satisfied from the ContentStore.
If it is not satisfied by ContentStore and ends up in FaceManager, FaceManager MUST NOT respond to these Interests.
This violates the control command specification:
A request to the command interface is an Interest under ndn:/localhost/nfd/<management-module>/<command-verb>... prefix.
where "management-module" is defined as
management module to which the command needs to be dispatched
I8710dedaba94c1fcd852bd3aa2f21d39ad0bd7ee
adds two events from FaceTable class: OnAdd and OnRemove.
FaceManager should subscribe to these events, and publish a notification when event fires.
- Description updated (diff)
- Description updated (diff)
Don't call Notification "event". The term "event" has too many meanings and is ambiguous.
But then we have inconsistency. TLV type is called FaceEvent. Should it be renamed to FaceEventNotification? If so, I don't have problems returning previous naming scheme.
I prefer to change FaceEvent to FaceStatusNotification.
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by Anonymous 
Updated by