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.
In the unlikely event that we generated a random number twice, the 2nd address would not get added. Ensure we loop until we have 20 addresses.
Pull-Request: #4030.
Currently, the kademlia behaviour can only learn that the remote node supports kademlia on a particular connection if we successfully negotiate a stream to them.
Using the newly introduced abstractions from #3651, we don't have to attempt to establish a stream to the remote to learn whether they support kademlia on a connection but we can directly learn it from the `ConnectionEvent::RemoteProtocolsChange` event. This happens directly once a connection is established which should overall benefit the DHT.
Clients do not advertise the kademlia protocol and thus we will immediately learn that a given connection is not suitable for kadmelia requests. We may receive inbound messages from it but this does not affect the routing table.
Resolves: #2032.
Pull-Request: #3877.
