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.
Currently, a user can push code after it has been approved and the send-it label applied. We only want to merge code that we actually looked at. Use mergify to dismiss approvals in such circumstances.
`cargo semver-checks` is still missing features in regards to properly detecting renamed exports. To make our CI pass again, we remove the renamed export, replace it with type-aliases and deprecate them to point users types exported under a module which now follows the conventions set in #2217.
Add support for QUIC draft-29 / the `quic` codepoint. This enables both dialing and listening on `quic` addresses.
The motivation for adding support is to allow users to connect to old go-libp2p nodes that don't support the `quic-v1` codepoint.
**Per default support is disabled.**
