Task #1584
closed
Reinitialize multicast faces when connectivity changes
100%
Description
Right now, NFD requires to be restarted when new interface is added or new address is assigned on interface (otherwise UDP multicast may not correctly work).
NFD needs to handle HUP signal, which will be send by some other process when network connectivity changes (upstart on Ubuntu, NDN control center or some other daemon on OSX).
Updated by Davide Pesavento over 10 years ago
I believe the correct (and most flexible) way to do this on Linux would be to listen to rtnetlink(7) notifications from the kernel.
Updated by Junxiao Shi over 10 years ago
A process other than NFD itself (eg. the control center) can detect NIC changes by rtnetlink notification, hooking to ifupdown, or other mechanisms. It then sends a signal to NFD when a change is detected.
NFD only needs to wait for the signal.
Updated by Davide Pesavento over 10 years ago
Junxiao Shi wrote:
NFD only needs to wait for the signal.
Wait for the signal and do what exactly? How is a "connectivity change" defined? Say for example that the IPv6 address of an interface changes, will this be notified to NFD? Will NFD close and reopen the multicast UDP face, potentially losing packets, even if there's no need to do so?
Updated by Junxiao Shi over 10 years ago
In case of an IPv6 address change, NFD is still notified. It should compare the new set of NIC information with the old one, and compute the minimal set of actions: close TCP and UDP tunnels whose local endpoint is the old IPv6 address.
Updated by Davide Pesavento over 10 years ago
I don't understand why you want to complicate things... Conflating the various specific notifications into a generic one (SIGUSR1) that doesn't say what has actually changed, then retrieving again the whole configuration of all network interfaces, and finally comparing it to the previous state (not trivial). All of this just to learn something that you already knew at the beginning but you chose to discard...
The only advantage of doing it this way is that the implementation on the NFD side is mostly platform-agnostic (thanks to boost signal handling and to listNetworkInterfaces). But you still need to have "something" on every platform that can send a signal or run a script every time the network configuration changes.
Updated by Alex Afanasyev over 10 years ago
- Assignee set to Davide Pesavento
Detection of network change is not a precise operation. On neither platform you can reliably detect what exactly has changed, so you will have to go over the current status and try to figure out the differences. The only relative reliable signal is that network has changed, but it is just a binary signal.
Junxiao proposed to use command interests to send such a signal from an external app (yes, this still should be an external app. This either upstart/systemd, or special daemon---we already have osx and ubuntu implementation). It is possible, but it seems to be more complicated than just processing a signal.
Updated by Davide Pesavento over 10 years ago
I don't have time to do this task by June 8th (v0.2 deadline)
Updated by Junxiao Shi over 10 years ago
- Assignee changed from Davide Pesavento to Alex Afanasyev
20140530 conference call decides to assign this to Alex. If he doesn't have time to complete this task, we'll have to defer it to next version.
Updated by Alex Afanasyev over 10 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
- Estimated time set to 8.00 h
Updated by Alex Afanasyev over 10 years ago
- Status changed from In Progress to Code review
- % Done changed from 10 to 100
Updated by Alex Afanasyev over 10 years ago
The processed signal is changed to HUP, since the current implementation not just reload multicast faces, but reloads the configuration file, including reload of multicast faces. HUP is the standard signal for such operations.
Updated by Junxiao Shi over 10 years ago
- Subject changed from Reinitialize multicast faces when connectivity changes (on USR1 signal) to Reinitialize multicast faces when connectivity changes
- Description updated (diff)
- Start date deleted (
05/09/2014)
Updated by Alex Afanasyev over 10 years ago
- Status changed from Code review to Closed