[Ndn-interest] Freshness & Latest Content
urs.schnurrenberger at unibas.ch
Fri May 4 02:18:58 PDT 2018
interesting approach. So far, I used mandatory version fields and a reserved version number '-1' that indicates 'latest'. Hence, an Interest with version -1 for the first chunk of a content always gets through to the producer. From the first Data packet, the requester can retrieve the actual latest version number and use it to request the remaining chunks. Of course, this is just a let-it-happen approach and not optimal, especially for contents with few chunks. However, the behavior is the same when using your idea of a zero-length component.
Von: Junxiao Shi <shijunxiao at email.arizona.edu>
Gesendet: Freitag, 4. Mai 2018 01:05
An: Urs Schnurrenberger <urs.schnurrenberger at unibas.ch>
Cc: ndn-interest at lists.cs.ucla.edu
Betreff: Re: [Ndn-interest] Freshness & Latest Content
What then happens when the (same as below) Interest
/nytimes/frontpage | CanBePrefix=true | MustBeFresh=true
arrives at a cache with the sole content
/nytimes/frontpage/addBanner/v23 | 60'000ms
According to prefix matching and a positive freshnessPeriod, will I receive the addBanner only and never the complete front page?
Yes, the cache will return the /nytimes/frontpage/addBanner/v23 Data.
My old article about web publishing over NDN https://yoursunny.com/t/2011/ndn-web/ proposed a solution: the Data name should include an extra component: /nytimes/frontpage/.../v105 (... denotes a zero-length component, see NDN URI spec). The Interest is then /nytimes/frontpage/... CanBePrefix=1 MustBeFresh=1, which cannot be satisfied by /nytimes/frontpage/addBanner/v23.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest