Remove default features. You need to enable required features
explicitly now. As a quick workaround, you may want to use the
new `full` feature which activates all features.
We support two versions of the Noise XX handshake with X25519, but only one of
them is compliant with the specification and thus compliant with other
implementations. We should always default to the spec compliant handshake.
Fixes bug introduced in https://github.com/libp2p/rust-libp2p/pull/2887/
* Provide separate functions for injecting in- and outbound streams
* Inline `HandlerWrapper` into `Connection`
* Only poll for new inbound streams if we are below the limit
* yamux: Buffer inbound streams in `StreamMuxer::poll`
In case we accidentally generate the same port twice, we will try to
issue two dial attempts to the same address but also expect two dial
errors which is exactly what this test is trying to catch.
Unfortunately, the assertion is badly written and does not catch
duplicate inputs.
With if-watch `2.0.0` `IfWatcher::new` is not async anymore, hence the
`IfWatch` wrapping logic is obsolete.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Adds two workflows on push & PR:
* `run-ping-interop-cross-version`: runs a Testground interoperability test
between multiple versions of rust-libp2p, including master, and the current
branch (during a pull request)
* `run-ping-interop-cross-implementation`: runs a Testground interoperability
test between go-libp2p and rust-libp2p, and the current branch (during a pull
request)
We rely on the https://github.com/libp2p/test-plans/ repository to retrieve and
run the tests.
Co-authored-by: Piotr Galar <piotr.galar@gmail.com>
Allow users to choose between async-io and tokio runtime
in the mdns protocol implementation. `async-io` is a default
feature, with an additional `tokio` feature.
Fix high CPU usage with Tokio library.
When using channels (e.g. `futures::channel::mpsc` or `std::sync::mpsc`)
always use the bounded variant, never use the unbounded variant. When
using a bounded channel, a slow consumer eventually slows down a fast
producer once the channel bound is reached, ideally granting the slow
consumer more system resources e.g. CPU time, keeping queues small and
thus latencies low. When using an unbounded channel a fast producer
continues being a fast producer, growing the channel buffer
indefinitely, increasing latency until the illusion of unboundedness
breaks and the system runs out of memory.
One may use an unbounded channel if one enforces backpressure through an
out-of-band mechanism, e.g. the consumer granting the producer
send-tokens through a side-channel.
Add document outlining a set of coding guidelines followed and to be
followed across the rust-libp2p code base.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
When generating an `OutEvent` `enum` definition for a user, derive `Debug`
for that `enum`.
Why not derive `Clone`, `PartialEq` and `Eq` for the generated `enum`
definition?
While it is fine to require all sub-`OutEvent`s to implement
`Debug`, the same does not apply to traits like `Clone`. I
suggest users that need `Clone` to define their own `OutEvent`.
