Project

General

Profile

Actions

Feature #3471

closed

nfdc create: allow specifying local URI

Added by Davide Pesavento over 8 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
Normal
Category:
Tools
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

In nfdc create command, add an optional parameter that specifies the local URI to be used for the created face.

In practice, the local URI is used to choose an appropriate channel. If no suitable channel is found, an error is returned. If the local URI scheme differs from the remote URI scheme, an error is returned. If the local URI is not specified, the current behavior of automatically choosing a channel is preserved.


Related issues 1 (0 open1 closed)

Has duplicate NFD - Feature #4017: nfdc face create: LocalUriClosedJunxiao Shi

Actions
Actions #1

Updated by Junxiao Shi over 8 years ago

What's the use case?

faces/create command only supports UDP unicast and TCP unicast.
There is exactly one channel for each of udp4, udp6, tcp4, tcp6.

Actions #2

Updated by Davide Pesavento over 8 years ago

The use case we have in mind is creating multiple UDP faces towards the same remote endpoint, each of them using a separate local network interface. This requires allocating one channel per IP address, or at least one channel per interface, in the local NFD.

Actions #3

Updated by Junxiao Shi over 8 years ago

The use case described in note-2 has additional dependencies. Can Davide join an NFD call to discuss?

Actions #4

Updated by Davide Pesavento over 8 years ago

Indeed, several things are needed to obtain the goal described in note-2, this is one of them. If needed, we can open separate tickets for the others, as they affect different components of NFD.

Andrea and I can definitely join a call to discuss our use case and rough solution, it's entirely possible that we're attacking the problem from the wrong angle. When? Next Tuesday?

Actions #5

Updated by Davide Pesavento over 8 years ago

Also, let me clarify one thing here first. I realized that we don't really need/want to specify the local URI (e.g. in terms of local IP address), what we want is to specify which system network interface will be used by the created face, and then the face will keep using that interface even if its IP address changes. In a way, this would be similar to the -I option of ping(8).

Actions #6

Updated by Alex Afanasyev over 8 years ago

Davide, this would have multiple complication, as it doesn't just depend on nfdc, but also on management protocol, face manager, protocol factory, and may be something else.

Do you really need to create multiple UDP faces to the same destination from the same NFD? Is it for some kind of debugging purposes?

Actions #7

Updated by Davide Pesavento over 8 years ago

Alex Afanasyev wrote:

Davide, this would have multiple complication, as it doesn't just depend on nfdc, but also on management protocol, face manager, protocol factory, and may be something else.

Yeah I'm aware of that. Andrea already has a (minimal and unpolished) implementation of almost all of the above for the UDP case. We're going to start using it in our V2I experiments asap.

Do you really need to create multiple UDP faces to the same destination from the same NFD?

Yes, we do. And not for debugging.

Actions #8

Updated by Davide Pesavento over 8 years ago

Davide Pesavento wrote:

Andrea and I can definitely join a call to discuss our use case and rough solution, it's entirely possible that we're attacking the problem from the wrong angle. When? Next Tuesday?

Ping?

Actions #9

Updated by Junxiao Shi over 8 years ago

  • Status changed from New to Rejected

@Davide explains the use case on 20160308 conference call: a mobile device with multiple physical network interfaces (cellular and WiFi) wants to connect to the same set of NDN gateway routers.

We decide that creating such faces through FaceMgmt commands would require an external process to watch for NIC additions and removals, and it's better to let NFD itself maintains these faces similar to Ethernet multicast faces.

Thus, this feature is replaced by #3521.

Actions #10

Updated by Davide Pesavento over 7 years ago

Actions

Also available in: Atom PDF