NFD

I believe the correct (and most flexible) way to do this on Linux would be to listen to rtnetlink(7) notifications from the kernel.

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.

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?

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.

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.

I don't have time to do this task by June 8th (v0.2 deadline)

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.