Relayed connections to other peers are created from streams to the relay itself. Internally, such a connection has different states. These however are not relevant to the user and should be encapsulated to allow for more backwards-compatible changes. The only interface exposed is `AsyncRead` and `AsyncWrite`.
Resolves: #3255.
Pull-Request: #3829.
In previous PR #3606 we've made `mdns::Event` `Clone`, but cloning single-use iterators doesn't sound right. Also you have to create an iterator from the actual data returned before putting it into events. So in this PR the iterators are replaced by `Vec`, as it's the type the data originally come from.
Related #3612.
Pull-Request: #3621.
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.
Previously, we would implicitly establish a connection when the user wanted to push identify information to a peer. I believe that this is the wrong behaviour. Instead, I am suggesting to log a message that we are skipping the push to this peer.
Additionally, the way this is currently implemented does not make much sense. Dialing a peer takes time. In case we don't have a connection at all, it could be that we drop the push requests because there isn't an active handler and thus we would have unnecessarily established the connection.
Instead of fixing this - which would require buffering the push messages - I think we should just remove the implicit dial.
Pull-Request: #3843.
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.
Previously, we only honored the `support_floodsub` setting when the user did not specify a custom protocol for gossipsub. This patch fixes this and allows users to advertise floodsub even when they use a custom protocol.
Pull-Request: #3837.
- Move helpers to the bottom
- Restructure tests to follow arrange-act-assert
- Only set necessary options on builder for each test
Pull-Request: #3836.
The `unreachable_pub` lint makes us aware of uses of `pub` that are not actually reachable from the crate root. This is considered good because it means reading a `pub` somewhere means it is actually public API. Some of our crates are quite large and keeping their entire API surface in your head is difficult.
We should strive for most items being `pub(crate)`. This lint helps us enforce that.
Pull-Request: #3735.
Previous to this change if the ConnectionHandler::poll for kad was called more frequently than the connection idle timeout the timeout would continually be pushed further into the future. After this change kad now will preserve the existing idle deadline.
Pull-Request: #3801.
Previously, we closed the entire connection upon receiving too many upgrade errors. This is unnecessarily aggressive. For example, an upgrade error may be caused by the remote dropping a stream during the initial handshake which is completely isolated from other protocols running on the same connection.
Instead of closing the connection, set `KeepAlive::No`.
Related: #3591.
Resolves: #3690.
Pull-Request: #3625.
This PR renames some method names that don't follow Rust naming conventions or behave differently from what the name suggests:
- Enforce "try" prefix on all methods that return `Result`.
- Enforce "encode" method name for methods that return encoded bytes.
- Enforce "to_bytes" method name for methods that return raw bytes.
- Enforce "decode" method name for methods that convert encoded key.
- Enforce "from_bytes" method name for methods that convert raw bytes.
Pull-Request: #3775.
With the changes from #3767, we made the `connect` test flaky because the `Swarm` was fully passed to the future and thus dropped as soon as the connection was established. We pass a mutable reference instead which keeps the `Swarm` alive.
Pull-Request: #3780.
Previously, the relay server would erroneously send its own `PeerId` in the STOP message to the client upon an incoming relay connection. This is obviously wrong and results in failed connection upgrades in other implementations.
Pull-Request: #3767.
As a relay, when forwarding data between relay-connection-source and -destination and vice versa, flush write side when read currently has no more data available.
Pull-Request: #3765.
Autonat uses `Vec` for the servers field to hold a list of `PeerId` when calling `Behaviour::add_server`, but there is no check to prevent duplicated entries of the `PeerId`, which would cause unnecessary allocation overtime with repeated calls to the function.
Resolves#3733.
Pull-Request: #3736.
The `RoutingUpdate` type that `add_address` returns was not made available publicly. This type is added in this PR by `pub use`.
Resolves#3737.
Pull-Request: #3739.
With https://github.com/libp2p/rust-libp2p/pull/3658, these crates depend on the `0.42.1` release to access the new `ToSwarm` type. With the currently specified version, a user could theoretically run into a compile error if they pin `libp2p-swarm` to `0.42.0` in their lockfile but update to the latest patch release of one of these crates.
Pull-Request: #3711.
Doesn't change any functionality but `pop` returns an `Option` whereas `remove` will panic on out-of-bounds. I am more comfortable with `pop` and a pattern match. Also, usage of `continue` allows us to not use an `else`.
Pull-Request: #3734.
Previously, we only mutably borrowed the `last_seq_no` in the current scope but did not modify the underlying number. This is because `u64` is copy and calling `wrapping_add` consumes `self` so the compiler just copied it. We introduce a new-type instead that is not `Copy`.
Additionally, `wrapping_add` and initializing with a random u64 might actually warp the number and thus not give us sequential numbers as intended in #3551. To solve this, we initialize with the current unix timestamp in nanoseconds. This allows a node to publish 1000000 messages a second and still not reuse sequence numbers even after a restart / re-initialization of the configuration. This is also what the go implementation does.
Resolves#3714.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Pull-Request: #3716.
All we need from the multihash is for it to be a data structure that we pass around. We only ever use the identity "hasher" and the sha256 hasher. Those are easily implemented without depending the (fairly heavy) machinery in `multihash`.
Unfortunately, this patch by itself does not yet lighten our dependency tree because `multiaddr` activates those features unconditionally. I opened a companion PR for this: https://github.com/multiformats/rust-multiaddr/pull/77.
https://github.com/multiformats/rust-multiaddr/pull/77 is another breaking change and we are trying to delay those at the moment. However, it will (hopefully) land eventually which should then be much easier to implement.
Fixes#3276.
Pull-Request: #3514.
