Enum libp2p_kad::Event
source · pub enum Event {
InboundRequest {
request: InboundRequest,
},
OutboundQueryProgressed {
id: QueryId,
result: QueryResult,
stats: QueryStats,
step: ProgressStep,
},
RoutingUpdated {
peer: PeerId,
is_new_peer: bool,
addresses: Addresses,
bucket_range: (Distance, Distance),
old_peer: Option<PeerId>,
},
UnroutablePeer {
peer: PeerId,
},
RoutablePeer {
peer: PeerId,
address: Multiaddr,
},
PendingRoutablePeer {
peer: PeerId,
address: Multiaddr,
},
}
Expand description
The events produced by the Kademlia
behaviour.
Variants§
InboundRequest
Fields
request: InboundRequest
An inbound request has been received and handled.
OutboundQueryProgressed
Fields
result: QueryResult
The intermediate result of the query.
stats: QueryStats
Execution statistics from the query.
step: ProgressStep
Indicates which event this is, if therer are multiple responses for a single query.
An outbound query has made progress.
RoutingUpdated
Fields
is_new_peer: bool
Whether this is a new peer and was thus just added to the routing table, or whether it is an existing peer who’s addresses changed.
The routing table has been updated with a new peer and / or address, thereby possibly evicting another peer.
UnroutablePeer
A peer has connected for whom no listen address is known.
If the peer is to be added to the routing table, a known
listen address for the peer must be provided via Behaviour::add_address
.
RoutablePeer
A connection to a peer has been established for whom a listen address
is known but the peer has not been added to the routing table either
because BucketInserts::Manual
is configured or because
the corresponding bucket is full.
If the peer is to be included in the routing table, it must
must be explicitly added via Behaviour::add_address
, possibly after
removing another peer.
See Behaviour::kbucket
for insight into the contents of
the k-bucket of peer
.
PendingRoutablePeer
A connection to a peer has been established for whom a listen address is known but the peer is only pending insertion into the routing table if the least-recently disconnected peer is unresponsive, i.e. the peer may not make it into the routing table.
If the peer is to be unconditionally included in the routing table,
it should be explicitly added via Behaviour::add_address
after
removing another peer.
See Behaviour::kbucket
for insight into the contents of
the k-bucket of peer
.