Task #1244: Face status change notification publisher - NFD - NDN project issue tracking system

Actions

Copy link

Task #1244

closed

Face status change notification publisher

Added by Junxiao Shi over 10 years ago. Updated over 10 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

Management

Target version:

v0.1

Start date:

Due date:

% Done:

100%

Estimated time:

5.00 h

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.

Related issues 4 (0 open — 4 closed)

Actions

Copy link

Updated by Junxiao Shi over 10 years ago

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.

Actions

Copy link

Updated by Anonymous over 10 years ago

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)

Actions

Copy link

Updated by Junxiao Shi over 10 years ago

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)

Actions

Copy link

Updated by Anonymous over 10 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by Anonymous over 10 years ago

Status changed from In Progress to Code review
% Done changed from 0 to 100

Actions

Copy link

Updated by Anonymous over 10 years ago

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.

Actions

Copy link

Updated by Junxiao Shi over 10 years ago

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.

Actions

Copy link

Updated by Anonymous over 10 years ago

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

Actions

Copy link

Updated by Junxiao Shi over 10 years ago

I8710dedaba94c1fcd852bd3aa2f21d39ad0bd7ee
adds two events from FaceTable class: OnAdd and OnRemove.

FaceManager should subscribe to these events, and publish a notification when event fires.

Actions

Copy link

#10

Updated by Alex Afanasyev over 10 years ago

Description updated (diff)

Actions

Copy link

#11

Updated by Alex Afanasyev over 10 years ago

Description updated (diff)

Actions

Copy link

#12

Updated by Junxiao Shi over 10 years ago

Don't call Notification "event". The term "event" has too many meanings and is ambiguous.

Actions

Copy link

#13

Updated by Alex Afanasyev over 10 years ago

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.

Actions

Copy link

#14