[ndnSIM] The prefix in the CS

[John Baugh]

Junxiao,

Good call...  I was up late so I didn't question what was going on enough.
I turns out the printing I was doing was for interests... not the content
store contents.

Now, the only thing in my CS is apparent some setup information, so it
appears I have the opposite problem.  It doesn't seem to have anything
cached by the end of the scenario being run.  To print out the content
store, I created a method printContentStore that I pass the CS into (that I
obtained from the l3protocol for the "router" node in the middle, which I
assume is the router...) - and it starts at cs.begin() until cs.end().  I'm
using cout and a regular file stream with it, but still - same information,
it's not printing anything other than what appears to be setup information.

In printing, I used the iterator, *it*, and used code like:

*std::cout<<it->getFullName().toUri()<<std::endl;*



So I guess the better questions I should be asking are:

1.  *When *should one print the contents of the content store?  After
Simulator::Run is called?  After Destroy?  Before ::Run?



2.  *Should I* even be trying to print the CS from inside the scenario file
at all?



3.  *Where *should I be printing it, and is there a technique that is
preferred over writing your own CS printing routing?

Thanks,

John

On Mon, Jun 12, 2017 at 7:56 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi John
>
> 2.  The content store still seems to be caching them as separate content
>> items!  Even if there are say, 20 different requests for /prefix/%FE%01?...
>>  they are each apparently cached separately.
>>
> How do you know that? If you have logs, paste a snippet of relevant logs.
> Short logs (less than 200 lines) should be pasted on email body. Long logs
> should be uploaded to Gist or PasteBin. Do not send logs as attachments.
> See also http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/
> 001748.html
>
>
>> *4.  Is ensuring duplicates aren't cached something that the Policy must
>> take care of?  (immediately evict an entry with the same /prefix/seqNumber
>> and/or /prefix/suffix ??*
>>
> No. Assuming there is only one producer creating the requested Data,
> subsequent Interests for the same Data should match the existing CS entry
> and should not be forwarded again.
> If you are sending multiple Interests with the same name from multiple
> consumers located in sparse locations, and there are multiple producers, it
> is possible that each producer can generate a different Data, and those
> Data could be cached separately. Remember that the Data name ends with an
> implicit digest, and signing the same name+payload multiple times will
> generate different signatures and thus different implicit digests, even if
> those producers are using the same signing key.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20170612/438563ec/attachment.html>