[Nfd-dev] [Ndn-app] Close NFD backdoor

[Dave Oran (oran)]

I don’t mean to hijack this thread, but it seems that the architecture needs two cache timers, not one.

One is an Expiry timer after which the data is no longer considered valid (and hence should not be returned from the cache if an interest arrives), the other is a desired caching period timer, which can be used by the cache as one of the inputs to its replacement algorithm.

On Sep 8, 2014, at 2:29 PM, Yingdi Yu <yingdi at CS.UCLA.EDU> wrote:

> Hi JeffT,
> 
> On Sep 8, 2014, at 2:53 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
> 
>> The NDN-RTC video conferencing app uses the MemoryContentCache in-app storage. It keeps data in the cache based on the data packet's FreshnessPeriod.
>> http://named-data.net/doc/ndn-ccl-api/memory-content-cache.html
>> 
>> You say "content store is aware of FreshnessPeriod of data packets, but an in-app storage should not."  Why should the in-app storage not be aware of the FreshnessPeriod?
> 
> In the NDN-TLV spec, the definition of FreshnessPeriod says "Note that the stale data is still valid data; the expiration of FreshnessPeriod only means that the producer may have produced newer data." My understanding about this is that FreshnessPeriod is used by end producer to tell intermediate routers (including local nfd) how long a data packet should stay in a content store. The end producer is the only one who knows and can decide whether a data packet is valid or not. And the in-memory storage contains data packets that are treated as valid by end producer.
> 
> For example, producer A generates a data packet "/a/b/c" with 10-second FreshnessPeriod. If "/a/b/c" is put into the MemoryContentCache, the packet will be removed from the cache after 10 seconds, and the producer A will have to generate the same data packet again even if the producer A still takes "/a/b/c" as valid. With the in-memory storage, the packet will never be removed until the producer generates a new valid data packet to replace "/a/b/c". And "/a/b/c" will be obsolete by the new data packet.
> 
> Yingdi
> 
> _______________________________________________
> Ndn-app mailing list
> Ndn-app at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140908/9f58d6bb/attachment.bin>