Mark constructors `Swarm::with_X_executor` as deprecated.
Move the deprecated functionality to `SwarmBuilder::with_X_executor`
Use `SwarmBuilder` throughout.
Resolves#3186.
Resolves#3107.
Pull-Request: #3588.
Instead of relying on `protoc` and buildscripts, we generate the bindings using `pb-rs` and version them within our codebase. This makes for a better IDE integration, a faster build and an easier use of `rust-libp2p` because we don't force the `protoc` dependency onto them.
Resolves#3024.
Pull-Request: #3312.
Previously, a `ConnectionHandler` was immediately requested from the `NetworkBehaviour` as soon as a new dial was initiated or a new incoming connection accepted.
With this patch, we delay the creation of the handler until the connection is actually established and fully upgraded, i.e authenticated and multiplexed.
As a consequence, `NetworkBehaviour::new_handler` is now deprecated in favor of a new set of callbacks:
- `NetworkBehaviour::handle_pending_inbound_connection`
- `NetworkBehaviour::handle_pending_outbound_connection`
- `NetworkBehaviour::handle_established_inbound_connection`
- `NetworkBehaviour::handle_established_outbound_connection`
All callbacks are fallible, allowing the `NetworkBehaviour` to abort the connection either immediately or after it is fully established. All callbacks also receive a `ConnectionId` parameter which uniquely identifies the connection. For example, in case a `NetworkBehaviour` issues a dial via `NetworkBehaviourAction::Dial`, it can unambiguously detect this dial in these lifecycle callbacks via the `ConnectionId`.
Finally, `NetworkBehaviour::handle_pending_outbound_connection` also replaces `NetworkBehaviour::addresses_of_peer` by allowing the behaviour to return more addresses to be used for the dial.
Resolves#2824.
Pull-Request: #3254.
Don't close the stream `protocol::recv`.
This is a short-term fix for #3298.
The issue behind this is a general one on the QUIC transport when closing streams, as described in #3343. This PR only circumvents the issue for identify. A proper solution for our QUIC transport still needs more thought.
Pull-Request: #3344.
We create the `ConnectionId` for the new connection as part of `DialOpts`. This allows `NetworkBehaviour`s to accurately track state regarding their own dial attempts.
This patch is the main enabler of https://github.com/libp2p/rust-libp2p/pull/3254. Removing the `handler` field will allow us to deprecate the `NetworkBehaviour::new_handler` function in favor of four new ones that give more control over the connection lifecycle.
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.
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`.
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.
This patch deprecates 3 out of 4 functions on `PollParameters`:
- `local_peer_id`
- `listened_addresses`
- `external_addresses`
The addresses can be obtained by inspecting the `FromSwarm` event. To make this easier, we introduce two utility structs in `libp2p-swarm`:
- `ExternalAddresses`
- `ListenAddresses`
A node's `PeerId` is always known to the caller, thus we can require them to pass it in.
Related: #3124.
Previously, we had one callback for each kind of message that a `ConnectionHandler` would receive from either its `NetworkBehaviour` or the connection itself.
With this patch, we combine these functions, resulting in two callbacks:
- `on_behaviour_event`
- `on_connection_event`
Resolves#3080.
Previously, the executor for connection tasks silently defaulted to a `futures::executor::ThreadPool`. This causes issues such as https://github.com/libp2p/rust-libp2p/issues/2230.
With this patch, we force the user to choose, which executor they want to run the connection tasks on which results in overall simpler API with less footguns.
Closes#3068.
* misc/metrics: Explicitly delegate event recording to each recorder
This allows delegating a single event to multiple `Recorder`s. That enables e.g. the
`identify::Metrics` `Recorder` to act both on `IdentifyEvent` and `SwarmEvent`. The latter enables
it to garbage collect per peer data on disconnects.
* protocols/dcutr: Expose PROTOCOL_NAME
* protocols/identify: Expose PROTOCOL_NAME and PUSH_PROTOCOL_NAME
* protocols/ping: Expose PROTOCOL_NAME
* protocols/relay: Expose HOP_PROTOCOL_NAME and STOP_PROTOCOL_NAME
* misc/metrics: Track # connected nodes supporting specific protocol
An example metric exposed with this patch:
```
libp2p_identify_protocols{protocol="/ipfs/ping/1.0.0"} 10
```
This implies that 10 of the currently connected nodes support the ping protocol.
Remove the concept of individual `Transport::Listener` streams from `Transport`.
Instead the `Transport` is polled directly via `Transport::poll`. The
`Transport` is now responsible for driving its listeners.
**Summary** of the plot of the `discover_peer_after_disconnect` test:
1. `swarm2` connects to `swarm1`.
2. `swarm2` requests an identify response from `swarm1`.
3. `swarm1` sends the response to `swarm2`.
4. `swarm2` disconnects from `swarm1`.
5. `swarm2` tries to disconnect.
**Problem**
`libp2p-identify` sets `KeepAlive::No` when it identified the remote. Thus `swarm1` might
identify` `swarm2` before `swarm2` identified `swarm1`. `swarm1` then sets `KeepAlive::No` and thus closes the
connection to `swarm2` before `swarm2` identified `swarm1`. In such case the unit test
`discover_peer_after_disconnect hangs indefinitely.
**Solution**
Add an initial delay to `swarm1` requesting an identification from `swarm2`, thus ensuring `swarm2`
is always able to identify `swarm1`.
An identify push contains the whole identify information of a remote
peer. Upgrading multiple inbound identify push streams is useless.
Instead older streams are dropped in favor of newer streams.
Previously `libp2p-swarm` required a `Transport` to be `Clone`. Methods
on `Transport`, e.g. `Transport::dial` would take ownership, requiring
e.g. a `Clone::clone` before calling `Transport::dial`.
The requirement of `Transport` to be `Clone` is no longer needed in
`libp2p-swarm`. E.g. concurrent dialing can be done without a clone per
dial.
This commit removes the requirement of `Clone` for `Transport` in
`libp2p-swarm`. As a follow-up methods on `Transport` no longer take
ownership, but instead a mutable reference (`&mut self`).
On the one hand this simplifies `libp2p-swarm`, on the other it
simplifies implementations of `Transport`.
A `ProtocolsHandler`, now `ConnectionHandler`, handels a connection, not
a protocol. Thus the name `CONNECTIONHandler` is more appropriate.
Next to the rename of `ProtocolsHandler` this commit renames the `mod
protocols_handler` to `mod handler`. Finally all combinators (e.g.
`ProtocolsHandlerSelect`) are renamed appropriately.
Allows `NetworkBehaviour` implementations to dial a peer, but instruct
the dialed connection to be upgraded as if it were the listening
endpoint.
This is needed when establishing direct connections through NATs and/or
Firewalls (hole punching). When hole punching via TCP (QUIC is different
but similar) both ends dial the other at the same time resulting in a
simultaneously opened TCP connection. To disambiguate who is the dialer
and who the listener there are two options:
1. Use the Simultaneous Open Extension of Multistream Select. See
[sim-open] specification and [sim-open-rust] Rust implementation.
2. Disambiguate the role (dialer or listener) based on the role within
the DCUtR [dcutr] protocol. More specifically the node initiating the
DCUtR process will act as a listener and the other as a dialer.
This commit enables (2), i.e. enables the DCUtR protocol to specify the
role used once the connection is established.
While on the positive side (2) requires one round trip less than (1), on
the negative side (2) only works for coordinated simultaneous dials.
I.e. when a simultaneous dial happens by chance, and not coordinated via
DCUtR, the connection attempt fails when only (2) is in place.
[sim-open]: https://github.com/libp2p/specs/blob/master/connections/simopen.md
[sim-open-rust]: https://github.com/libp2p/rust-libp2p/pull/2066
[dcutr]: https://github.com/libp2p/specs/blob/master/relay/DCUtR.md
* core: Mark "unused" field with "_"
We need to keep this marker type to ensure that the type continues
to be required to be pinned.
* tranports/noise: Derive `Default` for `Config`
`false` is the default for `bool`, we can derive this.
* protocols/request-response: Remove unused fields
These are already included the `RequestResponseMessage::Request`
variant.
* *: Allow clippy's large-enum-variant lint
Tackling these suggestions would require performance measurement
which we don't want to do at this stage.
Co-authored-by: Max Inden <mail@max-inden.de>
Check multiaddr has valid peer id component or none at all. We don't want to
cache a multiaddr with a purposely wrong multiaddr. e.g. something that ends
with .../p2p/some-other-peer. While this should fail to dial because we [check
this before
dialing](https://github.com/libp2p/rust-libp2p/blob/master/core/src/connection/pool/concurrent_dial.rs#L144),
it's better to not cache this in the first place.
Enable advanced dialing requests both on `Swarm` and via
`NetworkBehaviourAction`. Users can now trigger a dial with a specific
set of addresses, optionally extended via
`NetworkBehaviour::addresses_of_peer`. In addition the whole process is
now modelled in a type safe way via the builder pattern.
Example of a `NetworkBehaviour` requesting a dial to a specific peer
with a set of addresses additionally extended through
`NetworkBehaviour::addresses_of_peer`:
```rust
NetworkBehaviourAction::Dial {
opts: DialOpts::peer_id(peer_id)
.condition(PeerCondition::Always)
.addresses(addresses)
.extend_addresses_through_behaviour()
.build(),
handler,
}
```
Example of a user requesting a dial to an unknown peer with a single
address via `Swarm`:
```rust
swarm1.dial(
DialOpts::unknown_peer_id()
.address(addr2.clone())
.build()
)
```
