As the name implies, `LegacyConfig` allows users to interact with older versions of the noise protocol. These are not interoperable and we've been supporting them for a long time now. Hopefully, users have migrated away from it since. To not directly break them, we officially deprecate now without a replacement.
Identify multiaddress with `/quic` (draft 29) as QUIC address in case `support_draft_29` is `true`.
Without this patch the Rust punchr client would discard any QUIC addresses with `/quic` in its `Transport::address_translation`. Thus `/quic` based observed addresses from `libp2p-identify` would not be added to the local set of external addresses and thus QUIC would not be available as a transport for hole punching.
With #3097, subscribing to the floodsub topic in `examples/chat-tokio.rs` was removed. I assume this was unintentional (cc @umgefahren), so this PR adds it back.
With the addition of more CI jobs, we are constantly running into API limits on setting up protoc. For all jobs that run on ubuntu, we can install it from `apt` instead.
On ubuntu 22.04, which is what `ubuntu-latest` points to, this installs `protoc v3.12.4`.
GitHub wraps the titles of commits if they are longer than 72 characters. See fbd4192e2a for example.
There is a convention that titles should be no more than 50 characters: https://cbea.ms/git-commit/#limit-50
This however makes crafting the message quite difficult, esp. with our use of conventional commit messages, thus limiting it to 72 seems more reasonable as that is where tooling (.e.g GitHub) seems to "break".
With this commit `libp2p-kad` no longer discards the whole peer payload in case an addr is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining payload.
See https://github.com/libp2p/rust-libp2p/issues/3244 for details.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
With this commit `libp2p-identify` no longer discards the whole identify payload in case a listen addr of the remote node is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining identify payload.
This is especially relevant when rolling out a new protocol to a live network. Say that most nodes of a network run on an implementation version v1. Say that the `multiaddr` implementation is not aware of the `webrtc/` protocol. Say that a new version (v2) is rolled out to the network with support for the `webrtc/` protocol, listening via `webrtc/` by default. In such case all v1 nodes would discard all identify payloads of v2 nodes, given that the v2 identify payloads would contain the `webrtc/` protocol in their `listen_addr` addresses.
See https://github.com/libp2p/rust-libp2p/issues/3244 for details.
Ever since we moved `Pool` into `libp2p-swarm`, we always use it with the same `Transport`: `Boxed`. It is thus unnecessary for us to be overly generic over what kind of `Transport` we are using. This allows us to remove a few type parameters from the implementation which overall simplifies things.
This is technically a breaking change because I am removing a type parameter from two exported type aliases:
- `PendingInboundConnectionError`
- `PendingOutboundConnectionError`
Those have always only be used with `std::io::Error` in our API but it is still a breaking change.
Remove the `derive_builder` dev-dependency in gossipsub. We can manually implement the builder functionality on top of the `Default` instance of `InjectNodes`.
Resolved#3228.
Previously, the logic within `Swarm::dial` involved fairly convoluted `match` expressions. This patch refactors this function to use new utility functions introduced on `DialOpts` to handle one concern at a time.
This has the advantage that we are covering slightly more cases now. Because we are parsing the `PeerId` only once at the top, checks like banning will now also act on dials that specify the `PeerId` as part of the `/p2p` protocol.
Previously, we applied a lifetime onto the entire `RecordStore` to workaround Rust not having GATs. With Rust 1.65.0 we now have GATs so we can remove this workaround.
Related https://github.com/libp2p/rust-libp2p/issues/3240. Without this change, we would have to specify HRTB in various places.
Currently, we have dependabot configured to automatically rebase PRs as soon as the base branches changes. This however causes two problems:
1. It unnecessarily consumes CI resources because dependabot rebases all open dependency PRs at once upon every merge of a PR into `master`.
2. It does not interact well with our strategy of dismissing reviews on updates to the PR: https://github.com/libp2p/rust-libp2p/pull/3226#event-8074236930
Overall, the rebasing of dependency PRs is a way to fix merge conflicts and to ensure that CI still passes even on the latest version of the base branch. The latter is already ensured by our merge queue and the former can be triggered manually with `@dependabot rebase`, thus disabling automatic rebasing is the better configuration for our setup.
Previously, some of the caches for these job runs were overlapping. By incorporating the relevant matrix variables into the cache key, every instance of this job gets its own cache.
Currently, we store messages to be sent to the `ConnectionHandler` in an `Arc`. However, we never actually clone these messages as we can see with this patch, hence we remove this wrapping.
Related: https://github.com/libp2p/rust-libp2p/pull/3242
There is no need to specify dev dependencies from the monorepo by version. Versions can be inferred from the dependencies `Cargo.toml`. Specifying the version increases maintenance overhead, as they have to be bumped manually.
For the last [two years](https://github.com/libp2p/rust-libp2p/blob/master/CHANGELOG.md#version-0190-2020-05-18), we have been carrying around a non-compliant implementation of the noise protocol for libp2p. It is time to follow through on the announcement in that changelog entry and deprecate it. Users should use the spec compliant implementation instead.
1. This will reduce the maintenance effort of our codebase.
2. We will improve compile-times because we no longer need to depend on `libsodium` to test cryptography that is only part of the non-compliant implementation.
3. It will simplify usage of `rust-libp2p` because users cannot accidentally choose the wrong implementation.
There is nothing wrong about being near the edge of the concurrency Kademlia allows. If there was an older stream about to be reused, it doesn't mean there was anything wrong to warn about.
This patch addresses #2500 for the `libp2p-floodsub` crate.
For this PR the existing code was upgraded to use `Framed` with the `prost_codec::Codec` as the standard codec for handling the RPC message format serialization/deserialization.
Previously, the `with_bandwidth_logging` extension to `Transport` would track the bytes sent and received on a socket level. This however only works in conjunction with `Transport` upgrades where a separate multiplexer is negotiated on top of a regular stream.
With QUIC and WebRTC landing, this no longer works as those `Transport`s bring their own multiplexing stack. To still allow for tracking of bandwidth, we refactor the `with_bandwidth_logging` extension to count the bytes send on all substreams opened through a `StreamMuxer`. This works, regardless of the underlying transport technology. It does omit certain layers. However, there isn't necessarily a "correct" layer to count bandwidth on because you can always go down another layer (IP, Ethernet, etc).
Closes#3157.
Currently the `libp2p_swarm_connections_establishment_duration` metric has the following buckets:
```
// exponential_buckets(1e-3, 2., 10)
[0.001, 0.002, 0.004, 0.008, 0.016, 0.032, 0.064, 0.128, 0.256, 0.512]
```
It is unlikely that a connection is established in 1ms, even within a datacenter. It is very likely that libp2p connection establishment takes longer than 512ms over the internet.
This commit proposes the following buckets:
```
// exponential_buckets(0.01, 1.5, 20)
[0.01, 0.015, 0.0225, 0.03375, 0.050625, 0.0759375, 0.11390625, 0.170859375, 0.2562890625,
0.38443359375, 0.576650390625, 0.8649755859375, 1.29746337890625, 1.946195068359375,
2.9192926025390626, 4.378938903808594, 6.568408355712891, 9.852612533569337, 14.778918800354004,
22.168378200531006]
```
- Buckets start at 10ms.
- Reasonably high resolution in the sub-second area.
- Largest bucket at 22s, e.g. for a relayed connection.
- Unfortunately rather obscure numbers.
Previously, we used to buffer events separately and emit actions directly. That is unnecessary. We can have a single place where we return from the `poll` loop and shove all actions into the same buffer.
Previously, every inbound or outbound upgrade generated a log at `debug` level, without information about the upgrade.
This commit changes it such that successful upgrades are logged at `trace` level (due to ubiquitous use of OneShot handlers) and that the negotiated protocol name is included in the message.
The task for a pending connection only ever sends one event into this channel: Either a success or a failure. Cloning a sender adds one slot to the capacity of the channel. Hence, we can start this capacity at 0 and have the `cloning` of the `Sender` take care of properly increasing the capacity.
As I do frequently, I corrected for the latest clippy warnings. This will make sure the CI won't complain in the future. We could automate this btw and maybe run the nightly version of clippy.
This patch deprecates 3 out of 4 functions on `PollParameters`:
- `local_peer_id`
- `listened_addresses`
- `external_addresses`
The addresses can be obtained by inspecting the `FromSwarm` event. To make this easier, we introduce two utility structs in `libp2p-swarm`:
- `ExternalAddresses`
- `ListenAddresses`
A node's `PeerId` is always known to the caller, thus we can require them to pass it in.
Related: #3124.
Currently, we create a new cache for each workflow run for each crate. That ends up blowing the maximum allowed cache size of 10GB and GitHub deletes the least-recently used cache again. Effectively, this means we don't have any caching.
This patch introduces a cache factory workflow that only runs on master and always _saves_ a new cache. The CI workflow run for pull-requests on the other hand only restore these caches but don't save them.
