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

John Baugh jpbaugh at umich.edu
Sat Dec 3 23:23:29 PST 2016

All -

As a follow up, I noticed that *emitSignal(beforeEvict, i); *is called in
both the LRU and Priority FIFO Policies.  Is *this *what tells the Cs to
remove the actual data, as the Policy subclass should also mimic / mirror
the removal from its "secondary index" (to quote Junxiao)?  I assume since
it's not just calling beforeEvict or something that it must be doing
something besides just that.

This may be the last major piece to my puzzle of figuring out what is going



On Sat, Dec 3, 2016 at 8:00 PM, John Baugh <jpbaugh at umich.edu> wrote:

> 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 (m_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,
> John
> On Sat, Dec 3, 2016 at 6:58 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>> 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/20161204/d457324e/attachment-0001.html>

More information about the ndnSIM mailing list