NFD » ndn-cxx

https://gerrit.named-data.net/3354 is a partial implementation of adding data validation to NotificationSubscriber.
Before I can continue working on this, a design question must be resolved.

What's the proper procedure after data validation fails?
If we send an initial Interest right away, most likely the Interest would bring back the same Data.
Assuming the data failing validation is in reply to an Interest with sequence number (rather than an initial Interest), if we send the next Interest with incremented sequence number, we would lose one notification.
Waiting out the FreshnessPeriod before sending an initial Interest also would not work, because the bad Data may have extremely long FreshnessPeriod.
We could probably use Exclude selector to exclude the implicit digest of the bad Data, in hope of bringing back a different Data that could pass validation. The implementation would be more complicated, because if there are many bad Data, the Interest with many Exclude entries would eventually exceed the practical limit on packet size and need to be split into multiple Interests.

In fact, similar problem already exists in the current implementation regarding decode error.
When a Data cannot be decoded as a notification, the NotificationSubscriber reacts by sending an initial Interest right away. In reality, this Interest would bring back the same malformed Data. If no new Data is generated, the system would enter a loop until the malformed Data is evicted from ContentStore.

Note that leaving this mess to the calling application is not an option, because NotificationSubsciber is designed to reliably retrieve notifications.
Even if we are allowed to stop fetching and inform the application, the application would still face the same problem: whenever it invokes start() again, the initial Interest brings back the same Data and the subscriber stops again.