[ndnSIM] Using the setExpiryTImer

Sun Nov 25 01:49:25 PST 2018

Hello,

You can build and reinstall ndnSIM as you first install it.
“./waf” will compile all parts, including NFD and ndn-cxx inside ndnSIM. No additional work.

Best,
Xinyu Ma.

> On Nov 25, 2018, at 1:44 AM, Ashish Pradhan <ashishpradhan1162 at gmail.com> wrote:
> 
> 
> 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(however, it does in reflect in the scenarios of  examples folder inside the ndnSIM ). I am not sure how to build those files(the files within NFD, ndn.cxx etc )  for them to work with my separate repository.
> 
> 
> 
> On Sun, Nov 25, 2018 at 6:42 PM Ashish Pradhan <ashishpradhan1162 at gmail.com <mailto:ashishpradhan1162 at gmail.com>> wrote:
> 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 <mailto: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 <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 <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 <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:
>> 
>> 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 <https://github.com/named-data/NFD/blob/master/daemon/fw/strategy.cpp#L203>
>> 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 <https://github.com/named-data/NFD/blob/master/daemon/fw/forwarder.cpp#L516>)
>> 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 <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 <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 <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 <http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim>
> _______________________________________________
> ndnSIM mailing list
> 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/20181125/7d07e1c0/attachment-0001.html>