[ndnSIM] Using the setExpiryTImer

Ashish Pradhan ashishpradhan1162 at gmail.com
Sun Nov 25 01:42:07 PST 2018


I have made the necessary changes. I have a small problem now. I have a
separate working repository where I have the custom apps,custom strategies
and and my scenarios. When I make the changes in the Strategy.cpp, it
doesn't seem to reflect in my simulations. I am not sure how to build those
files(the files within NFD, ndn.cxx etc )  for them to work with



On Sun, Nov 25, 2018 at 2:06 PM Teng Liang <philoliang at email.arizona.edu>
wrote:

> Hi Ashish,
>
> To keep it simple, one PIT entry represents a pending Interest, which
> guides Data forwarding. One router may receive Interests with the same name
> from multiple different downstreams. On receiving the Data that can satisfy
> these Interests, the router is able to multicast the Data to all the
> downstreams sending the Interests. PIT entry's in-record represents the
> face to downstream, and each in-record has an expiry timer (=Interest
> lifetime). PIT entry itself has a different expiry timer that is refreshed
> by the latest PIT in-record expiry timer (code:
> https://github.com/named-data/NFD/blob/master/daemon/fw/forwarder.cpp#L181-L184
> )
> Chapter 3.4 in NFD developer guide explains more details about PIT (
> https://named-data.net/wp-content/uploads/2016/10/ndn-0021-7-nfd-developer-guide.pdf).
>
>
> For you scenario, one hack that may work is to remove the expiry timer
> check on pit in-record check (
> https://github.com/named-data/NFD/blob/master/daemon/fw/strategy.cpp#L216)
> instead of step 2 in my previous email.
>
> Teng
> On 11/24/18 8:36 PM, Ashish Pradhan wrote:
>
> Hi Teng,
>
> Thank you so much for understanding my problem. I will try to implement it
> as you said. In the mean time can you please explain the difference between
> "setting expiry timer of the pit entry" and  "setting expiry timer of the
> pit entry's in record"
>
> Best Regards,
> Ashish Pradhan
>
>
>
> On Sun, Nov 25, 2018 at 12:08 PM Teng Liang <philoliang at email.arizona.edu>
> wrote:
>
>> Hi Ashish,
>>
>> I agree with you that simply extending PIT entry lifetime (using
>> setExpiryTimer) will not work for "One-Interest-Many-Data" in NFD, because
>> when you invoke Strategy::sendDataToAll for the second (or latter) Data,
>> the PIT entry's in-record is already deleted. You could try these changes:
>>
>>    1. Avoid deleting PIT entry's in-record after forwarding data by
>>    - commenting out this line:
>>       https://github.com/named-data/NFD/blob/master/daemon/fw/strategy.cpp#L203
>>    2. Extending PIT entry's in-record lifetime by
>>       - adding an update function with the parameter time duration in
>>       pit::FaceRecord (the base class of pit::InRecord)
>>       - setting pit entry's in-record lifetime when setting pit entry's
>>       lifetime (invoking the previous added function within
>>       Forwarder::setExpiryTimer:
>>       https://github.com/named-data/NFD/blob/master/daemon/fw/forwarder.cpp#L516
>>       )
>>    3. Deleting PIT entry's in-records in Forwarder::onInterestFinalize
>>    (this could be optional)
>>
>> Thanks,
>> Teng
>>
>>
>> On 11/24/18 5:08 PM, Ashish Pradhan wrote:
>>
>> Hi Xinyu,
>>
>> Thank you for your reply.
>>
>> I am fully aware of the One-Interest-One-Data behavior. However, I have
>> a custom app(a producer) where it produces multiple data for a single
>> interest. Then I want all the produced data to reach the consumer. So for
>> that, I am implementing a custom strategy where the PIT entry lifetime of
>> the nodes are extended after it receives the first data from the producer.
>> I have followed the ndnSIM API documentation for it.
>>
>> beforeSatisfyInterest documentation:
>>
>> http://ndnsim.net/current/doxygen/classnfd_1_1fw_1_1Strategy.html#a97b4f1e5496c4dd08cc17b5d3d265f08
>>
>> setExpiryTimer documentation:
>>
>> http://ndnsim.net/current/doxygen/classnfd_1_1fw_1_1Strategy.html#a967ad88184231f79b245ce202e9d4ea7
>>
>> Best regards,
>> Ashish Pradhan
>>
>>
>>
>> On Sun, Nov 25, 2018 at 2:21 AM Xinyu Ma <bitmxy at gmail.com> wrote:
>>
>>> Hello, Pradhan
>>>
>>> I’m sorry I don’t understand why you want to extend the PIT entry’s
>>> lifetime and what you mean by “data response other than the first one”.
>>> NDN follows One-Interest-One-Data, so the PIT entry should be deleted
>>> after receiving the data.
>>> You can send another Interest if you still want the PIT entry to be
>>> there.
>>>
>>> Best,
>>> Xinyu Ma.
>>>
>>> On Nov 24, 2018, at 6:20 AM, Ashish Pradhan <ashishpradhan1162 at gmail.com>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I am trying to use the setExpiryTimer to extend the PIT entry's
>>> lifetime. However the data response other than the first one is not being
>>> forwarded back to the consumer. I have included the setExpiryTimer in the
>>> beforeSatisfyInterest function as follows:
>>> "NFD_LOG_DEBUG("beforeSatisfyInterest pitEntry=" << pitEntry->getName()
>>> <<
>>>                 " inFace=" << inFace.getId() << " data=" <<
>>> data.getName());
>>>
>>>   this->Strategy::setExpiryTimer(pitEntry,
>>> ndn::time::milliseconds(100));"
>>>
>>> Is there any thing that needs to be added?
>>>
>>> After looking at the sendData function there is this line
>>> "pitEntry->deleteInRecord(outFace);". If it is deleting the inRecord how
>>> does the setExpiryTimer help to preserve the entry?
>>>
>>> Best regards,
>>> Ashish Pradhan
>>>
>>> _______________________________________________
>>> ndnSIM mailing list
>>> ndnSIM at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>
>>>
>>>
>> _______________________________________________
>> ndnSIM mailing listndnSIM at lists.cs.ucla.eduhttp://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/20181125/3d01863d/attachment.html>


More information about the ndnSIM mailing list