NFD

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

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

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.

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

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.

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.

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.

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/)

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?

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?

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.

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

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?

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.