[ndnSIM] Using the setExpiryTImer

[Teng Liang]

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 <mailto: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
>>     <mailto: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
>>>         <mailto: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 <mailto:ndnSIM at lists.cs.ucla.edu>
>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>
>>
>>     _______________________________________________
>>     ndnSIM mailing list
>>     ndnSIM at lists.cs.ucla.edu  <mailto:ndnSIM at lists.cs.ucla.edu>
>>     http://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/20181124/93ddfc07/attachment-0001.html>