Instead of exposing the time to establish a connection, the time to upload the bytes and the time to download the bytes, expose a single time including all three.
The rational here is, that differentiation of the three is flawed. E.g. when does one stop the upload timer and start the download timer? When the last byte is sent? When the last byte is flushed? When the first byte is received?
See https://github.com/libp2p/test-plans/pull/184#pullrequestreview-1482600521 for past discussion.
Pull-Request: #4105.
Co-Authored-By: Max Inden <mail@max-inden.de>
This PR implements `Transport` for WebTransport for browsers by using web-sys.
Related: #3846.
Resolves: #3825.
Pull-Request: #4015.
Co-Authored-By: Yiannis Marangos <yiannis@eiger.co>
Co-Authored-By: Maciej Zwoliński <mac.zwolinski@gmail.com>
Co-Authored-By: Yiannis Marangos <psyberbits@gmail.com>
Using workspace inheritance breaks `cargo release` because it cannot resolve that the dev-dependencies should only use a `path` and not a version.
Pull-Request: #4097.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
`libp2p-muxer-harness` is never published to crates.io. Specifying it with a version makes `cargo release` check crates.io for the the non-existing crate.
Pull-Request: #4093.
Co-Authored-By: Max Inden <mail@max-inden.de>
We have two "interface" crates in our workspace: `libp2p-core` and `libp2p-swarm`. Most crates depend on both of these. To compile the tests for this crate, we often need a concrete implementation to some of these interfaces. When specifying a workspace-inherited dependency, we don't get to choose to omit the `version` field next to the path. If a dependency is `path`-only however, it will be tripped by `cargo` during the release process which is why all of this worked before our move to workspace inheritance.
With this patch, we change the minimum amount of dependencies necessary back to `path` dependencies to allowing releasing of our crates.
Related: #4053.
Pull-Request: #4091.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
All of the removed `dev-dependencies` are only for testing the upgrade procedure in `libp2p-core`. Ironically, this test does not use a single API of `multistream-select`. Thus, this test is simply misplaced in this crate. If we wanted to retain it, it should probably go into `libp2p` itself as that one already depends on all required crates.
Related: #4053.
Pull-Request: #4090.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
It often happens that multiple people contribute to a single PR. To correctly attribute authorship, GitHub supports the `Co-authored-by` convention. This line however needs to be at the very end of the commit message.
Because we are also automatically adding the pull-request number to the commit message, we cannot add these lines ourselves. Doing this manually is error-prone anyway so with this patch, we are extending the commit message template to automatically populate this from the commits within the pull request.
Pull-Request: #4069.
The extension for WebTransport certhashes was added and can be configured via `Config::with_webtransport_certhashes`.
In case of initiator, these certhashes will be used to validate the ones reported by responder. In case of responder, these certhashes will be reported to initiator.
Resolves#3988.
Pull-Request: #3991.
Implement `Transport::dial_as_listener` for QUIC as specified by the [DCUtR spec](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md).
To facilitate hole punching in QUIC, one side needs to send random UDP packets to establish a mapping in the routing table of the NAT device. If successful, our listener will emit a new inbound connection. This connection needs to then be sent to the dialing task. We achieve this by storing a `HashMap` of hole punch attempts indexed by the remote's `SocketAddr`. A matching incoming connection is then sent via a oneshot channel to the dialing task which continues with upgrading the connection.
Related #2883.
Pull-Request: #3964.
Prior to this change it was only possible to downcast a `ConnectionDenied` error when you had ownership of it which isn't the case inside `NetworkBehaviour`s. This change allows downcasting by reference.
See https://github.com/libp2p/rust-libp2p/discussions/4018.
Pull-Request: #4020.
> Observed addresses (aka. external address candidates) of the local node, reported by a remote node
> via `libp2p-identify`, are no longer automatically considered confirmed external addresses, in
> other words they are no longer trusted by default. Instead users need to confirm the reported
> observed address either manually, or by using `libp2p-autonat`. In trusted environments users can
> simply extract observed addresses from a `libp2p-identify::Event::Received { info:
> libp2p_identify::Info { observed_addr }}` and confirm them via `Swarm::add_external_address`.
Follow-up to https://github.com/libp2p/rust-libp2p/pull/3954.
Pull-Request: #4052.
This extends `ToSwarm` to add `ToSwarm::ListenOn` and `ToSwarm::RemoveListener`, which allows creating and removing listeners from a `NetworkBehaviour`.
Resolves https://github.com/libp2p/rust-libp2p/issues/3291.
Pull-Request: #3292.
Remove the use of the core `upgrade::transfer` module in `ping` example (`request-response` protocol) in favor of `cbor` codec.
Related #4011.
Pull-Request: #4046.
With `Version::V1Lazy` and negotiation of a single protocol, a stream initiator optimistically
sends application data right after proposing its protocol. More specifically an application can
write data via `AsyncWrite::poll_write` even though the remote has not yet confirmed the stream protocol.
This saves one round-trip.
``` mermaid
sequenceDiagram
A->>B: "/multistream/1.0.0"
A->>B: "/perf/1.0.0"
A->>B: <some-perf-protocol-data>
B->>A: "/multistream/1.0.0"
B->>A: "/perf/1.0.0"
B->>A: <some-perf-protocol-data>
```
When considering stream closing, i.e. `AsyncWrite::poll_close`, and using stream closing as an
operation in ones protocol, e.g. using stream closing to signal the end of a request, this becomes tricky.
The behavior without this commit was as following:
``` mermaid
sequenceDiagram
A->>B: "/multistream/1.0.0"
A->>B: "/perf/1.0.0"
A->>B: <some-perf-protocol-data>
Note left of A: Call `AsyncWrite::poll_close` which first waits for the<br/>optimistic multistream-select negotiation to finish, before closing the stream,<br/> i.e. setting the FIN bit.
B->>A: "/multistream/1.0.0"
B->>A: "/perf/1.0.0"
Note right of B: Waiting for A to close the stream (i.e. set the `FIN` bit)<br/>before sending the response.
A->>B: FIN
B->>A: <some-perf-protocol-data>
```
The above takes 2 round trips:
1. Send the optimistic multistream-select protocol proposals as well as the initiator protocol
payload and waits for the confirmation of the protocols.
2. Close the stream, i.e. sends the `FIN` bit and waits for the responder protocol payload.
This commit proposes that the stream initiator should not wait for the multistream-select protocol
confirmation when closing the stream, but close the stream within the first round-trip.
``` mermaid
sequenceDiagram
A->>B: "/multistream/1.0.0"
A->>B: "/perf/1.0.0"
A->>B: <some-perf-protocol-data>
A->>B: FIN
B->>A: "/multistream/1.0.0"
B->>A: "/perf/1.0.0"
B->>A: <some-perf-protocol-data>
```
This takes 1 round-trip.
The downside of this commit is, that the stream initiator will no longer notice a negotiation error
when closing the stream. They will only notice it when reading from the stream. E.g. say that B does
not support "/perf/1.0.0", A will only notice on `AsyncRead::poll_read`, not on
`AsyncWrite::poll_close`. This is problematic for protocols where A only sends data, but never
receives data, i.e. never calls `AsyncRead::poll_read`. Though one can argue that such protocol is
flawed in the first place. With a response-less protocol, as even if negotiation succceeds, A
doesn't know whether B received the protocol payload.
Pull-Request: #4019.
