libp2p_core/
lib.rs

1// Copyright 2017-2018 Parity Technologies (UK) Ltd.
2//
3// Permission is hereby granted, free of charge, to any person obtaining a
4// copy of this software and associated documentation files (the "Software"),
5// to deal in the Software without restriction, including without limitation
6// the rights to use, copy, modify, merge, publish, distribute, sublicense,
7// and/or sell copies of the Software, and to permit persons to whom the
8// Software is furnished to do so, subject to the following conditions:
9//
10// The above copyright notice and this permission notice shall be included in
11// all copies or substantial portions of the Software.
12//
13// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
14// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
15// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
16// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
17// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
18// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
19// DEALINGS IN THE SOFTWARE.
20
21//! Transports, upgrades, multiplexing and node handling of *libp2p*.
22//!
23//! The main concepts of libp2p-core are:
24//!
25//! - A [`PeerId`] is a unique global identifier for a node on the network.
26//!   Each node must have a different [`PeerId`]. Normally, a [`PeerId`] is the
27//!   hash of the public key used to negotiate encryption on the
28//!   communication channel, thereby guaranteeing that they cannot be spoofed.
29//! - The [`Transport`] trait defines how to reach a remote node or listen for
30//!   incoming remote connections. See the [`transport`] module.
31//! - The [`StreamMuxer`] trait is implemented on structs that hold a connection
32//!   to a remote and can subdivide this connection into multiple substreams.
33//!   See the [`muxing`] module.
34//! - The [`UpgradeInfo`], [`InboundUpgrade`] and [`OutboundUpgrade`] traits
35//!   define how to upgrade each individual substream to use a protocol.
36//!   See the `upgrade` module.
37
38mod keys_proto {
39    include!(concat!(env!("OUT_DIR"), "/keys_proto.rs"));
40}
41
42/// Multi-address re-export.
43pub use multiaddr;
44pub type Negotiated<T> = multistream_select::Negotiated<T>;
45
46mod peer_id;
47mod translation;
48
49pub mod connection;
50pub mod either;
51pub mod identity;
52pub mod muxing;
53pub mod network;
54pub mod transport;
55pub mod upgrade;
56
57pub use multiaddr::Multiaddr;
58pub use multihash;
59pub use muxing::StreamMuxer;
60pub use peer_id::PeerId;
61pub use identity::PublicKey;
62pub use transport::Transport;
63pub use translation::address_translation;
64pub use upgrade::{InboundUpgrade, OutboundUpgrade, UpgradeInfo, UpgradeError, ProtocolName};
65pub use connection::{Connected, Endpoint, ConnectedPoint};
66pub use network::Network;
67
68use std::{future::Future, pin::Pin};
69
70/// Implemented on objects that can run a `Future` in the background.
71///
72/// > **Note**: While it may be tempting to implement this trait on types such as
73/// >           [`futures::stream::FuturesUnordered`], please note that passing an `Executor` is
74/// >           optional, and that `FuturesUnordered` (or a similar struct) will automatically
75/// >           be used as fallback by libp2p. The `Executor` trait should therefore only be
76/// >           about running `Future`s in the background.
77pub trait Executor {
78    /// Run the given future in the background until it ends.
79    fn exec(&self, future: Pin<Box<dyn Future<Output = ()> + Send>>);
80}
81
82impl<F: Fn(Pin<Box<dyn Future<Output = ()> + Send>>)> Executor for F {
83    fn exec(&self, f: Pin<Box<dyn Future<Output = ()> + Send>>) {
84        self(f)
85    }
86}
libp2p_core/lib.rs

libp2p_core/
lib.rs
