Address book ordering, and private addresses

[JustinDrake]

The AddrBook handles a slice of multiaddresses ([]ma.Multiaddr). I was wondering if the ordering is intended to be meaningful, e.g. if the top multiaddresses are to be prioritised somehow over the next?

When printing the multiaddresses of example node QmaeXrsLHWm4gbjyEUJ4NtPsF3d36mXVzY5eTBQHLdMQ19 I get the following:

/ip4/127.0.0.1/tcp/4737
/ip4/172.17.0.1/udp/4737/utp
/ip4/127.0.0.1/udp/4737/utp
/ip6/::1/udp/4737/utp
/ip4/5.9.150.40/udp/4737/utp
/ip4/5.9.150.40/tcp/4737
/ip6/::1/tcp/4737
/ip4/172.19.0.1/udp/4737/utp
/ip6/fc20:a50b:75c2:bca3:be34:5c8c:c65d:7643/tcp/4737
/ip4/172.20.0.1/udp/4737/utp
/ip4/172.17.0.1/tcp/4737
/ip6/fc20:a50b:75c2:bca3:be34:5c8c:c65d:7643/udp/4737/utp
/ip6/2a01:4f8:190:3327::2/tcp/4737
/ip6/2a01:4f8:190:3327::2/udp/4737/utp
/ip4/172.19.0.1/tcp/4737
/ip4/172.18.0.1/udp/4737/utp
/ip4/172.20.0.1/tcp/4737
/ip4/172.18.0.1/tcp/4737

In the list above most of the multiaddresses use private IP addresses (127.0.0.1 and ::1 loopback addresses, and class B private IPs in the range 172.16.0.0 - 172.31.255.255). What is the point of communicating and storing all these private addresses? Presumably most of the time these are irrelevant addresses and should be skipped.

[chpio]

im getting

/ip6/::1/tcp/4737 
/ip4/172.19.0.1/tcp/4737 
/ip6/2a01:4f8:190:3327::2/tcp/59168 
/ip4/5.9.150.40/udp/4737/utp 
/ip4/172.18.0.1/udp/4737/utp 
/ip6/fc20:a50b:75c2:bca3:be34:5c8c:c65d:7643/udp/4737/utp 
/ip4/172.20.0.1/tcp/4737 
/ip4/172.18.0.1/tcp/4737 
/ip4/5.9.150.40/tcp/4737 
/ip6/2a01:4f8:190:3327::2/tcp/4737 
/ip4/127.0.0.1/udp/4737/utp 
/ip6/2a01:4f8:190:3327::2/udp/4737/utp 
/ip4/172.20.0.1/udp/4737/utp 
/ip6/2a01:4f8:190:3327::2/tcp/33680 
/ip6/2a01:4f8:190:3327::2/tcp/38796 
/ip4/172.19.0.1/udp/4737/utp 
/ip6/fc20:a50b:75c2:bca3:be34:5c8c:c65d:7643/tcp/4737 
/ip4/172.17.0.1/udp/4737/utp 
/ip6/2a01:4f8:190:3327::2/tcp/58418 
/ip4/172.17.0.1/tcp/4737 
/ip4/127.0.0.1/tcp/4737 
/ip6/2a01:4f8:190:3327::2/tcp/35126 
/ip6/::1/udp/4737/utp 

for this node but what are those random ports?

And that's the swarm config for it:

    "Swarm": [
      "/ip4/0.0.0.0/tcp/4737",
      "/ip4/0.0.0.0/udp/4737/utp",
      "/ip6/::/tcp/4737",
      "/ip6/::/udp/4737/utp"
    ]

Also it would be nice if there were a config for binding to an interface instead of IPs. As in my case the node is running on a server with static IPs (and no NAT/private networking) so there is really no need for the private IPs to be announced.

[Kubuxu]

You can manually bind to specific IPs (and thus interfaces) by giving non wildcard IPs in the config.

[whyrusleeping]

@chpio Yeah, set your swarm addresses to use /ip4/YOUR STATIC IP/tcp/PORT instead of 0.0.0.0. It should have the intended effect

[raulk]

We currently don't sort addresses in any specific manner, e.g. priorities. We don't filter addresses either. The peerstore just swallows whatever the caller provides.

@whyrusleeping @Stebalien different possibilities from my point of view:

1. It is the responsibility of the application to track the addresses it wants to.
2. Users can set "AddressFilter" function on the peerstore to discard incoming addresses.

Any thoughts on ordering addresses?

[Stebalien]

Relevant: libp2p/go-libp2p-swarm#57.

I like the idea of pushing filters down into the peerstore but I'm worried about the DHT. We currently use the peerstore for peer-routing information. On the other hand, this already causes problems due to multiformats/multiaddr#70. Furthermore, we've discussed storing records used for peer-routing separately for libp2p/libp2p#47.

However, even if we do sort them in the peerstore, we'd still likely need some logic in the dialer to delay dialing "expensive" addresses (see the swarm dial issue above).

[marten-seemann]

1. It is the responsibility of the application to track the addresses it wants to.

Agreed. The peerstore stores addresses, it's not the responsibility to sort addresses. Different applications will most likely have different sorting functions anyway.