[ndnSIM] Counting the number of interest packets received in a Namespace

Spyridon Mastorakis smastorakis at unomaha.edu
Wed Feb 5 19:39:10 PST 2020

Why not using these counters?



Spyridon (Spyros) Mastorakis
Assistant Professor
Computer Science Department
University of Nebraska, Omaha
Peter Kiewit Institute Room 175A

On Feb 4, 2020, at 1:31 PM, Dyaneswaran S <dyaneswaran16028 at cse.ssn.edu.in<mailto:dyaneswaran16028 at cse.ssn.edu.in>> wrote:

Hi guys,
    My objective is to count the no of interest packets received in a node. Since this looked like the kind of namespace specific information that can be stored in the Measurements Table, I did the following as suggested in the NFD Developers Guide and other strategies in the forwarder,

1. Created a Nested Counter Class inside my Strategy class. It looks something like this -

  class CounterInfo : public StrategyInfo
        static constexpr int
        {   return 1009; }

        CounterInfo() : m_count(0)

        {  ++m_count;}

        {   return m_count; }
        uint64_t m_count;

2. Then, in my AfterReceiveInterest() Trigger, I retrieve the entry using the piEntry APIs like this,

          CounterInfo *counter = pitEntry->getStrategyInfo<CounterInfo>();
          if(pitEntry->getStrategyInfo<CounterInfo>() == nullptr)
                counter = new CounterInfo();

3. I thought the above 2 steps were sufficient, but apparently not. So after more digging, I found out I had to extend the Lifetime of Measurements Table Entries. I was not sure how Measurements and StrategyInfo Class were interrelated but I did it anyway. (superstitious, I agree).  That looked like -

 this->getMeasurements().extendLifetime(*entry, MEASUREMENTS_LIFETIME);

But even then, I didnt get the expected output. That is the counter variable is not counting the packets.

Instead, its count never gets past 1. I am sure this is because its getting instantiated newly everytime this strategy is applied.

Somehow, its not accessing the already stored strategy info. I thought it was because of the different pit entries causing new measurement entries (since measurements are accessed via pitentries). But I made sure that didnt happen as well.

I thought about approximating the count of interest packets to the no. of PIT inrecords but that was ridiculous. I needed the actual count of interest packets.

Any pointers?? Any of my assumptions wrong?
Am I doing it the hard/correct way? Any other methods?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20200206/865358f0/attachment.html>

More information about the ndnSIM mailing list