Reinitialize multicast faces when connectivity changes
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).
#3 Updated by Davide Pesavento over 5 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?
#5 Updated by Davide Pesavento over 5 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.
#6 Updated by Alex Afanasyev over 5 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.