Starting with nightly-2023-09-10, the `[lints]` section in `Cargo.toml` files is stable. Together with workspace inheritance, this can be used to declare all lints we want to enforce in a single place.
Resolves: #4484.
Pull-Request: #4575.
Renamed the following
- `dns::GenDnsConfig` -> `dns::Config`
- `dns::DnsConfig` -> `dns::async_std::Config`
- `dns::TokioDnsConfig` -> `dns::tokio::Config`
If async-std feature is enable, use `dns::async_std::Config`. When using tokio, import `dns::tokio::Config` . There is no need to use `dns::Config` directly.
Resolves#4486.
Related: #2217.
Pull-Request: #4505.
Previously, a connection would be shut down immediately as soon as its `ConnectionHandler` reports `KeepAlive::No`. As we have gained experience with libp2p, it turned out that this isn't ideal.
For one, tests often need to keep connections alive longer than the configured protocols require. Plus, some usecases require connections to be kept alive in general.
Both of these needs are currently served by the `keep_alive::Behaviour`. That one does essentially nothing other than statically returning `KeepAlive::Yes` from its `ConnectionHandler`.
It makes much more sense to deprecate `keep_alive::Behaviour` and instead allow users to globally configure an `idle_conncetion_timeout` on the `Swarm`. This timeout comes into effect once a `ConnectionHandler` reports `KeepAlive::No`. To start with, this timeout is 0. Together with https://github.com/libp2p/rust-libp2p/issues/3844, this will allow us to move towards a much more aggressive closing of idle connections, together with a more ergonomic way of opting out of this behaviour.
Fixes#4121.
Pull-Request: #4161.
This PR implements `Transport` for WebRTC for browsers by using web-sys. Only the `webrtc-direct` spec is implemented. The `webrtc` spec for connecting two browsers with each other is left to a future PR.
Related: https://github.com/libp2p/specs/issues/475.
Related #2617.
Supersedes: #4229.
Pull-Request: #4248.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Configuration files generated by Kubo <= v0.22 list both `/quic` and `/quic-v1` listen addresses with the same UDP port. Given that we enable draft-29, the two addresses are treated the same by rust-libp2p's QUIC implementation. Though calling `listen_on` with both results in an "Address already in use" error by the OS on the second call. To prevent this from happening filter out `/quic` addresses in favor of `/quic-v1`.
Pull-Request: #4467.
This commit reverts the previous metrics behavior. Namely:
- adhering to --metrics-path flag
- listening on 0.0.0.0:8888 instead of 127.0.0.1:8080
Note that 8888 is the default IPFS debug (aka. metrics) port.
See https://github.com/mxinden/rust-libp2p-server/blob/master/src/metric_server.rs for previous behavior.
Pull-Request: #4392.
One needs to specify a version of `libp2p` dependeny in `misc/server/Cargo.toml` or import as a workspace dependency, in order to publish to crates.io.
This commit does the latter for the sake of consistency with the other libp2p-* dependencies.
Pull-Request: #4391.
Implements memory-based connection limits where the user can specify an absolute or a relative limit of the process' memory usage in relation to the available system memory.
Related: #4252.
Pull-Request: #4281.
The connection limit behaviour was not taking into account connection errors. Also, it was using the behaviour events to indicate established connections which is not always going to be the case because other behaviours can deny the connections (thanks @divagant-martian).
Closes#4249
Pull-Request: #4250.
Since https://github.com/libp2p/rust-libp2p/pull/3973, gossipsub now fully supports wasm targets. It functions properly when added as a dependency on its own. However, when trying to use it under libp2p by activating a feature, it's not possible and the compiler will raise an error like `unresolved import libp2p::gossipsub`. This pull request enables the use of gossipsub for wasm targets when it's activated as a feature of the libp2p dependency.
Pull-Request: #4217.
This resolves an issue where our tests were depending on the number of network interfaces available on the local machine.
Related #4110.
Pull-Request: #4122.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
