Project

General

Profile

Actions

Feature #2458

closed

FaceMgmt: reload multicast faces

Added by Alex Afanasyev almost 10 years ago. Updated almost 10 years ago.

Status:
Abandoned
Priority:
Normal
Assignee:
Category:
Protocol
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
1.50 h

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.


Related issues 1 (0 open1 closed)

Blocks NFD - Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration changeClosedAlex Afanasyev

Actions
Actions #1

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.

Actions #2

Updated by Alex Afanasyev almost 10 years ago

  • Is duplicate of Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change added
Actions #3

Updated by Alex Afanasyev almost 10 years ago

  • Description updated (diff)
Actions #4

Updated by Junxiao Shi almost 10 years ago

  • Is duplicate of deleted (Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change)
Actions #5

Updated by Junxiao Shi almost 10 years ago

  • Blocks Feature #2460: FaceManager: add/remove multicast faces upon local NIC configuration change added
Actions #6

Updated by Alex Afanasyev almost 10 years ago

oops. I meant to add blocking condition...

Actions #7

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.

Actions #8

Updated by Junxiao Shi almost 10 years ago

Maybe. We should make a decision after #2107.

Actions #9

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.

Actions #10

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.
Actions

Also available in: Atom PDF