Project

General

Profile

Actions

Task #1195

closed

FaceManager

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

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Management
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
15.00 h

Description

FaceManager should implement NFD-side of the Face Management protocol.


FaceManager also acts as a config section handler for face_system section.
ConfigFileFormat contains an example config section.
When processing configuration, it should create these channels and faces:

  • one UnixStreamChannel on unix.path
    • if unix.listen is yes, start listening
  • one TcpChannel on 0.0.0.0:tcp.port
    • if tcp.listen is yes, start listening
  • one UdpChannel for unicast on 0.0.0.0:udp.port
    • always start listening
  • if udp.mcast is yes, one UdpFace for multicast per NIC
  • if ether.mcast is yes, one EthernetFace for multicast per NIC

Related issues 5 (0 open5 closed)

Related to NFD - Task #1198: nfdc: command line client of FIB and Face management protocolsClosedHila Ben Abraham

Actions
Blocked by NFD - Task #1189: UdpFace implementationClosedGiulio Grassi

Actions
Blocked by ndn-cxx - Task #1240: Implement FaceManagementOptions structureClosedYingdi Yu

Actions
Blocked by NFD - Task #1250: Face close methodClosedAlex Afanasyev

Actions
Blocked by NFD - Task #1306: Enumerate NICsClosedDavide Pesavento

Actions
Actions #1

Updated by Alex Afanasyev almost 11 years ago

  • Category set to Management
  • Target version set to v0.1
  • Start date deleted (01/31/2014)
Actions #2

Updated by Anonymous almost 11 years ago

  • Status changed from New to In Progress
  • Assignee set to Anonymous
Actions #3

Updated by Anonymous almost 11 years ago

Is anyone implementing FaceManagementOptions? If not, is there TLV support for URIs?

Actions #4

Updated by Alex Afanasyev almost 11 years ago

This hasn't been assigned to anybody yet... I will assign TLV type for Uri in a minute.

Actions #5

Updated by Anonymous almost 11 years ago

  • Status changed from In Progress to Feedback
Actions #6

Updated by Alex Afanasyev almost 11 years ago

A couple of clarifications for this task. First, FaceManager should be the first implemented manager that takes input from the config file.

Each channel inside manager needs to be identified by its type (and/or name?). The manager needs to hold a container of channels of each type, indexed by type (or type + name, or just name). When a command is received, the "protocol" part in URI is the element that identifies specific channel and its type.

We also can implement a generic Channel abstraction, which would have method "connect"/"disconnect", which would use URI as an input. Each individual channel implementation would then have customized parsing of URI to channel-specific elements.

Remote host resolving (if any) should be responsibility of the specific Channel implementation. Channel selection should be explicit via name/protocol, not host/IP specified in URI.

Actions #7

Updated by Junxiao Shi almost 11 years ago

  • Description updated (diff)
  • Estimated time set to 15.00 h

ConfigFileFormat gives an example on how channel configuration should look like.
It's important to notice that the configuration file does not define each channel explicitly, because the network environment of a laptop may change.
Instead, it just defines the port numbers, multicast IP addresses, etc.
FaceManager should use these configured options to create channels and faces.

I agree with generic Channel abstraction idea (#1261).

Assignee should update % Done field to show progress.

Actions #8

Updated by Anonymous almost 11 years ago

Alex Afanasyev wrote:

A couple of clarifications for this task. First, FaceManager should be the first implemented manager that takes input from the config file.

Should it take a ConfigFile instance or just a callback to addSectionHandler?

Each channel inside manager needs to be identified by its type (and/or name?). The manager needs to hold a container of channels of each type, indexed by type (or type + name, or just name). When a command is received, the "protocol" part in URI is the element that identifies specific channel and its type.

In order to keep this simple, it sounds like the face_system subsections should be considered names and then have a "protocol" field that specifies tcp/udp/etc.

We also can implement a generic Channel abstraction, which would have method "connect"/"disconnect", which would use URI as an input. Each individual channel implementation would then have customized parsing of URI to channel-specific elements.

It sounds like you may also want to an IpChannel class that centralizes the IPv4, v6, and hostname parsing. If so, should this be part of #1261?

Remote host resolving (if any) should be responsibility of the specific Channel implementation.

I agree, but the reason (any) resolution is happening in the face manager is because the existing channel(s) do not support v4 and v6 resolution constraints mentioned in the face manager spec.

Channel selection should be explicit via name/protocol, not host/IP specified in URI.

This is what already occurs. The host/IP portion of the URI is only consulted for the "connect", but at that point, by definition, you have already selected the channel. The problem I ran into is that the protocol portion can request resolution constraints.

Should there also be a IPv4_only and IPv6_only configuration file fields? I would like to avoid any additional parsing of the "protocol" portion of the URI and just treat it as an opaque name. The face manager should just use the "protocol" it to locate the correct channel to pass the URI to. However, the channel needs to be aware of (and support) any host resolution constraints that have been placed upon it.

(On that note, we should consider calling the "protocol" portion of the URI the "channel name" or something similar...)

Actions #9

Updated by Junxiao Shi almost 11 years ago

Config section handler should be passed to ConfigFile::addSectionHandler.

The idea of defining channel names in configuration file is rejected.
The reason is: network environment of laptop can change (eg. turn off WiFi, plug in wired network, insert new USB network adaptor). It's impractical to require static configuration.


FaceManager could just maintain pointers to ChannelFactorys, and give URI to a ChannelFactory based on its scheme name.

In both TCP and UDP, the same channel is capable of listening on both IPv4 and IPv6.
(on FreeBSD, this needs a kernel flag to work, but NFDv1 does not support FreeBSD)

TcpChannel and UdpChannel should support address resolution from an URI, and should recognize IPv4/IPv6 restriction.
This is written as Task #1279.

Actions #10

Updated by Anonymous almost 11 years ago

Junxiao Shi wrote:

Config section handler should be passed to ConfigFile::addSectionHandler.

Not quite what I'm asking (ultimately addSectionHandler has to be called for anything to happen). My question is what should the face (and other) manager constructor take: a ConfigFile instance (directly call instance.addSectionHandler) or should it just take a callback matching addSectionHandler's signature?

In the past, you've had a preference for the callback approach, but the justification was that the object in question (the forwarder) was complex to construct and would complicate unit testing. ConfigFiles are trivial to construct. Do you have any objections to passing a ConfigFile instance to the face manager?

The idea of defining channel names in configuration file is rejected.
The reason is: network environment of laptop can change (eg. turn off WiFi, plug in wired network, insert new USB network adaptor). It's impractical to require static configuration.

I'm not sure I mean the same thing that you're thinking when I say "channel names". Consider the following snippet from the configuration file example:

; the tcp section contains settings of TCP faces and channels
tcp
{
listen yes ; set to 'no' to disable TCP listener, default 'yes'
port 6363 ; TCP listener port number
}

Here, I would consider "tcp" to be both the channel name and the protocol. My assumption is that this block represents a channel. Is it something different?


FaceManager could just maintain pointers to ChannelFactorys, and give URI to a ChannelFactory based on its scheme name.

Yes on the pointers, but I need clarification on passing URIs to ChannelFactorys. Alex (above) was talking about the various Channel types' connect methods taking URIs, not the factories.

In both TCP and UDP, the same channel is capable of listening on both IPv4 and IPv6.
(on FreeBSD, this needs a kernel flag to work, but NFDv1 does not support FreeBSD)

TcpChannel and UdpChannel should support address resolution from an URI, and should recognize IPv4/IPv6 restriction.
This is written as Task #1279.

Actions #11

Updated by Junxiao Shi almost 11 years ago

FaceManager should expose a public method that could be passed to ConfigFile::addSectionHandler. FaceManager constructor takes neither.

initializeMgmt function should create both ConfigFile instance and FaceManager instance, and invoke configFile.addSectionHandler(bind(&FaceManager::onConfig, faceManager)).

In the configuration file, a subsection under face_system does not represent a channel. Instead, it contains rules to create zero or more channels, and zero or more faces.
For example, in ether subsection, a channel and a multicast face is created for each NIC. If the system has no NIC, nothing is created; if the system has multiple NICs, multiple channels and multicast faces are created.

If FaceManager does not understand details in the URI, it cannot correctly pick a channel when multiple channels are present.
Therefore, delegating this work to the channel factory is an appropriate choice.

Actions #12

Updated by Alex Afanasyev over 10 years ago

  • Assignee changed from Anonymous to Alex Afanasyev
Actions #13

Updated by Alex Afanasyev over 10 years ago

  • Status changed from Feedback to In Progress
Actions #14

Updated by Anonymous over 10 years ago

Is it ok for me to take this task back? (not sure if you have any un-pushed changes http://gerrit.named-data.net/#/c/368/)

Actions #15

Updated by Alex Afanasyev over 10 years ago

  • Assignee changed from Alex Afanasyev to Anonymous

I thought I have already re-assigned this task back to you...

Actions #16

Updated by Anonymous over 10 years ago

I noticed that the face manager's TCP section parsing is using case insensitive keyword matching. Is this something we decided on?

I ask because the authorization is case sensitive. For example, the /localhost/nfd/fib namespace corresponds to the "fib" privilege. Wouldn't /localhost/nfd/FIB (and therefore a "FIB" privilege) technically be a different namespace?

Actions #17

Updated by Anonymous over 10 years ago

I'm also unclear about what the config file UDP section comment "NFD creates one UDP multicast face per NIC" means. Should the face manager enumerate all of the machine's IP addresses and create a multicast face for each one?

Actions #18

Updated by Junxiao Shi over 10 years ago

I prefer keywords in ConfigFileFormat should be case-sensitive.

FaceManager, when processing configuration, should call NIC enumeration function (from Task #1306), and create channels according to Task Description.

Actions #19

Updated by Junxiao Shi over 10 years ago

  • Subject changed from FaceManager implementation to FaceManager

Task #1317 provides a FaceTable that could be passed to FaceManager constructor instead of three functors.

To write unit tests for FaceManager:

  • mark get/add/remove methods in FaceTable with VIRTUAL_WITH_TESTS
  • make a subclass of FaceTable that overrides these methods
  • pass the subclass of FaceTable to FaceManager constructor
Actions #20

Updated by Alex Afanasyev over 10 years ago

I'm not really sure why I implemented case-insensitive comparison. Case sensitive verb makes more sense..

Actions #21

Updated by Anonymous over 10 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 80
Actions #22

Updated by Anonymous over 10 years ago

Referencing the new NetworkInterfaceInfo, for a given NIC, does it matter which IPv4 address is used as the local IP/endpoint for creating a UDP multicast face?

Actions #23

Updated by Junxiao Shi over 10 years ago

You can pick any IPv4 address to create the IPv4 UDP multicast channel, ie. pick the first one.

If the NIC doesn't have an IPv4 address, don't create IPv4 UDP multicast channel.

Actions #24

Updated by Anonymous over 10 years ago

  • Status changed from Feedback to Code review
  • % Done changed from 80 to 100
Actions #25

Updated by Anonymous over 10 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF