[ndnSIM] Content Store - caching a couple weird objects?

John Baugh jpbaugh at umich.edu
Sat Dec 3 17:00:20 PST 2016

Junxiao and Muhammad,

Thank you for your responses.  For a little more clarification regarding
where the actual data entries are stored:

When I look at cs.hpp:  *http://ndnsim.net/2.1/doxygen/cs_8hpp_source.html
<http://ndnsim.net/2.1/doxygen/cs_8hpp_source.html>*, and also the cs.cpp
file: *http://ndnsim.net/2.1/doxygen/cs_8cpp_source.html
<http://ndnsim.net/2.1/doxygen/cs_8cpp_source.html>*, I see the following:

In the Cs *HPP , *I see as data (private)*:*

*Table m_table;unique_ptr<Policy>
m_policy;ndn::util::signal::ScopedConnection m_beforeEvictConnection;*

So, a table (of entry names?), a smart pointer to the Policy (possibly with
a polymorphic object), and a signal - no data.

In the Cs *CPP*, I see nothing indicating insertion of data, except *through
*the policy.

On the contrary, when I look at one of the *Policy classes*, such as in the
FIFO policy (
http://ndnsim.net/2.1/doxygen/cs-policy-priority-fifo_8cpp_source.html) I
see use of what appears to be a map of entries, and an actual queue

I'm just trying to wrap my head around what is going where.

I've been told, or given the impression, that if you want to change the
caching algorithm (cache replacement, caching) then the route to go is to
provide a subclass of the *Policy*, NOT the *Cs *itself.

Thanks a ton, everyone,


On Sat, Dec 3, 2016 at 6:58 AM, Junxiao Shi <shijunxiao at email.arizona.edu>

> Hi John
> 1. With few exceptions, names beginning with /localhost/nfd belong to NFD
> Management protocol 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 Data.
> 2. Yes, NS_LOG allows one to enable and disable each logging component
> individually via NS_LOG environ at runtime. For tracers, see
> https://www.nsnam.org/docs/release/3.25/manual/html/tracing.html "tracing
> motivation" and remember that NS_LOG will not work if ns-3 is compiled in
> release mode.
> 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
> ContentStore").
> Yours, Junxiao
> 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:*
>> https://drive.google.com/open?id=0By9ufeKqmJYYN0dLMENXOVJjSlE
>> *My derived / customized policy class:*
>> https://drive.google.com/open?id=0By9ufeKqmJYYYUZOQUZFd21ORDA
>> *The output of the contents of Content Store:*
>> https://drive.google.com/open?id=0By9ufeKqmJYYTXdCMU1nN3lYeFU
>> Questions:
>> 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?
>> Thanks,
>> John
>> _______________________________________________
>> ndnSIM mailing list
>> ndnSIM at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20161203/30abec42/attachment.html>

More information about the ndnSIM mailing list