Feature #2458
closedFaceMgmt: reload multicast faces
0%
Description
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.
We need an extension of Face Management protocol for this purpose:
new verb: reload-mcast
control parameter: empty control parameters (just to conform to the protocol)
desired effect: re-creating multicast faces
The only complication is that we need to remember ConfigSection for multicast faces. If it is not enabled, then no action should be performed.
Updated by Junxiao Shi almost 10 years ago
- Tracker changed from Task to Feature
- Subject changed from Extend FaceManagement protocol to include command to reload multicast faces to FaceMgmt: reload multicast faces
- Category changed from Management to Protocol
- Assignee set to Junxiao Shi
- Estimated time set to 1.50 h
This issue is for protocol definition only. Separate issues will be created for its implementation.
Updated by Alex Afanasyev almost 10 years ago
- Is duplicate of Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change added
Updated by Junxiao Shi almost 10 years ago
- Is duplicate of deleted (Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change)
Updated by Junxiao Shi almost 10 years ago
- Blocks Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change added
Updated by Alex Afanasyev almost 10 years ago
oops. I meant to add blocking condition...
Updated by Alex Afanasyev almost 10 years ago
On another thought. Should we simply integrate NetworkMonitor inside FaceManager? This way we wouldn't need any external thing running to trigger the reload and this extra protocol would not be necessary.
Updated by Junxiao Shi almost 10 years ago
Maybe. We should make a decision after #2107.
Updated by Davide Pesavento almost 10 years ago
Alex Afanasyev wrote:
On another thought. Should we simply integrate NetworkMonitor inside FaceManager? This way we wouldn't need any external thing running to trigger the reload and this extra protocol would not be necessary.
Yes please. I think I've already argued against the need for an external tool in the past.
Updated by Junxiao Shi almost 10 years ago
- Status changed from New to Abandoned
20150202 conference call decides to take the approach in note-7.
Alex reveals that the overhead of NetworkMonitor is:
- OSX: one poll per second
- linux: async read on an open socket
Beichuan explains that NetworkMonitor is different from DNS resolver.
- DNS resolution shouldn't be done in NFD, because it involves sending a request and waiting for the answer.
- NetworkMonitor monitors local NIC configuration. Its complexity is acceptable in NFD.