[ndnSIM] Content Store - caching a couple weird objects?
shijunxiao at email.arizona.edu
Sat Dec 3 03:58:44 PST 2016
1. With few exceptions, names beginning with /localhost/nfd belong to NFD
https://redmine.named-data.net/projects/nfd/wiki/Management . NFD
Management protocol is designed as an NDN application layer protocol, so
its packets show up as Interests and Data. CS caches them just as any other
2. Yes, NS_LOG allows one to enable and disable each logging component
individually via NS_LOG environ at runtime. For tracers, see
motivation" and remember that NS_LOG will not work if ns-3 is compiled in
3. No. CS itself caches the Data inside nfd::cs::Entry class and maintains
an index based on names. The argument passed to Policy APIs is the iterator
on CS's primary index, and Policy maintains a secondary index of those
iterators used for eviction. The reason for this separation is to support
different Policy types with standard C++ subclasses, rather than complex
compile-time templates (which was used in ndnSIM 1.0 and appears as "old
On Fri, Dec 2, 2016 at 23:54 John Baugh <jpbaugh at umich.edu> wrote:
> Greetings all,
> I'm playing around with some of the content store stuff at the moment and
> have a couple questions.
> Here are the relevant files to my questions:
> *My primary simulation file:*
> *My derived / customized policy class:*
> *The output of the contents of Content Store:*
> 1.) I figure the stuff with /prefix/.... in front of it is just
> randomized / pseudorandomly generated items just starting with /prefix.
> But *what in the world is *the other garbage being printed to the file?
> Usually it's something like
> /localhost/nfd/faces/enable-local/control/<random string>.
> Is this some sort of setup information / link confirmation ACK or
> something that the nodes send/receive? Why is the CS caching it as if it
> were data?
> 2.) Is there a significant advantage to using one of the NS_LOG or
> tracers over using standard <fstream> library objects?
> 3.) If I understand correctly, the *POLICY *is responsible for actually
> caching the data? I assume that's all handled with the doBeforeInsert and
> the related virtual functions, like the policies that ndnSIM provides
> (FIFO, LRU, etc.), correct? The Content Store object itself seems to just
> cache the *names* and not the actual data?
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ndnSIM