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

[John Baugh]

Sorry again:

Now I'm REALLY confused.  The note in the documentation for doBeforeErase
says:

NoteThis will not be invoked for an entry being evicted by policy.

Besides the policy, what else is responsible for evicting an item?  In the
LRU and Priority FIFO, it seems an emitSignal is called, which I assume is
supposed to trigger beforeErase, which calls doBeforeErase?  This is a
confusing spider web.  Hopefully you can help me untangle it.  :)

I'm headed to bed.  I'd really appreciate some clarification on these
issues.

Thanks so much for your patience, everyone,

John

On Sun, Dec 4, 2016 at 2:23 AM, John Baugh <jpbaugh at umich.edu> wrote:

> 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.
>
> Thanks,
>
> John
>
> 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/017433d1/attachment.html>