NFD

On Ubuntu (up until it switches to systemd) it is possible, but only if one installs from PPA packages (I'm not aware of anybody else with source install that uses upstart scripts).

With systemd is probably also possible, but the same problem---somebody needs to configure it when installing from source, which may or may not be trivial.

On OSX, you have to use a separate daemon application to do the job. launchd doesn't provide this functionality natively.

Having an extra (and optional) tool just expands, simplifies, and unifies hub discovery operation.

What about adding a daemon mode to ndn-autoconf?

What about running ndn-autoconf in a cron job every 5 minutes?

What about adding a daemon mode to ndn-autoconf?

That's possible and I think better than a separate daemon I was thinking about.

What about running ndn-autoconf in a cron job every 5 minutes?

No. I don't like this. Autoconfig should be run as soon as network connectivity changes. These are the events that we know how to handle and I see no reason not to use such functions. Running every 5 minutes can be in addition, to guarantee that connectivity detection failures do not prevent the procedure to run.

The current implementation of ndn-autoconf uses res_query and res_search methods that block thread execution for non-deterministic amount of time. If machine has connectivity to DNS servers, then there is no problem. I tested on my machine when I disconnected from the network and I couldn't quite get how long should I wait till the function actually finishes...

I would like to open search for boost::asio-driven DNS search. Alternatively, I would use dig command, instead of res_query and res_search API methods...

There is another issue, which may be handled as part of this task. When network connectivity changes, NFD may lose multicast faces.

As part of #1584 we implemented NFD to process HUP signal to re-initialize faces. However, one needs to be least the same user to send such a signal... I think we need a new management protocol for this feature, or at the very least extend FaceManagement protocol.

The current implementation of ndn-autoconf uses res_query and res_search methods that block thread execution for non-deterministic amount of time. If machine has connectivity to DNS servers, then there is no problem. I tested on my machine when I disconnected from the network and I couldn't quite get how long should I wait till the function actually finishes...

I would like to open search for boost::asio-driven DNS search. Alternatively, I would use dig command, instead of res_query and res_search API methods...

res_query doesn't seem to allow setting timeout.

But using Boost.Asio driven DNS means another dependency. What about running res_query in a separate thread?

There is another issue, which may be handled as part of this task. When network connectivity changes, NFD may lose multicast faces.

As part of #1584 we implemented NFD to process HUP signal to re-initialize faces. However, one needs to be least the same user to send such a signal... I think we need a new management protocol for this feature, or at the very least extend FaceManagement protocol.

I agree with extending FaceMgmt to have faces/reload-mcast command, but it shall be separate issues.

I would like to open search for boost::asio-driven DNS search. Alternatively, I would use dig command, instead of res_query and res_search API methods...

res_query doesn't seem to allow setting timeout.

But using Boost.Asio driven DNS means another dependency. What about running res_query in a separate thread?

But that would mean that we would need to kill the spanned tread not in a nice way, with or without consequences...

I think we should merge the pending change, but I will create another issue to find solution for DNS timeout problem.