Given the following scenario:
1. Remote peer X connects and is added to `connected_peers`.
2. Remote peer X opens a Kademlia substream and thus confirms that it supports
the Kademlia protocol.
3. Remote peer X is added to the routing table as `Connected`.
4. Remote peer X disconnects and is thus marked as `Disconnected` in the routing
table.
5. Remote peer Y connects and is added to `connected_peers`.
6. Remote peer X re-connects and is added to `connected_peers`.
7. Remote peer Y opens a Kademlia substream and thus confirms that it supports
the Kademlia protocol.
8. Remote peer Y is added to the routing table. Given that the bucket is already
full the call to `entry.insert` returns `kbucket::InsertResult::Pending {
disconnected }` where disconnected is peer X.
While peer X is in `connected_peers` it has not yet (re-) confirmed that it
supports the Kademlia routing protocol and thus is still tracked as
`Disconnected` in the routing table. The `debug_assert` removed in this pull
request does not capture this scenario.
1. Deprecating the `write_one` function
Semantically, this function is a composition of `write_with_len_prefix` and
`io.close()`. This represents a footgun because the `close` functionality is
not obvious and only mentioned in the docs. Using this function multiple times
on a single substream will produces hard to debug behaviour.
2. Deprecating `read_one` and `write_with_len_prefix` functions
3. Introducing `write_length_prefixed` and `read_length_prefixed`
- These functions are symmetric and do exactly what you would expect, just
writing to the socket without closing
- They also have a symmetric interface (no more custom errors, just `io::Error`)
Co-authored-by: Max Inden <mail@max-inden.de>
Add `ExpandedSwarm::disconnect_peer_id` and
`NetworkBehaviourAction::CloseConnection` to close connections to a specific
peer via an `ExpandedSwarm` or `NetworkBehaviour`.
Co-authored-by: Max Inden <mail@max-inden.de>
Change `Stream` implementation of `ExpandedSwarm` to return all
`SwarmEvents` instead of only the `NetworkBehaviour`'s events.
Remove `ExpandedSwarm::next_event`. Users can use `<ExpandedSwarm as
StreamExt>::next` instead.
Remove `ExpandedSwarm::next`. Users can use `<ExpandedSwarm as
StreamExt>::filter_map` instead.
With the ethereum 2 [lighthouse client] and the Filecoin [forest client]
we have two rust-libp2p users demonstrating compatibility of the
rust-libp2p library with other libp2p implementations on a daily basis
on their corresponding live networks.
That in mind the compatibility warning is out of date. While we could do
better, especially in regards to automated compatibility testing across
implementations, rust-libp2p is in fact compatible with the libp2p
specification as well as other libp2p implementations.
[lighthouse client]: https://github.com/sigp/lighthouse
[forest client]: https://github.com/ChainSafe/forest
Add instructions on how to run a three node example where a listening
relay client listens via a relay server and a dialing relay client dials
the listening relay client via the relay server.
mdns keeps rediscovering nodes. this PR changes that to only emit events for new
nodes it discovered. In addition we make sure to only send a query if it is
really needed. Some logging is added for debugging purposes.
Changes in 45f07bf8 now seem to append `/p2p/<peer>` to multiaddr passed to
transports. The regex in transport/wasm-ext doesn't support this fully qualified
format. This commit adjusts the regex accordingly.
If you start listening after mdns joined a multicast group, the peers may not
discover eachother until the 5min timeout expires.
Co-authored-by: Max Inden <mail@max-inden.de>
With `rand` `v0.8.0` platform support changed [1] due to its upgrade to
`getrandom` `v0.2`. With `getrandom` `v0.2` `wasm32-unknown-unknown` is no
longer supported out of the box:
> This crate fully supports the wasm32-wasi and wasm32-unknown-emscripten
> targets. However, the wasm32-unknown-unknown target is not automatically
> supported since, from the target name alone, we cannot deduce which JavaScript
> interface is in use (or if JavaScript is available at all).
>
> Instead, if the "js" Cargo feature is enabled, this crate will assume that you
> are building for an environment containing JavaScript, and will call the
> appropriate methods. Both web browser (main window and Web Workers) and
> Node.js environments are supported, invoking the methods described above using
> the wasm-bindgen toolchain.
>
> This feature has no effect on targets other than wasm32-unknown-unknown.
This commit drops support for wasm32-unknown-unknown in favor of the two more
specific targets wasm32-wasi and wasm32-unknown-emscripten.
Note on `resolver = "2"`: The new resolver is required to prevent features
being mixed, more specifically to prevent libp2p-noise to build with the
`ring-resolver` feature. See [3] for details.
---
[1] https://github.com/rust-random/rand/blob/master/CHANGELOG.md#platform-support
[2] https://docs.rs/getrandom/0.2.2/getrandom/#webassembly-support
[3] https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
Instead of fully executing benchmarks, i.e. running multiple iterations,
each measured and recorded, only test that they compile and run them
with a single execution to make sure they work. The benefit is a reduced
CI runtime.
Flag documentation:
> To test that the benchmarks run successfully without performing the
measurement or analysis (eg. in a CI setting), use cargo test --benches.
https://bheisler.github.io/criterion.rs/book/user_guide/command_line_options.html
The above assumes that (a) the benchmark results from CI are likely
noisy and thus (b) no one actually looks at the benchmark results.
