Max Inden 217dd2ca22
clippy.toml: Create config and disallow unbounded channels (#2823)
When using channels (e.g. `futures::channel::mpsc` or `std::sync::mpsc`)
always use the bounded variant, never use the unbounded variant. When
using a bounded channel, a slow consumer eventually slows down a fast
producer once the channel bound is reached, ideally granting the slow
consumer more system resources e.g. CPU time, keeping queues small and
thus latencies low.  When using an unbounded channel a fast producer
continues being a fast producer, growing the channel buffer
indefinitely, increasing latency until the illusion of unboundedness
breaks and the system runs out of memory.

One may use an unbounded channel if one enforces backpressure through an
out-of-band mechanism, e.g. the consumer granting the producer
send-tokens through a side-channel.
2022-08-20 07:31:45 +02:00

Central repository for work on libp2p

dependency status Crates.io docs.rs

This repository is the central place for Rust development of the libp2p spec.

Getting started

Repository Structure

The main components of this repository are structured as follows:

  • core/: The implementation of libp2p-core with its Transport and StreamMuxer API 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 the libp2p-core Transport API .

  • muxers/: Implementations of the StreamMuxer interface of libp2p-core, e.g. (sub)stream multiplexing protocols on top of (typically TCP) connections. Multiplexing protocols are (mandatory) Transport upgrades.

  • swarm/: The implementation of libp2p-swarm building on libp2p-core with the central interfaces NetworkBehaviour and ConnectionHandler used to implement application protocols (see protocols/).

  • protocols/: Implementations of application protocols based on the libp2p-swarm APIs.

  • misc/: Utility libraries.

  • examples/: Worked examples of built-in application protocols (see protocols/) with common Transport configurations.

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.)

Notable users

(open a pull request if you want your project to be added here)

Description
No description provided
Readme MIT 23 MiB
Languages
Rust 99.8%
JavaScript 0.2%