Project

General

Profile

Notification » History » Revision 7

Revision 6 (Junxiao Shi, 05/23/2014 11:54 PM) → Revision 7/12 (Junxiao Shi, 08/09/2014 09:18 AM)

# Notification Stream 

 **Notification Stream** is a mechanism of [[Management|NFD Management protocol]]. 
 It is a way to get updates about events happening in the forwarder. 
 This mechanism is useful for monitoring forwarder state. 

 ## Naming 

 * A stream of notifications is published under a certain Name prefix. 
 * A notification is a Data packet under this Name prefix with a sequence number. 
   * The sequence number component is a NameComponentWithMarkerAndNumber, as in [NDN Naming Conventions](http://named-data.net/doc/tech-memos/naming-conventions.pdf). 
     This component starts with NameComponent containing a 0xFE marker, followed by a nonNegativeInteger. 
   * The sequence numbers of notifications in the same stream should be consecutive and increasing. 
   * Each notification is limited to one Data packet. 

 Example: 

     ndn:/localhost/nfd/faces/events/%FE%00 ndn:/localhost/nfd/faces/events/%00 // first notification 
     ndn:/localhost/nfd/faces/events/%FE%01 ndn:/localhost/nfd/faces/events/%01 // second notification 

 ## Notification publisher 

 Notifications from NFD are Data packets generated and signed by NFD. 

 These Data packets enter forwarding system via the InternalFace, and are subject to regular forwarding pipelines. 
 They should be admitted into the ContentStore. 

 ## Notification subscriber 

 The subscriber should typically request the Name of notification stream (`ndn:/localhost/nfd/faces/events` in the example) with ChildSelector=rightmost and Exclude=Any..*last-received-seq*. 
 If the subscriber has no knowledge of *last-received-seq*, the Exclude selector should be omitted. 
 InterestLifetime should be set to a long duration, such as 60000ms. 

 * If no new notification has been generated after *last-received-seq*, this Interest will stay in the PIT, and be satisfied when a new notification is generated. 
 * If one or more new notifications have been generated after *last-received-seq*, the Interest will be satisfied from the ContentStore, and the latest notification is returned.   
   The subscriber can retrieve missing notifications between *last-received-seq* and the returned latest notification by expressing additional Interests without Selectors. 

 Alternately, the subscriber can initially request the Name of notification stream with ChildSelector=rightmost and MustBeFresh=yes. 
 After a notification is received, the subscribe can send an Interest for the next anticipated sequence number, without Selectors. 
 If any Interest times out (because no notification is delivered within InterestLifetime), the subscriber restarts with the initial request.