`libp2p_tcp::Transport::remove_listener` previously removed the first listener that *did not match* the provided `ListenerId`. This small fix brings it inline with other implementations.
While following the ping tutorial myself, I noticed it was out of date from the ping example in `examples/ping.rs`, and the code given in the tutorial no longer cleanly builds. I decided to update the tutorial to build the exact code in the example.
In case an error happens for an outgoing connection, `Pool` reports an `OutgoingConnectionError`. This one is mapped to a `DialError` and reported via `SwarmEvent::OutgoingConnectionError` and `FromSwarm::DialFailure`.
For incoming connections, we didn't quite do the same thing. For one, `SwarmEvent::IncomingConnectionError` directly contained a `PendingInboundConnectionError`. Two, `FromSwarm::ListenFailure` did not include an error at all.
With this patch, we now introduce a `ListenError` enum which we use in `SwarmEvent::IncomingConnectionError` and we pass a reference to it along in `FromSwarm::ListenFailure`.
Previously, we used the full reference to the `OutEvent` of the `ConnectionHandler` in all implementations of `NetworkBehaviour`. Not only is this very verbose, it is also more brittle to changes. With the current implementation plan for #2824, we will be removing the `IntoConnectionHandler` abstraction. Using a type-alias to refer to the `OutEvent` makes the migration much easier.
This patch adds a workflow that automatically publishes a docker image of our `ping` interop-test binaries on every release. Releases are different from Git tags. We publish a tag for each version of each crate but only a single release for each version of the `libp2p` crate.
Alternatively, this workflow can also be triggered manually:
1. Select the Git ref you want to run the workflow on. This should be the version of `libp2p` you want to publish the test binary for. For example, if you want to publish a version of the test binary for a hotfix release of a sub-crate, you would pick the respective tag of the hotfix release.
2. Choose the tag of the docker image.
To resolve https://github.com/libp2p/test-plans/issues/112, I am planning to create branches off current master that hardcodes the libp2p version in the test-binary to a particular one and then trigger this workflow for the respective branch.
Previously, inbound connections that happened to resolve to our own `PeerId` were reported as `WrongPeerId`. With this patch, we now report those in a dedicated `LocalPeerId` error.
Related: #3205.
We make the binary that should be copied into the container configurable via a build time `ARG`. This will allow us to reuse the same `Dockerfile` once we write more tests.
Additionally, this allows us to remove some of the directory switching and creation code. In order to not send the entire repository over to the docker daemon as a build context, we introduce a `.dockerignore` file that only allows select binary to be sent over.
The downside of this is that we need to extend this ignore file every time we add a new test. This shouldn't happen very often though and is easily discovered because the building of the docker container will fail.
Node and browser tests take a little bit longer to spin up in the interop tests. The multidim-interop can tell the tests to increase the timeout when testing against these targets, but the test itself needs to use the passed in value.
This updates the test code to handle the new test_timeout option. See https://github.com/libp2p/test-plans/issues/107
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.
