Project

General

Profile

Feature #2417

tool/daemon to re-run ndn-autoconf when connectivity changes

Added by Alex Afanasyev over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Tools
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

In the past we were relying on NDNx Control Center to run local hub detection and configuration. However, we don't need to rely on such external tool and can bundle its functionality as part of NFD package. This tool would have platform-dependent implementation (dbus on Linux and SystemConfiguration Framework on OSX).

Code examples are in NFD control center repository (http://gerrit.named-data.net/#/admin/projects/NFD-Control-Center)


Related issues

Related to NFD - Bug #2459: ndn-autoconfig (daemon mode): non-deterministic timeouts for DNS resolutionNew

History

#1 Updated by Junxiao Shi over 4 years ago

  • Tracker changed from Task to Feature
  • Subject changed from Tool/daemon to re-run ndn-autoconf when connectivity changes to tool/daemon to re-run ndn-autoconf when connectivity changes

Shouldn't this be placed in upstart script?

#2 Updated by Alex Afanasyev over 4 years ago

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.

#3 Updated by Junxiao Shi over 4 years ago

What about adding a daemon mode to ndn-autoconf?

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

#4 Updated by Alex Afanasyev over 4 years ago

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.

#5 Updated by Alex Afanasyev over 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Alex Afanasyev
  • % Done changed from 0 to 40

#6 Updated by Alex Afanasyev over 4 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 40 to 100

#7 Updated by Alex Afanasyev over 4 years ago

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

#8 Updated by Alex Afanasyev over 4 years ago

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.

#9 Updated by Junxiao Shi over 4 years ago

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.

#10 Updated by Alex Afanasyev over 4 years ago

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

#11 Updated by Alex Afanasyev over 4 years ago

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

#12 Updated by Alex Afanasyev over 4 years ago

  • Related to Bug #2459: ndn-autoconfig (daemon mode): non-deterministic timeouts for DNS resolution added

#13 Updated by Alex Afanasyev over 4 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF