Previously, the `libp2p-ping` module came with a policy to close a connection after X failed pings. This is only one of many possible policies on how users would want to do connection management.
We remove this policy without a replacement. If users wish to restore this functionality, they can easily implement such policy themselves: The default value of `max_failures` was 1. To restore the previous functionality users can simply close the connection upon the first received ping error.
In this same patch, we also simplify the API of `ping::Event` by removing the layer of `ping::Success` and instead reporting the RTT to the peer directly.
Related: #3591.
Pull-Request: #3947.
This option is the only reason we pull in a dependency on the shared `zlib` library. Unfortunately, we cannot use a pure Rust backend here because that one does not support configuring the window bits of the deflate algorithm which is used in the deflate websocket extension.
Using websockets in libp2p is already crazy inefficient because you end up with double encryption when using `/wss` (which is enforced by browsers if your website is served via https). A good encryption algorithm like noise or TLS produces an output that looks completely random. Any attempt in compressing this is pretty much wasted CPU power.
Thus, I think removing this configuration option does not really hurt and allows us to remove the dependency on the `zlib` shared library.
Pull-Request: #3949.
By using a multi-stage docker build, a distroless base image and a release build, we can get the size of the Rust interop test down to 50MB. Previously, the image would be around 500MB. A debug build image would still have ~400MB. The release build slows down our interop build step by about 1min 20s. That however is only because we don't currently seem to utilize the caches that from what I understand should work on self-hosted runners. I opted https://github.com/libp2p/rust-libp2p/issues/3925 for that.
Resolves: #3881.
Pull-Request: #3926.
Previously, we would specify the version and path of our workspace dependencies in each of our crates. This is error prone as https://github.com/libp2p/rust-libp2p/pull/3658#discussion_r1153278072 for example shows. Problems like these happened in the past too.
There is no need for us to ever depend on a earlier version than the most current one in our crates. It thus makes sense that we manage this version in a single place.
Cargo supports a feature called "workspace inheritance" which allows us to share a dependency declaration across a workspace and inherit it with `{ workspace = true }`.
We do this for all our workspace dependencies and for the MSRV.
Resolves#3787.
Pull-Request: #3715.
In the libp2p specs, the only handshake pattern that is specified is the XX handshake. Support for other handshake patterns can be added through external modules. While we are at it, we rename the remaining types to following the laid out naming convention.
The tests for handshakes other than XX are removed. The handshakes still work as we don't touch them in this patch.
Related #2217.
Pull-Request: #3768.
These functions were only used for some code in the interop-tests which is easily mitigated and perhaps even easier to understand now. We can thus deprecate these functions and their related types and thereby reduce the API surface of `libp2p-core` and the maintenance burden.
This change is motivated by the work around making protocols always strings which requires/required updates to all these upgrades.
Related #3806.
Related #3271.
Related #3745.
Pull-Request: #3807.
We currently expose `libp2p-quic` and `libp2p-webrtc` as submodules from the `libp2p` crate despite those only being "alpha" status. This causes problems because we need to pin those dependencies due to `cargo` automatically upgrading alphas (which are allowed to incur breaking changes as per semver spec). Additionally, exposing these modules practically hides the "alpha" state of those modules, rendering it kind of obsolete.
The "alpha" state is still true for those modules, thus to properly communicate this to users, we deprecate the modules and require users to spell out the dependency and the alpha version in their manifest.
Pull-Request: #3580.
Mark constructors `Swarm::with_X_executor` as deprecated.
Move the deprecated functionality to `SwarmBuilder::with_X_executor`
Use `SwarmBuilder` throughout.
Resolves#3186.
Resolves#3107.
Pull-Request: #3588.
We only retain it for the test job which runs `cargo semver-checks` which may need to build the rustdoc for the baseline version which still requires `protoc` to be installed until we make the next round of releases.
Pull-Request: #3592.
Currently, our top-level `Cargo.toml` manifest represents a crate AND a workspace. This causes surprising behaviour (e.g. #2949) where we need to explicitly pass `--workpace` to every command to run it on the entire workspace and not just the meta crate.
My moving the meta crate into its own directory, the root manifest file is a virtual manifest only and thus, every `cargo` command will automatically default to running on the entire workspace.
On top of this, I personally find it easier to understand if workspace and crate manifests are not mixed.
Pull-Request: #3536.
Instead of relying on `protoc` and buildscripts, we generate the bindings using `pb-rs` and version them within our codebase. This makes for a better IDE integration, a faster build and an easier use of `rust-libp2p` because we don't force the `protoc` dependency onto them.
Resolves#3024.
Pull-Request: #3312.
We only use `strum` for the interop-tests but we add 3 dependencies to a full build of the repository for it, including a proc-macro which needs to be pipelined in front of other crates which makes them hard to parallelize. Remove it in favor of fairly trivial reimplementation of `FromStr`.
Pull-Request: #3513.
Building inside the container allows Windows and MacOS users to also build this binary. Thanks to a new feature from docker, `--mount=type=cache`, rebuilding layers is fast without any additional hacks.
This patch adds a workflow that automatically publishes a docker image of our `ping` interop-test binaries on every release. Releases are different from Git tags. We publish a tag for each version of each crate but only a single release for each version of the `libp2p` crate.
Alternatively, this workflow can also be triggered manually:
1. Select the Git ref you want to run the workflow on. This should be the version of `libp2p` you want to publish the test binary for. For example, if you want to publish a version of the test binary for a hotfix release of a sub-crate, you would pick the respective tag of the hotfix release.
2. Choose the tag of the docker image.
To resolve https://github.com/libp2p/test-plans/issues/112, I am planning to create branches off current master that hardcodes the libp2p version in the test-binary to a particular one and then trigger this workflow for the respective branch.
We make the binary that should be copied into the container configurable via a build time `ARG`. This will allow us to reuse the same `Dockerfile` once we write more tests.
Additionally, this allows us to remove some of the directory switching and creation code. In order to not send the entire repository over to the docker daemon as a build context, we introduce a `.dockerignore` file that only allows select binary to be sent over.
The downside of this is that we need to extend this ignore file every time we add a new test. This shouldn't happen very often though and is easily discovered because the building of the docker container will fail.
Node and browser tests take a little bit longer to spin up in the interop tests. The multidim-interop can tell the tests to increase the timeout when testing against these targets, but the test itself needs to use the passed in value.
This updates the test code to handle the new test_timeout option. See https://github.com/libp2p/test-plans/issues/107
