<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Jeff,
<div><br>
</div>
<div>Thank you very much. We are wondering if it is possible for the library to inform the producer when nfd crashes. Right now we'll have to rely on periodically getting the nfd-status to see if the prefix is still registered.</div>
<div><br>
</div>
<div>Lan<br>
<div>
<div>On Sep 8, 2014, at 6:27 PM, "Thompson, Jeff" <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Hi Lan,</div>
<div><br>
</div>
<div>The PyNDN2 default constructor for Face makes a Unix socket connection to the local NFD. Therefore, if NFD crashes, the next attempt by the consumer application to send an interest to NFD gets "socket.error: [Errno 32] Broken pipe".</div>
<div><br>
</div>
<div>This might be easy to detect. However, the producer application makes a connection and waits for NFD to send an interest to the application. If NFD crashes, it simply never gets an interest or an error.</div>
<div><br>
</div>
<div>- Jeff T</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223); ">
<span style="font-weight:bold">From: </span>"Lan Wang (lanwang)" <<a href="mailto:lanwang@memphis.edu">lanwang@memphis.edu</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, September 3, 2014 2:26 PM<br>
<span style="font-weight:bold">To: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"Ashlesh Gawande (agawande)" <<a href="mailto:agawande@memphis.edu">agawande@memphis.edu</a>>, Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Help needed with PyNDN2<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Junxiao: Thank you for the explanation.
<div><br>
</div>
<div>Jeff: what's the behavior of PyNDN2 when nfd crashes?</div>
<div><br>
</div>
<div>Lan<br>
<div>
<div>
<div>On Sep 2, 2014, at 7:25 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Hi Ashlesh
<div><br>
</div>
<div>I don't known PyNDN so I cannot answer the specific question.</div>
<div>The answer below is applicable to library design in general.</div>
<div><br>
</div>
<div>A client library can choose what to do when the forwarder has crashed.</div>
<div>In most cases, the library would crash or raise an error if the connection to the server is lost. This is common among popular client libraries such as libmysql.</div>
<div>ndn-cxx chooses to have this behavior, because ndn-cxx developers believe that an application is useless when the forwarder is down.<br>
</div>
<div>This means, when NFD is closing, all ndn-cxx applications connected to NFD will crash as well.</div>
<div>An external monitoring script can detect this, and restart NFD, followed by applications.</div>
<div>This behavior is acceptable on servers for those applications that don't have much internal states.</div>
<div><br>
</div>
<div>However, it's undesirable to let a user-facing application crash when NFD is closing.</div>
<div>The application can catch the error raised by the library, and periodically attempt to connect the Face until a new connection is established, and then register the prefixes.<br>
</div>
<div>Alternatively, the library can choose to detect the problem, and attempt to recover. If a library chooses to do this, it should still inform the application through the event or callback system when forwarder becomes unavailable and available again.</div>
<div>In both cases, the application may need to recover network-visible states after forwarder recovery (eg. ChronoSync entity may need to rejoin the sync-group).</div>
<div><br>
</div>
<div>
<div class="gmail_extra">Yours, Junxiao<br>
<br>
<div class="gmail_quote">On Tue, Sep 2, 2014 at 5:08 PM, Ashlesh Gawande (agawande)
<span dir="ltr"><<a href="mailto:agawande@memphis.edu" target="_blank">agawande@memphis.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" type="cite">
Hi<br>
<br>
I was working with PyNDN2 library which uses NFD.<br>
<br>
In PyNDN2 Is there a way to check if NFD has gone down (or should there be a way to that in the library) ?<br>
If so how can it be done?<br>
<br>
(I have added the conversation I had with Jeff T)<br>
<br>
Thanks<br>
Ashlesh<br>
<br>
</blockquote>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span></div>
</blockquote>
</div>
<br>
</div>
</body>
</html>