Provide canonical example for latest data retrieval without selectors in real-time applications
With the pending deprecation of selectors, please provide an example in ndn-cxx for achieving efficient retrieval of "latest data". Once there is an assignee, the application group can help to create a more specific requirement document.
#1 Updated by Junxiao Shi about 1 year ago
ndn-cxx has not been used to develop any real-time application so I don’t see why this needs to be in ndn-cxx, as opposed to ndn-cpp.
From protocol point of view, finding the name for “latest data” requires an Interest reaching the producer itself.
Using selectors, the last Interest excluding all existing versions would reach the producer, and the producer should Nack this Interest, so the consumer knows it has found the last versions.
Not using selectors, the consumer can directly ask the producer
/producer-prefix/what-is-latest-version/[random-number], and the producer can answer with the current version number plus some metadata about how to derive future versions, such as “I’ll generate a new version every second, and they’ll be named like ..”. The consumer can then retrieve the indicated version, plus several later versions as derived from the metadata in order to account for the round-trip during “what-is-latest-version” retrieval.
#4 Updated by Jeff Burke 12 months ago
Yes, this may be more appropriate for ndn-cpp (except for the blocks on selector deprecation). But generally we have followed the pattern where architectural issues are demonstrated/prototyped in ndn-cxx, then the ndn-ccl implementations follow. I'll follow up with Lixia et al on this.
#6 Updated by Spyros Mastorakis 5 months ago
- Status changed from New to Closed
Please take a look at the following paper that presents a solution to this problem:
#7 Updated by Junxiao Shi 5 months ago
- Project changed from ndn-cxx to NDN Specifications
- Assignee set to Spyros Mastorakis
- % Done changed from 0 to 100
I carefully read the paper cited in note-6. It indeed solves the problem in real-time applications. Attack is possible but prohibitively expensive with limited effect.