[Nfd-dev] Fwd: Re: Help needed with PyNDN2

Junxiao Shi shijunxiao at email.arizona.edu
Tue Sep 2 17:25:25 PDT 2014


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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140902/69eed5fc/attachment.html>


More information about the Nfd-dev mailing list