NFD

I suggest encoding the local address in "username" part of FaceUri:

udp4://192.0.2.1@224.0.23.170:56363
ether://eth1@33:33:01:01:01:01

and deleting the definition for "udp-mcast" and "ether-mcast" schemes in FaceMgmt.

Junxiao's suggestion sounds good to me, although we're kind of abusing the URI syntax.

Junxiao Shi wrote:

Accepted UNIX stream face does not have a meaningful remote endpoint.

struct sockaddr_un from accept(2) is same as local endpoint, so it's unsuitable as remote FaceUri.

What shall we put as remote FaceUri?

'ss -px' can display some information about the peer of a Unix domain socket connection, I don't know where it gets that info from though... it might be some Linux-specific kernel structures...

In my opinion using the fd is sufficient for our purposes (and still gives useful info for debugging e.g. through strace)

Ethernet local endpoint is identified by device name.

Should we define another FaceUri scheme to represent device name, or should we use local MAC address?

Using the local MAC address is ambiguous if virtual interfaces are present. The device name is the only unique identification as far as I know.

We have a machine that looks like:

shijunxiao@hostname:~$ ip link
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:25:90:xx:xx:xx brd ff:ff:ff:ff:ff:ff
shijunxiao@hostname:~$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:25:90:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 128.196.xx.xx/xx brd 128.196.xx.xx scope global eth0
    inet 10.192.xx.xx/xx brd 10.192.xx.xx scope global eth0:1
shijunxiao@hostname:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:25:90:xx:xx:xx  
          inet addr:128.196.xx.xx  Bcast:128.196.xx.xx  Mask:255.255.xx.xx

eth0:1    Link encap:Ethernet  HWaddr 00:25:90:xx:xx:xx  
          inet addr:10.192.xx.xx  Bcast:10.192.xx.xx  Mask:255.255.xx.xx

ifconfig shows same MAC address on eth0 and eth0:1.

Does virtual interface refer to "eth0:1" of this machine?

If so, we shouldn't even allow Ethernet communication on "eth0:1",
because it would show up as same source MAC address on the receiving end, and cause problem with NDNLP (after adding fragmentation).

If virtual interface refers to something else, please cite a document.

Junxiao Shi wrote:

Does virtual interface refer to "eth0:1" of this machine?

Technically those are aliases [1], and while they can be called "virtual" because they don't correspond to any physical interface, I wasn't referring to them. Sorry for being too vague.

What I was talking about was mainly the 802.1q and 802.1ad VLAN interfaces [2], that have the same mac address but different interface names (usually eth0.${vlan_id}).

There are also other types of virtual interfaces (veth, macvlan, bonding, ...) but those have different mac addresses too, so the uniqueness issue doesn't exist there.

[1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/alias.txt

[2] https://wiki.archlinux.org/index.php/VLAN

I would also use device name to identify local Ethernet endpoint (dev:// or what you have mentioned before during the call).

Davide Pesavento wrote:

'ss -px' can display some information about the peer of a Unix domain socket connection, I don't know where it gets that info from though... it might be some Linux-specific kernel structures...

A ucred structure (containing pid, uid, gid) for the peer process connected to a local socket can be obtained via getsockopt(fd, SOL_SOCKET, SO_PEERCRED, ...) on Linux. Unfortunately on Mac OS X only the uid and gid are available, via getpeereid(3).

Yes. That would make sense. Steve was suggesting to make a nested TLV (FaceInfo), but this is probably overkill here, since it is used in just two places

FaceStatus block has FaceFlags field added.