Type Alias libp2p::kad::KademliaEvent
source · pub type KademliaEvent = Event;
kad
module instead and refer to this type as kad::Event
.Aliased Type§
enum KademliaEvent {
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,
},
}
Variants§
InboundRequest
An inbound request has been received and handled.
Fields
request: InboundRequest
OutboundQueryProgressed
An outbound query has made progress.
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.
RoutingUpdated
The routing table has been updated with a new peer and / or address, thereby possibly evicting another peer.
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.
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
.