05a4b16bb3
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.
Central repository for work on libp2p
This repository is the central place for Rust development of the libp2p spec.
Getting started
-
Main documentation can be found on https://docs.rs/libp2p.
-
The examples folder contains small binaries showcasing the many protocols in this repository.
-
To report bugs, suggest improvements or request new features please open GitHub issue on this repository.
-
For rust-libp2p specific questions please use the GitHub Discussions forum https://github.com/libp2p/rust-libp2p/discussions.
-
For discussions and questions related to multiple libp2p implementations please use the libp2p Discourse forum https://discuss.libp2p.io.
Repository Structure
The main components of this repository are structured as follows:
-
core/: The implementation oflibp2p-corewith itsNetwork,TransportandStreamMuxerAPI on which almost all other crates depend. -
transports/: Implementations of transport protocols (e.g. TCP) and protocol upgrades (e.g. for authenticated encryption, compression, ...) based on thelibp2p-coreTransportAPI . -
muxers/: Implementations of theStreamMuxerinterface oflibp2p-core, e.g. (sub)stream multiplexing protocols on top of (typically TCP) connections. Multiplexing protocols are (mandatory)Transportupgrades. -
swarm/: The implementation oflibp2p-swarmbuilding onlibp2p-corewith the central interfacesNetworkBehaviourandProtocolsHandlerused to implement application protocols (seeprotocols/). -
protocols/: Implementations of application protocols based on thelibp2p-swarmAPIs. -
misc/: Utility libraries. -
examples/: Worked examples of built-in application protocols (seeprotocols/) with commonTransportconfigurations.
Community Guidelines
The libp2p project operates under the IPFS Code of Conduct.
tl;dr
- Be respectful.
- We're here to help: abuse@ipfs.io
- Abusive behavior is never tolerated.
- Violations of this code may result in swift and permanent expulsion from the IPFS [and libp2p] community.
- "Too long, didn't read" is not a valid excuse for not knowing what is in this document.
Notable users
(open a pull request if you want your project to be added here)
- https://github.com/paritytech/polkadot
- https://github.com/paritytech/substrate
- https://github.com/sigp/lighthouse
- https://github.com/golemfactory/golem-libp2p
- https://github.com/comit-network
- https://github.com/rs-ipfs/rust-ipfs
- https://github.com/marcopoloprotocol/marcopolo
- https://github.com/ChainSafe/forest
- https://github.com/ipfs-rust/ipfs-embed
- https://www.actyx.com/developers/