alexander.afanasyev at ucla.edu
Sat Mar 9 18:40:14 PST 2013
The client? Do you mean one of the ndn::Consumer* applications? These classed don't themselves generate NACKs, they can trigger NACK generation if Interests cannot be forwarded anywhere. Not sure what is the problem you are observing...
On Mar 9, 2013, at 5:47 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
> Hi Alex,
> Thanks! A little update: it seems like OK with faces (and so it was OK from the beginning), I found the error... it's really stupid, the Client generates NACKs himself when transmission queue is full...
> Is it possible to fix it somehow?
> 10.03.2013, 08:01, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>:
>> Hi Natalya,
>> Correct me if I'm wrong, but I think you should try another face when the base code cannot forward the Interest. The base version or CanSendOutInterests returns false when the node is trying to send out on the face the node has received interest from (in this case you definitely want to try another, if available), or (if retransmission detection is enabled) the node already send out interest to this phase during the current "retransmission cycle". In the latter case, it is also desirable to try another face to explore alternatives.
>> Can you try to disable m_drop_cause logic and always try to send to the next face, if CanSendOutInterest returns false, and see what happens?
>> On Mar 9, 2013, at 4:05 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
>>> Hi Alex,
>>> In my code, I added a condition at the end of CanSendOutInterest. The m_drop_cause parameter is set to 1 if CanSendOutInterest passes through this condition and returns false (i.g. node can not send Interest to the given face because the transmission queue is full and in this case I want to change the face). m_drop_cause is set to 2 if CanSendOutInterest returns false because of any existing in base code condition (like, retransmissions etc), in this case I don't want to change the face and node should just behaves normally.
>>> But I check this m_drop_cause parameter and it is equal to 1 but node doesn't try to find the next face (he enters to the condition if(m_drop_cause == 1) continue; but then just exits, it seems like there are no more available faces).
>>> Oh, yes, I use i_metric. The i_nth was just the last attempt to see if it can change anything.
>>> 10.03.2013, 06:16, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>:
>>>> Hi Natalya,
>>>> NACKs would be generated if DoPropagateInterest return false. TrySendOutInterest method makes an attempt to send out interest over the face and in your code I see that attempt to try next face would be aborted if m_drop_cause is not equal to 1 (e.g., if it is 1, only one face should be tried in most of the cases). Is this m_drop_cause a configuration parameter or something that is set for each attempt?
>>>> Another side question. Are you intentionally not using metric to rank faces (fib::i_nth instead of fib::i_metric)?
>>>> On Mar 9, 2013, at 1:47 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
>>>>> Hi Alex,
>>>>> I want to re-send an Interest to next available face if the current one is unavailable because of any special reason. I trace the second face and see that it receives rerouted Interests but sometimes I see that the node generates a NACK rather than resend the Interest to the next face (it even doesn't try to choose the next face and just exits from DoPropagateInterest function ). So, there is something wrong in my implementation or in manually generated FIB... Could you tell me please, do I use a correct way for changing faces?
>>>>> I rewrite DoPropagateInterest function and choose the interface as follows:
>>>>> BOOST_FOREACH (const fib::FaceMetric &metricFace, pitEntry->GetFibEntry ()->m_faces.get<fib::i_nth> ())
>>>>> if (!TrySendOutInterest (inFace, metricFace.m_face, header, origPacket, pitEntry))
>>>>> if(m_drop_cause == 1)
>>>>> else break;
>>>>> return propagatedCount > 0;
>>>>> Is it correct and the problem should not come from this piece?
>>>>> ndnSIM mailing list
>>>>> ndnSIM at lists.cs.ucla.edu
>>> ndnSIM mailing list
>>> ndnSIM at lists.cs.ucla.edu
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ndnSIM