[ndnSIM] The prefix in the CS

John Baugh jpbaugh at umich.edu
Mon Jun 12 01:32:52 PDT 2017

Greetings all,

If you wish, ignore the last e-mail unless you have a better suggestion
than me modifying the Consumer base class...  I apologize for e-mailing
again so soon, but I did a little digging and found something promising, so
I started playing with it.  I won't e-mail again this morning (evening?
 night?  I don't even know what time it is...)

I modified the Consumer class in ndn-consumer.[hpp,cpp] to maintain an
extra data member, m_suffix, an uint64.  I think added an ".AddAttribute"
to the static TypeId definition, so that the helper would allow me to pass
"Suffix" as a helper, with UintegerValue as the type.

Then, in the SendPacket method, I created a condition so that:

*   nameWithSequence->appendSequenceNumber(m_suffix) *

is used instead of

However, now when I run the application:

1.  It does print out my prefix/suffix in the form /prefix/%FE%*suffix*

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.

3.  Was handling this (2, i.e. duplicate removal/prevention) not
implemented behind the scenes because the seqNumber always ensured the same
item was never requested twice?  That seems unrealistic, but I could
understand if simply no one got around to it yet.

*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 ??*

Thanks a ton for your patience.  I'm learning a lot, but apparently have a
long way to go.

Thanks a ton,


On Mon, Jun 12, 2017 at 3:05 AM, John Baugh <jpbaugh at umich.edu> wrote:

> Junxiao et al.,
> Thank you for your response.  That does clarify things a bit.  Would the
> best option to, in your words, "program/configure your consumer to send out
> Interests with same names" be to subclass Consumer (or one of its
> subclasses) and override one of the methods?
> 1.  I cannot seem to find where the randomization of the values such as
> %FE%C3 are being appended to "/prefix/" before the interest is sent.  Does
> anyone know where this would be?
> 2.  I suppose that my goal is to have a particular Consumer object request
> say, /prefix/1 multiple times, maybe interspersed with say, prefix/2 or
> others (but from a finite, reasonably predictable set of options.  Thoughts?
> 3,  I assume if I do (2) even with different Nonces, the producer, cache,
> etc. will consider anything with /prefix/1 to be a single requested content
> object, correct?
> 4.  I would also assume that it's unlikely the Producer would need
> modified, if you specify that the producer handles "/prefix/" then,
> anything starting with that should be responded to with content, correct?
> Thanks,
> John
> On Tue, Jun 6, 2017 at 2:52 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>> Hi John
>>> When the requested "/prefix" is set for particular consumers, for
>>> example, there appear to be many requests made (e.g., ConsumerCbr):
>>> /prefix/%FE%C3/...
>>> /prefix/%FE%C4/...
>>> 1.  I printed out the contents of cached items in the Content Store
>>> (using getFullName().toUri() on the iterator in my loop, starting at
>>> begin(), ending at end(), of course.), and noticed that each of these is
>>> treated as separate content objects?
>> Yes.
>>> 2.  I was previously under the impression that /prefix/*whatever* was a
>>> single content object, and that the Content Store wouldn't cache more than
>>> one of them.  Is the /%FE%C3/... part of the content object's true name?
>> Yes.
>>> 3.  If this is the case, it seems like the Consumers never request the
>>> same item more than once... is there any way to control this?  I want to
>>> ultimately simulate multiple requests of the same contents from various
>>> consumers to see how it affects the Cs
>> You can program/configure your consumer to send out Interests with same
>> names.
>> Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20170612/bea45644/attachment-0001.html>

More information about the ndnSIM mailing list