[ndnSIM] Using the setExpiryTImer

Sun Nov 25 01:58:06 PST 2018

This is my sendData reimplementation code(just commented the 2 lines):
void CustomStrategy::sendData(const shared_ptr<pit::Entry>& pitEntry, const
Data& data, const Face& outFace)
{
      //BOOST_ASSERT(pitEntry->getInterest().matchesData(data));

      // delete the PIT entry's in-record based on outFace,
      // since Data is sent to outFace from which the Interest was received
      //pitEntry->deleteInRecord(outFace);
      NFD_LOG_INFO("pitEntry not deleted");

      Strategy::m_forwarder.onOutgoingData(data,
*const_pointer_cast<Face>(outFace.shared_from_this()));
}
I get this error : error: ‘nfd::Forwarder& nfd::fw::Strategy::m_forwarder’
is private within this context

Best Regards,
Ashish Pradhan

On Sun, Nov 25, 2018 at 6:35 PM Ashish Pradhan <ashishpradhan1162 at gmail.com>
wrote:

> Hello Xinyu,
>
> Thank you for reaching out. Trying to send Data with “m_forwarder.
> onOutgoingData” gives an error of m_forwarder being a private member.
>
> The multiple data objects have the same name.
>
>
>
> On Sun, Nov 25, 2018 at 6:17 PM Xinyu Ma <bitmxy at gmail.com> wrote:
>
>> Hello, Pradhan
>>
>> On Nov 24, 2018, at 9:38 PM, Ashish Pradhan <ashishpradhan1162 at gmail.com>
>> wrote:
>>
>> Can't this be done simply by making a custom strategy and using the
>> setExpiryTimer? If not, where is the setExpiryTimer useful?
>>
>> In the documentation it is mentioned that "If the strategy wishes to
>> collect responses from additional upstream nodes, it should invoke
>> setExpiryTimer within this function to prolong the PIT entry lifetime.
>> If a Data arrives from another upstream during the extended PIT entry
>> lifetime, this trigger will be invoked again. At that time, this function
>> must invoke setExpiryTimer again to continue collecting more responses."
>> http://ndnsim.net/current/doxygen/classnfd_1_1fw_1_1Strategy.html#a97b4f1e5496c4dd08cc17b5d3d265f08
>>
>> Shouldn't this simply work?
>>
>>
>> Yes, this works if you only want to "prolong the PIT entry lifetime”
>> and “collecting more responses” at this node.
>> But what you need is to continue forwarding data, which means the
>> in-record of PIT entry should not be deleted.
>> In-records are deleted in the “Strategy::sendData” function, which is
>> called by “Strategy::afterReceiveData” after “beforeSatisfyInterest”
>> So if you don’t want to hack NFD, you can override “afterReceiveData” and
>> try to send Data with “m_forwarder.onOutgoingData” but not  “sendData”.
>>
>> On Sun, Nov 25, 2018 at 2:31 PM Lixia Zhang <lixia at cs.ucla.edu> wrote:
>>
>>>
>>>
>>> On Nov 24, 2018, at 9:20 PM, Ashish Pradhan <ashishpradhan1162 at gmail.com>
>>> wrote:
>>>
>>> No, the producers produces multiple data objects(not segmenting into
>>> multiple data packets).
>>>
>>>
>>> no difference: the producer knows how many total packets it produces.
>>>
>>>
>> Could you please tell me whether the multiple data objects have the same
>> name?
>> If their names are different, I think you can make it with out keep the
>> PIT entry.
>>
>> Best wishes,
>> Xinyu Ma.
>>
>>
>>>
>>> On Sun, Nov 25, 2018 at 2:15 PM Lixia Zhang <lixia at cs.ucla.edu> wrote:
>>>
>>>>
>>>> On Nov 24, 2018, at 4:08 PM, Ashish Pradhan <
>>>> ashishpradhan1162 at gmail.com> 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.
>>>>
>>>>
>>>> I would like to better understand what is going on here: do you mean
>>>> the producer app generates a data object which needs to be segmented into
>>>> multiple data packets?
>>>>
>>>> If so: yes one can find a way to hack the code to allow the bread crumb
>>>> of one Interest to retrieve multiple data packets, but it is unclear to me
>>>> a good idea to use across a network
>>>> (one interest can retrieve the first data packet, which can carry "FinalBlockId"
>>>> to inform the consumer how many more data packets to fetch).
>>>>
>>>> Lixia
>>>>
>>>> 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 list
>>>> ndnSIM at lists.cs.ucla.edu
>>>> 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/8d2b9bf1/attachment.html>