transports/quic: Adapt QuicMuxer to upstream StreamMuxer changes #6
Conversation
…ibp2p#2752) Document that the `ConnectionHandler` implementation has to enforce a limit on the number of inbound substreams.
…ibp2p#2734) * misc/metrics: Explicitly delegate event recording to each recorder This allows delegating a single event to multiple `Recorder`s. That enables e.g. the `identify::Metrics` `Recorder` to act both on `IdentifyEvent` and `SwarmEvent`. The latter enables it to garbage collect per peer data on disconnects. * protocols/dcutr: Expose PROTOCOL_NAME * protocols/identify: Expose PROTOCOL_NAME and PUSH_PROTOCOL_NAME * protocols/ping: Expose PROTOCOL_NAME * protocols/relay: Expose HOP_PROTOCOL_NAME and STOP_PROTOCOL_NAME * misc/metrics: Track # connected nodes supporting specific protocol An example metric exposed with this patch: ``` libp2p_identify_protocols{protocol="/ipfs/ping/1.0.0"} 10 ``` This implies that 10 of the currently connected nodes support the ping protocol.
…nd,address_change,close}` (libp2p#2724) Instead of having a mix of `poll_event`, `poll_outbound` and `poll_close`, we flatten the entire interface of `StreamMuxer` into 4 individual functions: - `poll_inbound` - `poll_outbound` - `poll_address_change` - `poll_close` This design is closer to the design of other async traits like `AsyncRead` and `AsyncWrite`. It also allows us to delete the `StreamMuxerEvent`.
* build(deps): Bump Swatinem/rust-cache from 1.4.0 to 2.0.0 Bumps [Swatinem/rust-cache](https://github.com/Swatinem/rust-cache) from 1.4.0 to 2.0.0. - [Release notes](https://github.com/Swatinem/rust-cache/releases) - [Changelog](https://github.com/Swatinem/rust-cache/blob/master/CHANGELOG.md) - [Commits](Swatinem/rust-cache@cb2cf0c...6720f05) --- updated-dependencies: - dependency-name: Swatinem/rust-cache dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Follow up on libp2p#2724. Given that libp2p-core is bumped to v0.35.0, libp2p-tcp needs to be bumped as well.
….0 (libp2p#2761) * build(deps): Update prometheus-client requirement from 0.16.0 to 0.17.0 Updates the requirements on [prometheus-client](https://github.com/prometheus/client_rust) to permit the latest version. - [Release notes](https://github.com/prometheus/client_rust/releases) - [Changelog](https://github.com/prometheus/client_rust/blob/master/CHANGELOG.md) - [Commits](prometheus/client_rust@v0.16.0...v0.17.0) --- updated-dependencies: - dependency-name: prometheus-client dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
We are already boxing the given object so we might as well pin to to avoid the `Unpin` trait bound.
…rBox` (libp2p#2775) `StreamMuxerBox` is never shared across threads but owned by a single connection. Restricting it to be `Sync` unnecessarily limits the design space around the `StreamMuxer` trait and its implementations.
…ibp2p#2765) Co-authored-by: Elena Frank <elena.frank@protonmail.com> Co-authored-by: Max Inden <mail@max-inden.de>
Discussed in libp2p#2722.
transports/quic/src/muxer.rs
Outdated
| while let Poll::Ready(event) = self.connection.poll_event(cx) { | ||
| match event { | ||
| ConnectionEvent::Connected => { | ||
| tracing::error!("Unexpected Connected event on established QUIC connection"); |
There was a problem hiding this comment.
error seems a bit much here. I wouldn't won't be woken at 3am because my production app is reporting _error_s and then seeing it is this one which is practically harmless :)
Why is this unexpected in the first place?
There was a problem hiding this comment.
ConnectionEvent::Connected should only be returned a single time, which is when we finished all the crypto and established a connection.
In quic::upgrade::Update we poll a pending new connection until it returns ConnectionEvent::Connected. Only then we create the QuicMuxer for this connection. Hence within QuicMuxer the event should not happen again.
There was a problem hiding this comment.
If it really should not happen, then perhaps put a debug assert here?
transports/quic/src/muxer.rs
Outdated
| while let Poll::Ready(event) = inner.connection.poll_event(cx) { | ||
| if let ConnectionEvent::ConnectionLost(_) = event { | ||
| return Poll::Ready(Ok(())); | ||
| } | ||
| } |
There was a problem hiding this comment.
Let's assume this returns Poll::Pending at some point. Then we will break out of this loop and register a waker further down. Once we are woken, poll_close gets called again and we go straight into inner.poll_connection which will likely yield the ConnectionEvent::ConnectionLost. I don't think we will be observing it here then, right?
I think we may not want to call poll_connection at the top here or maybe return an error from poll_connection in case it has been closed?
|
If we end up merging libp2p#2797, we could only poll the inner connection within |
Generate `NetworkBehaviour::OutEvent` if not provided through `#[behaviour(out_event = "MyOutEvent")]` and event processing is disabled (default).
…X25519 DH key exchange (libp2p#2887) Co-authored-by: Max Inden <mail@max-inden.de>
This patch fixes an issue where we couldn't use type parameters on a behaviour with a custom out event that had different type parameters.
Should be fixed with 4e027b1 and bdba780. @kpp Would you mind testing again? |
The existing implementation was based on an old API of the quinn_proto Endpoint which by now has changed. In particular we can not explicitly `accept` new connections on the endpoint anymore. Instead if there is a new connections and our channel for new connections is full because the endpoint is too busy, we now simply drop the connection to backpressure the remote.
|
Thank you for the continuous reviews @thomaseizinger. I think I addressed everything. There are still two major TODOs in the code, namely
They are unrelated to the change of this PR. |
| @@ -183,16 +186,14 @@ impl Connection { | |||
| /// On success, a [`quinn_proto::StreamEvent::Finished`] event will later be produced when the | |||
| /// substream has been effectively closed. A [`ConnectionEvent::StreamStopped`] event can also | |||
| /// be emitted. | |||
| pub fn shutdown_substream( | |||
| pub fn finish_substream( | |||
There was a problem hiding this comment.
According to the docs, this only closes the write-side. If that is the case, perhaps close or close_write would be a better name?
There was a problem hiding this comment.
I think I prefer to stick with finish_substream because it is consistent if the name of the event it produces quinn_proto::StreamEvent::Finished / ConnectionEvent::StreamFinished.
But not a strong opinion, happy to change it to close_write if you insist :)
@elenaf9 I don't think this is a good idea. Let's merge this one ASAP.
I tested b7103aa only, it works! Here are perf logs: b7103aa |
Okay. From my side this is ready for merge then. Will create the PR tomorrow.
Thanks for testing. |
|
Merged via kpp#23. |
Address leftovers from review in elenaf9#6.
Description
Merge latest upstream master and adapt
QuixMuxertoStreamMuxertrait changes from libp2p#2724. Relevant commit is 57840a3.Discussed in libp2p#2722 (comment) and kpp#19 (comment).
//CC @kpp @thomaseizinger - unfortunately can not explicitly request a review from you, but I would appreciate one.