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>
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()
)
```
Concurrently dial address candidates within a single dial attempt.
Main motivation for this feature is to increase success rate on hole punching
(see https://github.com/libp2p/rust-libp2p/issues/1896#issuecomment-885894496
for details). Though, as a nice side effect, as one would expect, it does
improve connection establishment time.
Cleanups and fixes done along the way:
- Merge `pool.rs` and `manager.rs`.
- Instead of manually implementing state machines in `task.rs` use
`async/await`.
- Fix bug where `NetworkBehaviour::inject_connection_closed` is called without a
previous `NetworkBehaviour::inject_connection_established` (see
https://github.com/libp2p/rust-libp2p/issues/2242).
- Return handler to behaviour on incoming connection limit error. Missed in
https://github.com/libp2p/rust-libp2p/issues/2242.
Require `NetworkBehaviourAction::{DialPeer,DialAddress}` to contain a
`ProtocolsHandler`. This allows a behaviour to attach custom state to its
handler. The behaviour would no longer need to track this state separately
during connection establishment, thus reducing state required in a behaviour.
E.g. in the case of `libp2p-kad` the behaviour can include a `GetRecord` request
in its handler, or e.g. in the case of `libp2p-request-response` the behaviour
can include the first request in the handler.
Return `ProtocolsHandler` on connection error and close. This allows a behaviour
to extract its custom state previously included in the handler on connection
failure and connection closing. E.g. in the case of `libp2p-kad` the behaviour
could extract the attached `GetRecord` from the handler of the failed connection
and then start another connection attempt with a new handler with the same
`GetRecord` or bubble up an error to the user.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
* Make clippy "happy".
Address all clippy complaints that are not purely stylistic (or even
have corner cases with false positives). Ignore all "style" and "pedantic" lints.
* Fix tests.
* Undo unnecessary API change.
`is_pending_outbound` should return true if the connection
to the mentioned peer hasn't been established, yet.
Closes issue: #1885
Signed-off-by: Tejas Sanap <sanap.tejas@gmail.com>
A user of libp2p-request-response is guaranteed to receive an additional event
after receiving a request via `RequestResponseEvent::Message`.
After receiving the request:
- If the user responds in time and the connection is still alive, the
user can expect a `ResponseSent`.
- If the user drops the response channel, the user can expect an
`InboundFailure::ResponseOmission`.
- If the user does not respond in time, the user can expect an
`InboundFailure::Timeout`.
Thus far the user did not receive an event when the connection to the
peer closes. With this commit:
- If the connection to the peer closes before the users calls
`send_response` or after the user calls `send_response` but before the
response can be send on the network, the user can expect an
`InboundFailure::ConnectionClosed`.
* Refine error reporting for inbound request handling.
At the moment one can neither get confirmation when a
response has been sent on the underlying transport, nor
is one aware of response omissions. The latter was
originally intended as a feature for support of
one-way protocols, which seems like a bad idea in
hindsight. The lack of notification for sent
responses may prohibit implementation of some
request-response protocols that need to ensure
a happens-before relation between sending a
response and a subsequent request, besides uses
for collecting statistics.
Even with these changes, there is no active notification
for failed inbound requests as a result of connections
unexpectedly closing, as is the case for outbound requests.
Instead, for pending inbound requests this scenario
can be identified if necessary by the absense of both
`InboundFailure` and `ResponseSent` events for a particular
previously received request. Interest in this situation is
not expected to be common and would otherwise require
explicitly tracking all inbound requests in the `RequestResponse`
behaviour, which would be a pity. `RequestResponse::send_response`
now also synchronously returns an error if the inbound upgrade
handling the request has been aborted, due to timeout or
closing of the connection, giving more options for graceful
error handling for inbound requests.
As an aside, the `Throttled` wrapper now no longer emits
inbound or outbound error events occurring in the context
of sending credit requests or responses. This is in addition
to not emitting `ResponseSent` events for ACK responses of
credit grants.
* Update protocols/request-response/src/lib.rs
Co-authored-by: Max Inden <mail@max-inden.de>
* Address some minor clippy warnings. (#1868)
* Track pending credit request IDs.
In order to avoid emitting events relating to credit grants or acks
on the public API. The public API should only emit events relating
to the actual requests and responses sent by client code.
* Small cleanup
* Cleanup
* Update versions and changelogs.
* Unreleased
Co-authored-by: Max Inden <mail@max-inden.de>
* Restore `RequestResponse::throttled`.
In contrast to the existing "throttled" approach this PR adds back-
pressure to the protocol without requiring pre-existing knowledge
of all nodes about their limits. It adds small, CBOR-encoded headers
to the actual payload data. Extra credit messages communicate back
to the sender how many more requests it is allowed to send.
* Remove some noise.
* Resend credit grant after connection closed.
Should an error in some lower layer cause a connection to be closed,
our previously sent credit grant may not have reached the remote peer.
Therefore, pessimistically, a credit grant is resent whenever a
connection is closed. The remote ignores duplicate grants.
* Remove inbound/outbound tracking per peer.
* Send ACK as response to duplicate credit grants.
* Simplify.
* Fix grammar.
* Incorporate review feedback.
- Remove `ResponseSent` which was a leftover from previous attemps
and issue a credit grant immediately in `send_response`.
- Only resend credit grants after a connection is closed if we are
still connected to this peer.
* Move codec/header.rs to throttled/codec.rs.
* More review suggestions.
* Generalise `ProtocolWrapper` and use shorter prefix.
* Update protocols/request-response/src/lib.rs
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Update protocols/request-response/src/throttled.rs
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Update protocols/request-response/src/throttled.rs
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Minor comment changes.
* Limit max. header size to 8KiB
* Always construct initial limit with 1.
Since honest senders always assume a send budget of 1 and wait for
credit afterwards, setting the default limit to a higher value
can only become effective after informing the peer about it which
means leaving `max_recv` at 1 and setting `next_max` to the desired
value.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Use a single exchange instead of two one_shots.
* Add `Throttled` to libp2p-request-response.
Wraps the existing `RequestResponse` behaviour and applies strict limits
to the number of inbound and outbound requests per peer.
The wrapper is opt-in and if not used, the protocol behaviour of
`RequestResponse` does not change. This PR also does not introduce
an extra protocol, hence the limits applied need to be known a priori
for all nodes which is not always possible or desirable. As mentioned
in #1687 I think that we should eventually augment the protocol with
metadata which allows a more dynamic exchange of requests and responses.
This PR also replaces the two oneshot channels with a single one from the
scambio crate which saves one allocation per request/response. If not
desirable because the crate has seen less testing the first commit could
be reverted.
* Fix rustdoc error.
* Remove some leftovers from development.
* Add docs to `NetworBehaviourAction::{map_in,map_out}`.
* Apply suggestions from code review
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Add `ping_protocol_throttled` test.
* Add another test.
* Revert "Use a single exchange instead of two one_shots."
This reverts commit e34e1297d411298f6c69e238aa6c96e0b795d989.
# Conflicts:
# protocols/request-response/Cargo.toml
# protocols/request-response/src/handler/protocol.rs
* Update CHANGELOG.
* Update CHANGELOG.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Add the libp2p-request-response protocol.
This crate provides a generic implementation for request/response
protocols, whereby each request is sent on a new substream.
* Fix OneShotHandler usage in floodsub.
* Custom ProtocolsHandler and multiple protocols.
1. Implement a custom ProtocolsHandler instead of using
the OneShotHandler for better control and error handling.
In particular, all request/response sending/receiving is
kept in the substreams upgrades and thus the background
task of a connection.
2. Support multiple protocols (usually protocol versions)
with a single `RequestResponse` instance, with
configurable inbound/outbound support.
* Small doc clarification.
* Remove unnecessary Sync bounds.
* Remove redundant Clone constraint.
* Update protocols/request-response/Cargo.toml
Co-authored-by: Toralf Wittner <tw@dtex.org>
* Update dev-dependencies.
* Update Cargo.tomls.
* Add changelog.
* Remove Sync bound from RequestResponseCodec::Protocol.
Apparently the compiler just needs some help with the scope
of borrows, which is unfortunate.
* Try async-trait.
* Allow checking whether a ResponseChannel is still open.
Also expand the commentary on `send_response` to indicate that
responses may be discard if they come in too late.
* Add `RequestResponse::is_pending`.
As an analogue of `ResponseChannel::is_open` for outbound requests.
* Revert now unnecessary changes to the OneShotHandler.
Since `libp2p-request-response` is no longer using it.
* Update CHANGELOG for libp2p-swarm.
Co-authored-by: Toralf Wittner <tw@dtex.org>
