[Ndn-interest] Question regarding consistency

[Alex Afanasyev]

> On Aug 24, 2015, at 6:12 AM, aniesh chawla <chawla.aniesh at gmail.com> wrote:
> 
> Hello Everyone,
> 
> I have a very basic doubt which I could not resolve while reading documentation of NDN. I would like to also take this as research topic if my doubt is valid.
> 
> The question is:
> How is the consistency of data maintained in the network? Since, NDN is "pull" based networking and lets say there is change in file version at one of the node and not in other nodes. I can see the this can be achieved through NDNFS, but still the other nodes will not have change in version of the file. So, how will the new node who is requesting for that file will get to know which version to ask for? If we use NDNS to resolve every such query and we use time stamp as version then also it should be propagated throughout the network? I also see that Chrono-sync does something like this but it has waiting timer for propagation delays. So either NDNS is talking to every node in the whole network or some other way.

To discover that a newer version of some data is available, you need to have additional mechanisms to discover newer name (version) of the data.  What you have mentioned is correct:  you can rely on ChronSync to notify about new published data items, you can use manifest and manifest-like mechanisms (e.g., NDNFS, NDNS) where consumers when desired retrieve information about current ("fresh") status of published data.  In either case, what you get is exact name of new data, including version number.

Selector mechanism that Tai-Lin mentioned is a way to get different data from what you already have.  It can be used for newer version discovery, though it can have additional implications from packet processing perspective.

--
Alex

> Is my understanding correct or am I missing something here?
> 
> Thanks a lot
> 
> Regards
> Aniesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150824/b042037f/attachment.bin>