{swarm,core}/: Allow specifying the role of a connection in NetworkBehaviourAction::Dial

[mxinden]

The Direct Connection Upgrade through Relay protocol (#2076) tries to establish a connection between two peers by synchronizing the two such that they can simultaneously attempt to establish a connection. Steps required by the two peers differ by transport protocol (e.g. TCP and QUIC) and role (client and server). See excerpt from the specification below:

5. Simultaneous Connect. The two nodes follow the steps below in parallel for
   every address obtained from the Connect message:
   • For a TCP address:
     • Upon receiving the Sync, A immediately dials the address to B.
     • Upon expiry of the timer, B dials the address to A.
     • This will result in a TCP Simultaneous Connect. For the purpose of all
       protocols run on top of this TCP connection, A is assumed to be the
       client and B the server.
   • For a QUIC address:
     • Upon receiving the Sync, A immediately dials the address to B.
     • Upon expiry of the timer, B starts to send UDP packets filled with
       random bytes to A's address. Packets should be sent repeatedly in
       random intervals between 10 and 200 ms.
     • This will result in a QUIC connection where A is the client and B is
       the server.

https://github.com/libp2p/specs/blob/master/relay/DCUtR.md#the-protocol

In the case of TCP B needs to act as a listener once a connection is successfully established. Note that the TCP stack will treat both A and B as dialers as the connection will be a simultaneous TCP connection.

In the case of QUIC B needs to send random bytes instead of a connection attempt and then once a connection is established needs to act as a listener just like in the case of TCP.

Code in and based on libp2p-swarm does not need to be concerned with these implementation details. Instead, a single flag on NetworkBehaviourAction::Dial, indicating to the Swarm and libp2p-core that the conection to be established should be treated from the role of a listener, is sufficient.

To reduce conflicts, I would suggest tackling this once #2249 is fixed.

[dvc94ch]

Doesn't sim-open already take care of this?

[mxinden]

Doesn't sim-open already take care of this?

Yes, but with an additional round-trip. The two peers already have an established channel via which they can coordinate the role (see spec excerpt above), thus there is no need for the additional negotiation via Mulistream Select Sim Open. Let me know if that makes sense to you.

[dvc94ch]

Ah now I understand, thanks for explaining