split the Transport trait

[Sherlock-Holo]

Description

split the Transport into Listen and Dial 2 traits

Motivation

currently Transport handle listen and dial logic, I think the responsibility of this trait is too heavy and too hard to write a custom transport

for example:

I am writing a relay Transport, like the libp2p crate relay mod but it doesn't need user specify the relay server addr

so I think user combine normal transport like tcp transport with my relay transport, then

when dialing, try tcp transport at first, if fail, try relay
when listening, listen on tcp transport and relay transport too

however, currently libp2p only provide or_transport helper method, it can handle dial, but can't work on listening

if split the Transport, it will be easier to use my relay "transport"

Requirements

1. split Transport into Listen and Dial trait

Open questions

after created the transport, the next step is setting the upgrade and auth, if splits the transport trait, should we add the upgrade provided method to both traits, or combine the listen and dial instance into a transport struct then set the upgrade and auth?

Are you planning to do it yourself in a pull request?

Maybe

I want to make contribution to libp2p but I am also a newbie and learning libp2p

[thomaseizinger]

Currently, the Transport also provides a poll function which allows the implementation to make progress on background tasks. Do you envision both Listen and Dial to have a poll function then?

Related issues:

• core: Remove Transport::{Dial,ListenUpgrade} in favor of using trait objects #3347
• Re-organising crate structure #3271

[Sherlock-Holo]

yes, both of them have a poll method

[thomaseizinger]

I am not entirely opposed to the idea. libp2p-webrtc and libp2p-quic are probably our most complex transports. If you wanted to have a stab at this, that is where I'd start to validate that it actually works. I do remember there being interactions between dialing and listening on those two transports.

[thomaseizinger]

Another thing to consider: To construct a Swarm whatever you pass to it needs to be able to do both listening and dialing. Hence, if a particular transport (like yours) only supports one, there needs to be some kind of adapter type that provides a default for the other.

[thomaseizinger]

Closing this as stale.