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>
With f2905c07f1246c3c3fdc1cde95f7e9c5c1c9b01a the secp256k1 feature is
disabled by default. Instead of enabling it in the dev-dependency,
simply use ed25519.
Unless restricted by orphan rules, implementing `From` is superior
because it implies `Into` but leaves the choice to the user, which
one to use. Especially for errors, `From` is convenient because that
is what `?` builds on.
Co-authored-by: Max Inden <mail@max-inden.de>
Signed-off-by: Emil Majchrzak <majchrzakemil@gitlab.com>
Co-authored-by: Emil Majchrzak <majchrzakemil@gitlab.com>
Co-authored-by: Max Inden <mail@max-inden.de>
This will allow capturing variables in these closures so that we can
make these functions aware of the forkId (necessary for altair).
Co-authored-by: Max Inden <mail@max-inden.de>
Don't close connection if ping protocol is unsupported by remote. Previously, a
failed protocol negotation for ping caused a force close of the connection. As a
result, all nodes in a network had to support ping. To allow networks where some
nodes don't support ping, we now emit `PingFailure::Unsupported` once for every
connection on which ping is not supported.
Co-authored-by: Max Inden <mail@max-inden.de>
Not all implementations of `NetworkBehaviour` need all callbacks.
We've have been adding new callbacks with default implementations
for a while now. There is no reason the initial ones cannot also
be defaulted, thus making it easier create new implementations.
Co-authored-by: Max Inden <mail@max-inden.de>
- Change `PublicKey::into_protobuf_encoding` to
`PublicKey::to_protobuf_encoding`.
- Change `PublicKey::into_peer_id` to `PublicKey::to_peer_id`.
- Change `PeerId::from_public_key(PublicKey)` to
`PeerId::from_public_key(&PublicKey)`.
- Add `From<&PublicKey> for PeerId`.
Co-authored-by: Max Inden <mail@max-inden.de>
* Fix needless question mark operator
* Don't convert from u64 to u64
LocalStreamId is already a u64, no need to convert.
* Don't use `.into()` to convert to the same type
* Don't specify lifetime if it can be inferred
* Use `vec!` macro if we immediately push to it
This creates the vector with the appropriate capacity.
* Don't index array when taking a reference is enough
Co-authored-by: Max Inden <mail@max-inden.de>
Given the following scenario:
1. Remote peer X connects and is added to `connected_peers`.
2. Remote peer X opens a Kademlia substream and thus confirms that it supports
the Kademlia protocol.
3. Remote peer X is added to the routing table as `Connected`.
4. Remote peer X disconnects and is thus marked as `Disconnected` in the routing
table.
5. Remote peer Y connects and is added to `connected_peers`.
6. Remote peer X re-connects and is added to `connected_peers`.
7. Remote peer Y opens a Kademlia substream and thus confirms that it supports
the Kademlia protocol.
8. Remote peer Y is added to the routing table. Given that the bucket is already
full the call to `entry.insert` returns `kbucket::InsertResult::Pending {
disconnected }` where disconnected is peer X.
While peer X is in `connected_peers` it has not yet (re-) confirmed that it
supports the Kademlia routing protocol and thus is still tracked as
`Disconnected` in the routing table. The `debug_assert` removed in this pull
request does not capture this scenario.
1. Deprecating the `write_one` function
Semantically, this function is a composition of `write_with_len_prefix` and
`io.close()`. This represents a footgun because the `close` functionality is
not obvious and only mentioned in the docs. Using this function multiple times
on a single substream will produces hard to debug behaviour.
2. Deprecating `read_one` and `write_with_len_prefix` functions
3. Introducing `write_length_prefixed` and `read_length_prefixed`
- These functions are symmetric and do exactly what you would expect, just
writing to the socket without closing
- They also have a symmetric interface (no more custom errors, just `io::Error`)
Co-authored-by: Max Inden <mail@max-inden.de>
Add `ExpandedSwarm::disconnect_peer_id` and
`NetworkBehaviourAction::CloseConnection` to close connections to a specific
peer via an `ExpandedSwarm` or `NetworkBehaviour`.
Co-authored-by: Max Inden <mail@max-inden.de>
Change `Stream` implementation of `ExpandedSwarm` to return all
`SwarmEvents` instead of only the `NetworkBehaviour`'s events.
Remove `ExpandedSwarm::next_event`. Users can use `<ExpandedSwarm as
StreamExt>::next` instead.
Remove `ExpandedSwarm::next`. Users can use `<ExpandedSwarm as
StreamExt>::filter_map` instead.
Add instructions on how to run a three node example where a listening
relay client listens via a relay server and a dialing relay client dials
the listening relay client via the relay server.
mdns keeps rediscovering nodes. this PR changes that to only emit events for new
nodes it discovered. In addition we make sure to only send a query if it is
really needed. Some logging is added for debugging purposes.
If you start listening after mdns joined a multicast group, the peers may not
discover eachother until the 5min timeout expires.
Co-authored-by: Max Inden <mail@max-inden.de>
