7665e74cdb
Scenario: rust-libp2p node A dials rust-libp2p node B. B listens on a QUIC address. A dials B via the `libp2p-quic` `Transport` wrapped in a `libp2p-dns` `Transport`. Note that `libp2p-dns` in itself is not relevant here. Only the fact that `libp2p-dns` delays a dial is relevant, i.e. that it first does other async stuff (DNS lookup) before creating the QUIC dial. In fact, dialing an IP address through the DNS `Transport` where no DNS resolution is needed triggers the below just fine. 1. A calls `Swarm::dial` which creates a `libp2p-dns` dial. 2. That dial is spawned onto the connection `Pool`, thus starting the DNS resolution. 3. A continuously calls `Swarm::poll`. 4. `libp2p-quic` `Transport::poll` is called, finding no dialers in `self.dialer` given that the spawned dial is still only resolving the DNS address. 5. On the spawned connection task: 1. The DNS resolution finishes. 2. Thus calling `Transport::dial` on `libp1p-quic` (note that the DNS dial has a clone of the QUIC `Transport` wrapped in an `Arc<Mutex<_>>`). 3. That adds a dialer to `self.dialer`. Note that there are no listeners, i.e. `Swarm::listen_on` was never called. 4. `DialerState::new_dial` is called which adds a message to `self.pending_dials` and wakes `self.waker`. Given that on the last `Transport::poll` there was no `self.dialer`, that waker is empty. Result: The message is stuck in the `DialerState::pending_dials`. The message is never send to the endpoint driver. The dial never succeeds. This commit fixes the above, waking the `<Quic as Transport>:poll` method.
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.
-
For security related issues please file a private security vulnerability report or reach out to security@libp2p.io. Please do not file a public issue on GitHub.
-
To report bugs, suggest improvements or request new features please open a 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.
-
For general project updates and discussions join the biweekly libp2p Community Calls.
Repository Structure
The main components of this repository are structured as follows:
-
core/: The implementation oflibp2p-corewith itsTransportandStreamMuxerAPI 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 interfacesNetworkBehaviourandConnectionHandlerused 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.
Maintainers
(In alphabetical order.)
- Elena Frank (@elenaf9)
- João Oliveira (@jxs)
- Max Inden (@mxinden)
- Thomas Eizinger (@thomaseizinger)
Notable users
(open a pull request if you want your project to be added here)
- COMIT - Bitcoin–Monero Cross-chain Atomic Swap.
- Forest - An implementation of Filecoin written in Rust.
- fuel-core - A Rust implementation of the Fuel protocol.
- HotShot - Decentralized sequencer in Rust developed by Espresso Systems.
- ipfs-embed - A small embeddable ipfs implementation used and maintained by Actyx.
- iroh - Next-generation implementation of IPFS for Cloud & Mobile platforms.
- Lighthouse - Ethereum consensus client in Rust.
- Locutus - Global, observable, decentralized key-value store.
- rust-ipfs - IPFS implementation in Rust.
- Starcoin - A smart contract blockchain network that scales by layering.
- Subspace - Subspace Network reference implementation
- Substrate - Framework for blockchain innovation, used by Polkadot.