Feature #2458
closed
FaceMgmt: reload multicast faces
Added by Alex Afanasyev almost 10 years ago.
Updated almost 10 years ago.
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:
The only complication is that we need to remember ConfigSection for multicast faces. If it is not enabled, then no action should be performed.
- 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.
- Is duplicate of Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change added
- Description updated (diff)
- Is duplicate of deleted (Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change)
- Blocks Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change added
oops. I meant to add blocking condition...
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.
Maybe. We should make a decision after #2107.
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.
- 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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by