Notification » History » Version 7
Junxiao Shi, 08/09/2014 09:18 AM
| 1 | 5 | Junxiao Shi | # Notification Stream |
|---|---|---|---|
| 2 | 1 | Junxiao Shi | |
| 3 | 5 | Junxiao Shi | **Notification Stream** is a mechanism of [[Management|NFD Management protocol]]. |
| 4 | It is a way to get updates about events happening in the forwarder. |
||
| 5 | This mechanism is useful for monitoring forwarder state. |
||
| 6 | 1 | Junxiao Shi | |
| 7 | ## Naming |
||
| 8 | |||
| 9 | * A stream of notifications is published under a certain Name prefix. |
||
| 10 | * A notification is a Data packet under this Name prefix with a sequence number. |
||
| 11 | 7 | Junxiao Shi | * The sequence number component is a NameComponentWithMarkerAndNumber, as in [NDN Naming Conventions](http://named-data.net/doc/tech-memos/naming-conventions.pdf). |
| 12 | This component starts with a 0xFE marker, followed by a nonNegativeInteger. |
||
| 13 | 1 | Junxiao Shi | * The sequence numbers of notifications in the same stream should be consecutive and increasing. |
| 14 | * Each notification is limited to one Data packet. |
||
| 15 | |||
| 16 | Example: |
||
| 17 | |||
| 18 | 7 | Junxiao Shi | ndn:/localhost/nfd/faces/events/%FE%00 // first notification |
| 19 | ndn:/localhost/nfd/faces/events/%FE%01 // second notification |
||
| 20 | 1 | Junxiao Shi | |
| 21 | ## Notification publisher |
||
| 22 | |||
| 23 | Notifications from NFD are Data packets generated and signed by NFD. |
||
| 24 | |||
| 25 | These Data packets enter forwarding system via the InternalFace, and are subject to regular forwarding pipelines. |
||
| 26 | They should be admitted into the ContentStore. |
||
| 27 | |||
| 28 | ## Notification subscriber |
||
| 29 | |||
| 30 | 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*. |
||
| 31 | 5 | Junxiao Shi | If the subscriber has no knowledge of *last-received-seq*, the Exclude selector should be omitted. |
| 32 | 7 | Junxiao Shi | InterestLifetime should be set to a long duration, such as 60000ms. |
| 33 | 1 | Junxiao Shi | |
| 34 | * 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. |
||
| 35 | * 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. |
||
| 36 | The subscriber can retrieve missing notifications between *last-received-seq* and the returned latest notification by expressing additional Interests without Selectors. |
||
| 37 | 7 | Junxiao Shi | |
| 38 | Alternately, the subscriber can initially request the Name of notification stream with ChildSelector=rightmost and MustBeFresh=yes. |
||
| 39 | After a notification is received, the subscribe can send an Interest for the next anticipated sequence number, without Selectors. |
||
| 40 | If any Interest times out (because no notification is delivered within InterestLifetime), the subscriber restarts with the initial request. |