[Nfd-dev] Help needed with PyNDN2

[Lan Wang (lanwang)]

Jeff,

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.

Lan
On Sep 8, 2014, at 6:27 PM, "Thompson, Jeff" <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

Hi Lan,

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".

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.

- Jeff T

From: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Date: Wednesday, September 3, 2014 2:26 PM
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "Ashlesh Gawande (agawande)" <agawande at memphis.edu<mailto:agawande at memphis.edu>>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Subject: Re: [Nfd-dev] Help needed with PyNDN2

Junxiao: Thank you for the explanation.

Jeff: what's the behavior of PyNDN2 when nfd crashes?

Lan
On Sep 2, 2014, at 7:25 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Ashlesh

I don't known PyNDN so I cannot answer the specific question.
The answer below is applicable to library design in general.

A client library can choose what to do when the forwarder has crashed.
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.
ndn-cxx chooses to have this behavior, because ndn-cxx developers believe that an application is useless when the forwarder is down.
This means, when NFD is closing, all ndn-cxx applications connected to NFD will crash as well.
An external monitoring script can detect this, and restart NFD, followed by applications.
This behavior is acceptable on servers for those applications that don't have much internal states.

However, it's undesirable to let a user-facing application crash when NFD is closing.
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.
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.
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).

Yours, Junxiao

On Tue, Sep 2, 2014 at 5:08 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:
Hi

I was working with PyNDN2 library which uses NFD.

In PyNDN2 Is there a way to check if NFD has gone down (or should there be a way to that in the library) ?
If so how can it be done?

(I have added the conversation I had with Jeff T)

Thanks
Ashlesh

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/88438138/attachment.html>