Auto relay connection

[dariusc93]

Should add a option to add listen on a relay automatically while behind a NAT. This would allow us to walk through DHT and find any peers that has the relay v2 protocol in which case we would then listen to it automatically. There are a couple of things that might need to be done

1. Build up a map to keep track of active peers with the relay protocol
2. Determine the max number we can and should listen on (eg does it do anything to listen on multiple relays as been done manually?).
3. Only use relays when behind a nat or firewall, otherwise dont use relays unless connection is being blocked in some way.
4. Track the ListenId after doing Swarm::listen_on and use it to remove the listener when there is an issue related to it

Draft should be first implemented into this crate and once its figured out to split it out into its own crate (or implement directly into libp2p?).

[dariusc93]

This will be done inside of a behaviour which would allow static relays (one users can add themselves) as well as an option to add relays while walking DHT.

Thought: (WIP - not exactly final and may not reflect actual implementation)

Overall:

• Add relay (peer and their multihash) to a map as pending and initiate a connection to their multiaddr.

  • The peer multiaddr must not contain a p2p-circuit or otherwise behind a relay otherwise it will be rejected
    • Doubt a peer behind a relay can also act as an relay too, but something to question in the future but not an intended feature here.
  • Will accept both tcp and udp (depends on configuration between v1 or draft-29 - will not accept both)
    • Note that at this time quic in rust-libp2p does not support dcutr.
  • Relay must be dial-able. It will be rejected if not.
    • Local and lan addr will be accepted but the multiaddr may be rejected in the future (unless there is some usecase for using relays locally)
  • Once connected and reservation is accepted, store in a separate list of possible relays to use.
  • Relay must support relay v2 (STOP) protocol. Client must support relay v2 (HOP)
    • rust-libp2p no longer supports v1 (and v1 will be depreciated in go-ipfs soon if not already done so).

• Monitor relays and measure their avg ping. Any relays that have an extremely high avg ping for a long duration, timeout or disconnect will be removed from the candidate list

• Update identify on each change (may require push in identify to be enabled so this is done automatically unless there is a way to do that through the behaviour)

Static Relays:

• Have no limit to how many can be added (since the developer or their application would be in control on their end)
• Can switch between relays (selectable by peerid although if the peer has multiple addresses used for a relay, it may select one that suited the best based on the conditions above)

Dynamic (or auto) Relays:

• Will contain a fixed limit, determined by configuration (if not by a variable). This is to prevent storing and managing hundred, of not more, of relays and creating unnecessary connections.
• Relays will be obtained via DHT by walking through and finding peers with the relay v2 STOP protocol.
• Monitor and swap relays out regularly with the best ones discovered
  • If a relay is being used already, we wont swap it out unless it doesnt meet the conditions above

Questions:

1. In the event of peers not using DHT, should we allow peers to share their relays with each other? Possibly through request-response protocol? Not really needed in the short or long term though but might be a nice thing to have for exchanging relays and building up one own list in the event of DHT not being used.
2. Should we allow both static and dynamic relays or have it so one or the other (but not both) could be used?
3. Should we build on top of relay protocol or should be keep this separate from the protocol and incorporate it into the swarm at specific events points?
4. Should a single candidate limit be per peer id (which would contains multiple addresses) or per address?
5. Although should not be relied on, should we have the default relays set for ipfs/libp2p bootstrap?
   • Note that while this is possible, there may be times where they may not be suitable for being used as relays so maybe we shouldnt default to them.
6. How would connection limits impact relay usage? libp2p does not have a connection manager at this time (see swarm/: Support generic connection management libp2p/rust-libp2p#2824) but should probably give the relays a higher priority connection over others so if the connection limit is ever reached, we could drop unnecessary connections to try to sustain the relay list (may have to have our own form of connection manager until one is implemented upstream)
7. What will the impact be in regards to bitswap? Max block size is 2MB but relay v2 may have much lower data restrictions and unless DCUtR is used (and hole punching has been successful in the case of use), would likely drop packets.

Reference:
libp2p/rust-libp2p#2944
https://github.com/libp2p/go-libp2p/blob/031ec50a04507cb2def993ef0ad15cf95eb98922/p2p/host/autorelay/options.go#L37-L45 (Thanks mxinden)
https://github.com/libp2p/go-libp2p/blob/031ec50a04507cb2def993ef0ad15cf95eb98922/p2p/host/autorelay/relay_finder.go#L71-L73

[dariusc93]

autorelay was moved to https://github.com/dariusc93/libp2p-autorelay though will leave this issue open for the time being since there is still more to do.