Task #1195
closedFaceManager
100%
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
Updated by Alex Afanasyev almost 11 years ago
- Category set to Management
- Target version set to v0.1
- Start date deleted (
01/31/2014)
Updated by Anonymous over 10 years ago
- Status changed from New to In Progress
- Assignee set to Anonymous
Updated by Anonymous over 10 years ago
Is anyone implementing FaceManagementOptions? If not, is there TLV support for URIs?
Updated by Alex Afanasyev over 10 years ago
This hasn't been assigned to anybody yet... I will assign TLV type for Uri in a minute.
Updated by Anonymous over 10 years ago
- Status changed from In Progress to Feedback
Updated by Alex Afanasyev over 10 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.
Updated by Junxiao Shi over 10 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.
Updated by Anonymous over 10 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...)
Updated by Junxiao Shi over 10 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 ChannelFactory
s, 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.
Updated by Anonymous over 10 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
ChannelFactory
s, and give URI to a ChannelFactory based on its scheme name.
Yes on the pointers, but I need clarification on passing URIs to ChannelFactory
s. 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.
Updated by Junxiao Shi over 10 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.
Updated by Alex Afanasyev over 10 years ago
- Assignee changed from Anonymous to Alex Afanasyev
Updated by Alex Afanasyev over 10 years ago
- Status changed from Feedback to In Progress
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/)
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...
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?
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?
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.
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
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..
Updated by Anonymous over 10 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 80
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?
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.
Updated by Anonymous over 10 years ago
- Status changed from Feedback to Code review
- % Done changed from 80 to 100
Updated by Anonymous over 10 years ago
- Status changed from Code review to Closed