Task #4734
closedRedefine Notification Stream procedures without ChildSelector
100%
Description
NFD Management protocol's Notification Stream mechanism currently requires the use of deprecated ChildSelector. It should be redefined without using ChildSelector and Exclude.
This issue is protocol definition only. Implementation is in #4664.
Updated by Junxiao Shi about 6 years ago
- Blocks Bug #4664: NotificationSubscriber uses ChildSelector added
Updated by Junxiao Shi about 6 years ago
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
- % Done changed from 0 to 10
Notification rev7 gives two subscriber workflows. First workflow requires "ChildSelector=rightmost Exclude=any,last-know-seq-num" in every Interest. Second workflow requires "ChildSelector=rightmost MustBeFresh=yes" in first Interest, and uses incrementing sequence numbers in subsequent Interests.
I think the most straightforward solution is:
- Subscriber sends CanBePrefix=yes MustBeFresh=yes for the first Interest, and uses incrementing sequence numbers in subsequent Interests.
- Publisher sets minimum FreshnessPeriod.
While RDR protocol (#4706) is attractive, it's overkill for Notification Stream. RDR allows high FreshnessPeriod on application Data, and uses a short-lived metadata packet to inform consumers what's the latest application Data. NFD Management's notifications are short-lived and there's no benefit in setting high FreshnessPeriod on notifications, and therefore subscribers can directly retrieve notifications in the same way they retrieve RDR metadata.
PSync is another possible solution, but it's also overkill for Notification Stream. PSync allows subscribers to get updates about multiple data streams, while NFD Management only has a handful of notification streams, so it's not worth the overhead of adopting PSync.
Updated by Junxiao Shi about 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 10 to 100
Notification rev8