[ndnSIM] How the application level tracers work?

[Alex Afanasyev]

Hi Anil,

> On Apr 2, 2016, at 7:17 PM, Anil Jangam <anilj.mailing at gmail.com> wrote:
> 
> Hi,
> 
> In my simulation scenario, I get no output when I enable the application delay tracer. However, when I run the example provided, it works fine. So, are there any preconditions in this example program, which I need to take care of or just following line is enough to collect the application delay metrics?

ApplicationDelayTracer relies on trace signals produced by ndn::Consumer app (you can check apps/ndn-consumer.cpp inside Consumer::GetTypeId method).  If your scenario doesn't have ndn::Consumer-based app or doesn't implement exactly the same trace signals, then the tracer will be useless.  So, the only precondition is that you need to have an ndn::Consumer* installed or have an app with same trace signals.


> ndn::AppDelayTracer::InstallAll("app-delays-trace.txt");

> I also want to understand the significance of Connect() function implementation.
> 
> Config::ConnectWithoutContext("/NodeList/" + m_node
>                                   + "/ApplicationList/*/LastRetransmittedInterestDataDelay",
>                                 MakeCallback(&AppDelayTracer::LastRetransmittedInterestDataDelay, this));
> 
> Config::ConnectWithoutContext("/NodeList/" + m_node + "/ApplicationList/*/FirstInterestDataDelay",
>                                 MakeCallback(&AppDelayTracer::FirstInterestDataDelay, this));
> 
> What does ConnectWithoutContext() do? I looked into the Config class, but did not understand what service it really provides. What the attributes (like
> LastRetransmittedInterestDataDelay and FirstInterestDataDelay) actually mean? Are they predefined anywhere or are they user defined?

Connect and ConnectWithoutContext differ in the signature of the callback that will be called when trace is "signaled".  Just connect, will also add string parameter that would represent from which node it is called, and without will not have this parameter.  In the tracer, information about the node is already recorded, so it is unnecessary to have additional context.

Config class just provides a very generic interface to connect things. Actual attributes are defined as part of GetTypeId methods of NS-3 "object" classes.  You can check ndn::Consumer's definition in apps/ndn-consumer.cpp.  You can also check NS-3 documentation about it, e.g., https://www.nsnam.org/wiki/HOWTO_determine_the_path_of_an_attribute_or_trace_source


---
Alex



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20160413/b3108ae3/attachment.bin>