feat: introduce libp2p-stream

[thomaseizinger]

Description

For a while now, rust-libp2p provided the request-response abstraction which makes it easy for users to build request-response based protocols without having to implement a NetworkBehaviour themselves. This PR introduces an alpha version of libp2p-stream: a NetworkBehaviour that directly gives access to negotiated streams.

In addition to complementing request-response, libp2p-stream also diverges in its design from the remaining modules by offering a clonable Control that provides async functions.

Resolves: #4457.

Notes & open questions

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

I've pushed an initial implementation. It was actually easier than I expected. Still need to review it myself once I've got fresher eyes though!

It also doesn't have any documentation yet although there is quite a bit I want to say about the design in regards to backpressure for example.

[mxinden]

This is great! The implementation is simple, the example is even simpler.

I have some suggestions but overall, from an architecture perspective, this looks good to me.

[thomaseizinger]

@mxinden This is actually getting into a state where I am considering to make it a regular libp2p module but release it as an alpha first. That means we don't have to commit to the API right away and can likely get better feedback than just an example.

[mxinden]

@mxinden This is actually getting into a state where I am considering to make it a regular libp2p module but release it as an alpha first. That means we don't have to commit to the API right away and can likely get better feedback than just an example.

Sounds good to me!

[thomaseizinger]

@mxinden: I've update this PR to get rid of the PeerControl API.

I decided that I don't want to implement any form of connection keep-alive. Instead, requesting a new stream should simply attempt to establish a new connection. I think that is overall more useful!

But without the PeerControl API, there is the chicken-egg problem of not knowing which peer a request is for before reading it from the channel. To solve that, I ended up using shared memory instead of channels. This allows each Control to always know the latest state of all connections and obtain a Sender for a particular connection atomically. To issue new dials, I used a channel to ensure we don't have a lock inside the poll function.

Curious to hear what you think of this design!

[thomaseizinger]

@mxinden I decided to also move accept to the Control to be a) more consistent and b) give users more flexibility in how and when they listen on protocols.

[thomaseizinger]

@mxinden I'd suggest to merge this with a failing semver job because I want to release it right away anyway.

[mxinden]

Looking forward for this to land! I expect this to be useful for many, especially those implementing a protocol on top of libp2p for the first time.

[thomaseizinger]

@rkuhn I resolved your comments to allow this to merge! :)