[ndnSIM] Using the setExpiryTImer

Sat Nov 24 21:23:04 PST 2018

Hi Teng,
Thank you for your reply,

I was stuck in step 2 that you had mentioned before. I will now try to
remove the expiry timer check. Also I am curious that, if  there were these
additional steps required to extend the PIT entry lifetime, where is the
"already available" setExpiryTimer useful.?

Regards,
Ashish Man Singh Pradhan,

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/b3166ea8/attachment-0001.html>