The gossipsub tests are calling lifecycle functions of the `NetworkBehaviour` that aren't meant to be called outside of `Swarm`. This already surfaced as a problem in https://github.com/libp2p/rust-libp2p/pull/3327 and it is coming up again in https://github.com/libp2p/rust-libp2p/pull/3254 where `new_handler` gets deprecated.
Try to mitigate that by constructing a dummy handler instead. Functionally, there is no difference as in both cases, the given handler has never seen a connection.
Storing `NetworkBehaviourAction`s within the behaviour is more flexible than only storing `OutEvent`s. Additionally, I find expression-oriented code easier to reason about because it typically doesn't contain side-effects.
This is much quicker to execute. To keep our CI reproducible, I opted to link to a specific version instead of the "latest" release. Updating to a new version is as easy as switching out the version number in the URL.
With this commit `libp2p-autonat` no longer discards the whole remote payload in case an addr is unparsable, but instead logs the failure and skips the unparsable multiaddr.
See libp2p#3244 for details.
Instead of offering a public constructor, users are now no longer able to construct `ConnectionId`s at all. They only public API exposed are the derived traits. Internally, `ConnectionId`s are monotonically incremented using a static atomic counter, thus no two connections will ever get assigned the same ID.
I suggest we remove the milestones section. @p-shahi let me know if you feel strongly about keeping it.
- Most items in milestones are either done or outdated
- Milestones are already tracked on each item
- Items are ordered by priority / date
The trick with this one is to use `futures::Either` everywhere where we may wrap something that implements any of the `futures` traits. This includes the output of `EitherFuture` itself. We also need to implement `StreamMuxer` on `future::Either` because `StreamMuxer`s may be the the `Output` of `InboundUpgrade`.
Instead of tracking an inner enum, move all fields of `Opts` into `DialOpts`, setting them directly once we construct them. This makes the getters a lot simpler to implement and reduces code duplication.
Currently, we only have a single channel for all established connections. This requires us to construct the channel ahead of time, before we even have a connection. As it turns out, sharing this buffer across all connections actually has downsides. In particular, this means a single, very busy connection can starve others by filling up this buffer, forcing other connections to wait until they can emit an event.
We can completely replace `EitherFuture2` with `EitherFuture`. `EitherFuture` itself cannot be removed for now because the `Future` implementation on `future::Either` forces both `Future`s to evaluate to the same type.
It doesn't appear that https://github.com/rust-lang/rust-clippy/issues/10061 is going to be fixed any time soon. In the meantime, our CI is "red" which is misleading because we purposely don't require this CI check. It will however hit stable in ~ 2 weeks at which point our required clippy CI check will fail.
Suppress clippy lint with an `allow` to make it pass.
With this commit `libp2p-dcutr` no longer discards the whole remote payload in case an addr is unparsable, but instead logs the failure and skips the unparsable multiaddr.
See https://github.com/libp2p/rust-libp2p/issues/3244 for details.
Scenario: rust-libp2p node A dials rust-libp2p node B. B listens on a QUIC address. A dials B via the `libp2p-quic` `Transport` wrapped in a `libp2p-dns` `Transport`.
Note that `libp2p-dns` in itself is not relevant here. Only the fact that `libp2p-dns` delays a dial is relevant, i.e. that it first does other async stuff (DNS lookup) before creating the QUIC dial. In fact, dialing an IP address through the DNS `Transport` where no DNS resolution is needed triggers the below just fine.
1. A calls `Swarm::dial` which creates a `libp2p-dns` dial.
2. That dial is spawned onto the connection `Pool`, thus starting the DNS resolution.
3. A continuously calls `Swarm::poll`.
4. `libp2p-quic` `Transport::poll` is called, finding no dialers in `self.dialer` given that the spawned dial is still only resolving the DNS address.
5. On the spawned connection task:
1. The DNS resolution finishes.
2. Thus calling `Transport::dial` on `libp1p-quic` (note that the DNS dial has a clone of the QUIC `Transport` wrapped in an `Arc<Mutex<_>>`).
3. That adds a dialer to `self.dialer`. Note that there are no listeners, i.e. `Swarm::listen_on` was never called.
4. `DialerState::new_dial` is called which adds a message to `self.pending_dials` and wakes `self.waker`. Given that on the last `Transport::poll` there was no `self.dialer`, that waker is empty.
Result: The message is stuck in the `DialerState::pending_dials`. The message is never send to the endpoint driver. The dial never succeeds.
This commit fixes the above, waking the `<Quic as Transport>:poll` method.
Trait bounds on struct declarations should be avoided as much as possible because they creep into every reference of the type. To supply default type parameters, we don't need the trait bounds.
As the name implies, `LegacyConfig` allows users to interact with older versions of the noise protocol. These are not interoperable and we've been supporting them for a long time now. Hopefully, users have migrated away from it since. To not directly break them, we officially deprecate now without a replacement.
Identify multiaddress with `/quic` (draft 29) as QUIC address in case `support_draft_29` is `true`.
Without this patch the Rust punchr client would discard any QUIC addresses with `/quic` in its `Transport::address_translation`. Thus `/quic` based observed addresses from `libp2p-identify` would not be added to the local set of external addresses and thus QUIC would not be available as a transport for hole punching.
With #3097, subscribing to the floodsub topic in `examples/chat-tokio.rs` was removed. I assume this was unintentional (cc @umgefahren), so this PR adds it back.
With the addition of more CI jobs, we are constantly running into API limits on setting up protoc. For all jobs that run on ubuntu, we can install it from `apt` instead.
On ubuntu 22.04, which is what `ubuntu-latest` points to, this installs `protoc v3.12.4`.
GitHub wraps the titles of commits if they are longer than 72 characters. See fbd4192e2a for example.
There is a convention that titles should be no more than 50 characters: https://cbea.ms/git-commit/#limit-50
This however makes crafting the message quite difficult, esp. with our use of conventional commit messages, thus limiting it to 72 seems more reasonable as that is where tooling (.e.g GitHub) seems to "break".
With this commit `libp2p-kad` no longer discards the whole peer payload in case an addr is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining payload.
See https://github.com/libp2p/rust-libp2p/issues/3244 for details.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
With this commit `libp2p-identify` no longer discards the whole identify payload in case a listen addr of the remote node is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining identify payload.
This is especially relevant when rolling out a new protocol to a live network. Say that most nodes of a network run on an implementation version v1. Say that the `multiaddr` implementation is not aware of the `webrtc/` protocol. Say that a new version (v2) is rolled out to the network with support for the `webrtc/` protocol, listening via `webrtc/` by default. In such case all v1 nodes would discard all identify payloads of v2 nodes, given that the v2 identify payloads would contain the `webrtc/` protocol in their `listen_addr` addresses.
See https://github.com/libp2p/rust-libp2p/issues/3244 for details.
