<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Junxiao,</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks for the explanation. So for now since LinkService part isn't implemented, in NFD therefore ndnSIM we <i>only</i> have transport for indicating a face(and a link) state. So if I set transport state to FAILED or CLOSED it will be like the actual link is DOWN, right?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Spyridon,</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Having what Junxiao said, I wonder why did you recommend to set state for Face directly. Is it to avoid getting into programming complexities?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks,</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Sabet<br> </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 10:24 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Γιαννης<div class="m_-8296657536863280995gmail_msg"><br class="m_-8296657536863280995gmail_msg"></div><div class="m_-8296657536863280995gmail_msg"><div class="m_-8296657536863280995gmail_msg">NFD face state is a combination of transport state and LinkService state.</div><div class="m_-8296657536863280995gmail_msg">The former, transport state, reports the state of the underlying socket.</div><div class="m_-8296657536863280995gmail_msg">The latter, LinkService state, reports the state as perceived by LinkService. This part is not yet implemented.</div><div class="m_-8296657536863280995gmail_msg">Face class would not set either transport state or LinkService state, but only read from them and report the combined state. It currently only reads and returns transport state because LinkService state isn't implemented.</div><div class="m_-8296657536863280995gmail_msg"><br></div><div class="m_-8296657536863280995gmail_msg">When a link becomes so lossy that communication is no longer possible, the LinkService is supposed to detect this situation (using Bidirectional Forwarding Detection, for example) and report LinkService state as DOWN. Since the socket is still connected, the transport state remains UP.</div><div class="m_-8296657536863280995gmail_msg"><br class="m_-8296657536863280995gmail_msg"></div><div class="m_-8296657536863280995gmail_msg">Yours, Junxiao</div></div></div><div class="HOEnZb"><div class="h5"><div><div class="m_-8296657536863280995gmail_msg"><div class="m_-8296657536863280995gmail_msg"><br class="m_-8296657536863280995gmail_msg"><div class="gmail_quote m_-8296657536863280995gmail_msg"><div class="m_-8296657536863280995gmail_msg">On Tue, Mar 7, 2017 at 18:29 Γιαννης Μανωλοπουλος <<a class="m_-8296657536863280995gmail_msg" href="mailto:j.manolopoulos@gmail.com" target="_blank">j.manolopoulos@gmail.com</a>> wrote:</div><blockquote class="gmail_quote m_-8296657536863280995gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-8296657536863280995gmail_msg">I am trying to model link failure between a router and a particular consumer. The consumer has issued an interest, but the link fails while awaiting for the data packet. I tried using LinkControlHelper, but it only sets the error rate of the channel to maximum and won't change consumer application's face state to DOWN. So, when the data packet arrives at the router, as far as the forwarder/strategy is concerned, it is forwarded correctly to the consumer and the pit entry gets deleted eventually, whereas I want to maintain it for the duration of InterestLifetime or at least until the link is up again (for experimental purposes).<br class="m_-8296657536863280995gmail_msg"><br class="m_-8296657536863280995gmail_msg">So I was wondering if there is a way to schedule for this particular face to change its state to DOWN at a given time, and then change it back to UP when the link is up again.<br class="m_-8296657536863280995gmail_msg"><br class="m_-8296657536863280995gmail_msg"></div></blockquote></div></div></div></div>
</div></div><br>______________________________<wbr>_________________<br>
ndnSIM mailing list<br>
<a href="mailto:ndnSIM@lists.cs.ucla.edu">ndnSIM@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank" rel="noreferrer">http://www.lists.cs.ucla.edu/<wbr>mailman/listinfo/ndnsim</a><br>
<br></blockquote></div><br></div></div>