2021-04-01 15:46:41 +02:00
|
|
|
// Copyright 2021 Protocol Labs.
|
|
|
|
//
|
|
|
|
// Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
// copy of this software and associated documentation files (the "Software"),
|
|
|
|
// to deal in the Software without restriction, including without limitation
|
|
|
|
// the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
// and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
// Software is furnished to do so, subject to the following conditions:
|
|
|
|
//
|
|
|
|
// The above copyright notice and this permission notice shall be included in
|
|
|
|
// all copies or substantial portions of the Software.
|
|
|
|
//
|
|
|
|
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
|
|
// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
// DEALINGS IN THE SOFTWARE.
|
|
|
|
|
|
|
|
//! # Ping Tutorial - Getting started with rust-libp2p
|
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! This tutorial aims to give newcomers a hands-on overview of how to use the
|
2021-04-01 15:46:41 +02:00
|
|
|
//! Rust libp2p implementation. People new to Rust likely want to get started on
|
|
|
|
//! [Rust](https://www.rust-lang.org/) itself, before diving into all the
|
|
|
|
//! networking fun. This library makes heavy use of asynchronous Rust. In case
|
2022-03-06 17:43:09 +01:00
|
|
|
//! you are not familiar with this concept, the Rust
|
2021-04-01 15:46:41 +02:00
|
|
|
//! [async-book](https://rust-lang.github.io/async-book/) should prove useful.
|
2022-03-06 17:43:09 +01:00
|
|
|
//! People new to libp2p might prefer to get a general overview at
|
|
|
|
//! [libp2p.io](https://libp2p.io/)
|
|
|
|
//! first, although libp2p knowledge is not required for this tutorial.
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! We are going to build a small `ping` clone, sending a ping to a peer,
|
|
|
|
//! expecting a pong as a response.
|
|
|
|
//!
|
|
|
|
//! ## Scaffolding
|
|
|
|
//!
|
|
|
|
//! Let's start off by
|
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! 1. Updating to the latest Rust toolchain, e.g.: `rustup update`
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! 2. Creating a new crate: `cargo init rust-libp2p-tutorial`
|
|
|
|
//!
|
|
|
|
//! 3. Adding `libp2p` as well as `futures` as dependencies in the
|
|
|
|
//! `Cargo.toml` file. Current crate versions may be found at
|
|
|
|
//! [crates.io](https://crates.io/).
|
|
|
|
//! We will also include `async-std` with the
|
|
|
|
//! "attributes" feature to allow for an `async main`.
|
|
|
|
//! At the time of writing we have:
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! ```yaml
|
|
|
|
//! [package]
|
|
|
|
//! name = "rust-libp2p-tutorial"
|
|
|
|
//! version = "0.1.0"
|
2021-11-26 09:34:58 -07:00
|
|
|
//! edition = "2021"
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! [dependencies]
|
2023-05-15 16:11:13 +02:00
|
|
|
//! libp2p = { version = "0.50", features = ["tcp", "dns", "async-std", "noise", "yamux", "websocket", "ping", "macros"] }
|
2022-03-06 17:43:09 +01:00
|
|
|
//! futures = "0.3.21"
|
2023-09-12 13:09:27 +03:00
|
|
|
//! env_logger = "0.10.0"
|
2023-01-27 02:33:17 +00:00
|
|
|
//! async-std = { version = "1.12.0", features = ["attributes"] }
|
2021-04-01 15:46:41 +02:00
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Network identity
|
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! With all the scaffolding in place, we can dive into the libp2p specifics.
|
|
|
|
//! First we need to create a network identity for our local node in `async fn
|
2021-12-06 11:32:58 -05:00
|
|
|
//! main()`, annotated with an attribute to allow `main` to be `async`.
|
2022-03-06 17:43:09 +01:00
|
|
|
//! Identities in libp2p are handled via a public/private key pair.
|
2021-04-01 15:46:41 +02:00
|
|
|
//! Nodes identify each other via their [`PeerId`](crate::PeerId) which is
|
2022-03-06 17:43:09 +01:00
|
|
|
//! derived from their public key. Now, replace the contents of main.rs by:
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! ```rust
|
|
|
|
//! use libp2p::{identity, PeerId};
|
|
|
|
//! use std::error::Error;
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
2021-04-01 15:46:41 +02:00
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
2023-01-27 02:33:17 +00:00
|
|
|
//! println!("Local peer id: {local_peer_id:?}");
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! Ok(())
|
|
|
|
//! }
|
|
|
|
//! ```
|
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! Go ahead and build and run the above code with: `cargo run`. A unique
|
|
|
|
//! [`PeerId`](crate::PeerId) should be displayed.
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! ## Transport
|
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! Next up we need to construct a transport. A transport in libp2p provides
|
|
|
|
//! connection-oriented communication channels (e.g. TCP) as well as upgrades
|
|
|
|
//! on top of those like authentication and encryption protocols. Technically,
|
|
|
|
//! a libp2p transport is anything that implements the [`Transport`] trait.
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! Instead of constructing a transport ourselves for this tutorial, we use the
|
|
|
|
//! convenience function [`development_transport`](crate::development_transport)
|
|
|
|
//! that creates a TCP transport with [`noise`](crate::noise) for authenticated
|
|
|
|
//! encryption.
|
|
|
|
//!
|
|
|
|
//! Furthermore, [`development_transport`] builds a multiplexed transport,
|
|
|
|
//! whereby multiple logical substreams can coexist on the same underlying (TCP)
|
|
|
|
//! connection. For further details on substream multiplexing, take a look at
|
|
|
|
//! [`crate::core::muxing`] and [`yamux`](crate::yamux).
|
|
|
|
//!
|
|
|
|
//! ```rust
|
|
|
|
//! use libp2p::{identity, PeerId};
|
|
|
|
//! use std::error::Error;
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
2021-04-01 15:46:41 +02:00
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
2023-01-27 02:33:17 +00:00
|
|
|
//! println!("Local peer id: {local_peer_id:?}");
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! let transport = libp2p::development_transport(local_key).await?;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! Ok(())
|
|
|
|
//! }
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Network behaviour
|
|
|
|
//!
|
2022-03-06 17:43:09 +01:00
|
|
|
//! Now it is time to look at another core trait of rust-libp2p: the
|
2021-04-01 15:46:41 +02:00
|
|
|
//! [`NetworkBehaviour`]. While the previously introduced trait [`Transport`]
|
|
|
|
//! defines _how_ to send bytes on the network, a [`NetworkBehaviour`] defines
|
|
|
|
//! _what_ bytes to send on the network.
|
|
|
|
//!
|
|
|
|
//! To make this more concrete, let's take a look at a simple implementation of
|
2022-10-01 00:19:34 +10:00
|
|
|
//! the [`NetworkBehaviour`] trait: the [`ping::Behaviour`](crate::ping::Behaviour).
|
|
|
|
//! As you might have guessed, similar to the good old `ping` network tool,
|
|
|
|
//! libp2p [`ping::Behaviour`](crate::ping::Behaviour) sends a ping to a peer and expects
|
|
|
|
//! to receive a pong in turn. The [`ping::Behaviour`](crate::ping::Behaviour) does not care _how_
|
|
|
|
//! the ping and pong messages are sent on the network, whether they are sent via
|
2021-04-01 15:46:41 +02:00
|
|
|
//! TCP, whether they are encrypted via [noise](crate::noise) or just in
|
|
|
|
//! [plaintext](crate::plaintext). It only cares about _what_ messages are sent
|
|
|
|
//! on the network.
|
|
|
|
//!
|
|
|
|
//! The two traits [`Transport`] and [`NetworkBehaviour`] allow us to cleanly
|
|
|
|
//! separate _how_ to send bytes from _what_ bytes to send.
|
|
|
|
//!
|
2022-10-01 00:19:34 +10:00
|
|
|
//! With the above in mind, let's extend our example, creating a [`ping::Behaviour`](crate::ping::Behaviour) at the end:
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! ```rust
|
2023-09-20 04:02:29 +05:30
|
|
|
//! use libp2p::swarm::NetworkBehaviour;
|
2023-01-27 02:33:17 +00:00
|
|
|
//! use libp2p::{identity, ping, PeerId};
|
2021-04-01 15:46:41 +02:00
|
|
|
//! use std::error::Error;
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
2021-04-01 15:46:41 +02:00
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
2023-01-27 02:33:17 +00:00
|
|
|
//! println!("Local peer id: {local_peer_id:?}");
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! let transport = libp2p::development_transport(local_key).await?;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let behaviour = ping::Behaviour::default();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! Ok(())
|
|
|
|
//! }
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Swarm
|
|
|
|
//!
|
|
|
|
//! Now that we have a [`Transport`] and a [`NetworkBehaviour`], we need
|
|
|
|
//! something that connects the two, allowing both to make progress. This job is
|
|
|
|
//! carried out by a [`Swarm`]. Put simply, a [`Swarm`] drives both a
|
|
|
|
//! [`Transport`] and a [`NetworkBehaviour`] forward, passing commands from the
|
|
|
|
//! [`NetworkBehaviour`] to the [`Transport`] as well as events from the
|
2023-09-12 13:09:27 +03:00
|
|
|
//! [`Transport`] to the [`NetworkBehaviour`]. As you can see, after [`Swarm`] initialization, we
|
|
|
|
//! removed the print of the local [`PeerId`](crate::PeerId) because every time a [`Swarm`] is
|
|
|
|
//! created, it prints the local [`PeerId`](crate::PeerId) in the logs at the INFO level. In order
|
|
|
|
//! to continue to see the local [`PeerId`](crate::PeerId) you must initialize the logger
|
|
|
|
//! (In our example, `env_logger` is used)
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! ```rust
|
2023-09-20 04:02:29 +05:30
|
|
|
//! use libp2p::swarm::{NetworkBehaviour, SwarmBuilder};
|
2023-01-27 02:33:17 +00:00
|
|
|
//! use libp2p::{identity, ping, PeerId};
|
2021-04-01 15:46:41 +02:00
|
|
|
//! use std::error::Error;
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
2023-09-12 13:09:27 +03:00
|
|
|
//! env_logger::init();
|
2021-04-01 15:46:41 +02:00
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! let transport = libp2p::development_transport(local_key).await?;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let behaviour = ping::Behaviour::default();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-05-24 16:32:59 +02:00
|
|
|
//! let mut swarm = SwarmBuilder::with_async_std_executor(transport, behaviour, local_peer_id).build();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! Ok(())
|
|
|
|
//! }
|
2023-09-20 04:02:29 +05:30
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Idle connection timeout
|
|
|
|
//!
|
|
|
|
//! Now, for this example in particular, we need set the idle connection timeout.
|
|
|
|
//! Otherwise, the connection will be closed immediately.
|
|
|
|
//!
|
|
|
|
//! Whether you need to set this in your application too depends on your usecase.
|
|
|
|
//! Typically, connections are kept alive if they are "in use" by a certain protocol.
|
|
|
|
//! The ping protocol however is only an "auxiliary" kind of protocol.
|
|
|
|
//! Thus, without any other behaviour in place, we would not be able to observe the pings.
|
|
|
|
//!
|
|
|
|
//! ```rust
|
|
|
|
//! use libp2p::swarm::{NetworkBehaviour, SwarmBuilder};
|
|
|
|
//! use libp2p::{identity, ping, PeerId};
|
|
|
|
//! use std::error::Error;
|
|
|
|
//! use std::time::Duration;
|
|
|
|
//!
|
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
|
|
|
//! use std::time::Duration;
|
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
|
|
|
//! println!("Local peer id: {local_peer_id:?}");
|
|
|
|
//!
|
|
|
|
//! let transport = libp2p::development_transport(local_key).await?;
|
2023-01-27 02:33:17 +00:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let behaviour = ping::Behaviour::default();
|
|
|
|
//!
|
|
|
|
//! let mut swarm = SwarmBuilder::with_async_std_executor(transport, behaviour, local_peer_id)
|
|
|
|
//! .idle_connection_timeout(Duration::from_secs(30)) // Allows us to observe pings for 30 seconds.
|
|
|
|
//! .build();
|
|
|
|
//!
|
|
|
|
//! Ok(())
|
2023-01-27 02:33:17 +00:00
|
|
|
//! }
|
2021-04-01 15:46:41 +02:00
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Multiaddr
|
|
|
|
//!
|
|
|
|
//! With the [`Swarm`] in place, we are all set to listen for incoming
|
|
|
|
//! connections. We only need to pass an address to the [`Swarm`], just like for
|
|
|
|
//! [`std::net::TcpListener::bind`]. But instead of passing an IP address, we
|
|
|
|
//! pass a [`Multiaddr`] which is yet another core concept of libp2p worth
|
|
|
|
//! taking a look at.
|
|
|
|
//!
|
|
|
|
//! A [`Multiaddr`] is a self-describing network address and protocol stack that
|
|
|
|
//! is used to establish connections to peers. A good introduction to
|
2022-03-06 17:43:09 +01:00
|
|
|
//! [`Multiaddr`] can be found at
|
|
|
|
//! [docs.libp2p.io/concepts/addressing](https://docs.libp2p.io/concepts/addressing/)
|
|
|
|
//! and its specification repository
|
|
|
|
//! [github.com/multiformats/multiaddr](https://github.com/multiformats/multiaddr/).
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2021-08-09 15:07:14 +02:00
|
|
|
//! Let's make our local node listen on a new socket.
|
|
|
|
//! This socket is listening on multiple network interfaces at the same time. For
|
2022-03-06 17:43:09 +01:00
|
|
|
//! each network interface, a new listening address is created. These may change
|
2021-08-09 15:07:14 +02:00
|
|
|
//! over time as interfaces become available or unavailable.
|
2022-03-06 17:43:09 +01:00
|
|
|
//! For example, in case of our TCP transport it may (among others) listen on the
|
2021-08-09 15:07:14 +02:00
|
|
|
//! loopback interface (localhost) `/ip4/127.0.0.1/tcp/24915` as well as the local
|
2022-04-27 06:48:22 +00:00
|
|
|
//! network `/ip4/192.168.178.25/tcp/24915`.
|
2021-08-09 15:07:14 +02:00
|
|
|
//!
|
2021-04-01 15:46:41 +02:00
|
|
|
//! In addition, if provided on the CLI, let's instruct our local node to dial a
|
|
|
|
//! remote peer.
|
|
|
|
//!
|
|
|
|
//! ```rust
|
2023-09-20 04:02:29 +05:30
|
|
|
//! use libp2p::swarm::{NetworkBehaviour, SwarmBuilder};
|
2023-01-27 02:33:17 +00:00
|
|
|
//! use libp2p::{identity, ping, Multiaddr, PeerId};
|
2021-04-01 15:46:41 +02:00
|
|
|
//! use std::error::Error;
|
2023-09-20 04:02:29 +05:30
|
|
|
//! use std::time::Duration;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
2023-09-12 13:09:27 +03:00
|
|
|
//! env_logger::init();
|
2021-04-01 15:46:41 +02:00
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! let transport = libp2p::development_transport(local_key).await?;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let behaviour = ping::Behaviour::default();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let mut swarm = SwarmBuilder::with_async_std_executor(transport, behaviour, local_peer_id)
|
|
|
|
//! .idle_connection_timeout(Duration::from_secs(30)) // Allows us to observe pings for 30 seconds.
|
|
|
|
//! .build();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! // Tell the swarm to listen on all interfaces and a random, OS-assigned
|
|
|
|
//! // port.
|
|
|
|
//! swarm.listen_on("/ip4/0.0.0.0/tcp/0".parse()?)?;
|
|
|
|
//!
|
|
|
|
//! // Dial the peer identified by the multi-address given as the second
|
|
|
|
//! // command-line argument, if any.
|
|
|
|
//! if let Some(addr) = std::env::args().nth(1) {
|
2021-11-15 14:17:23 +01:00
|
|
|
//! let remote: Multiaddr = addr.parse()?;
|
|
|
|
//! swarm.dial(remote)?;
|
2023-01-27 02:33:17 +00:00
|
|
|
//! println!("Dialed {addr}")
|
2021-04-01 15:46:41 +02:00
|
|
|
//! }
|
|
|
|
//!
|
|
|
|
//! Ok(())
|
|
|
|
//! }
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Continuously polling the Swarm
|
|
|
|
//!
|
|
|
|
//! We have everything in place now. The last step is to drive the [`Swarm`] in
|
|
|
|
//! a loop, allowing it to listen for incoming connections and establish an
|
|
|
|
//! outgoing connection in case we specify an address on the CLI.
|
|
|
|
//!
|
|
|
|
//! ```no_run
|
|
|
|
//! use futures::prelude::*;
|
2023-09-20 04:02:29 +05:30
|
|
|
//! use libp2p::swarm::{NetworkBehaviour, SwarmEvent, SwarmBuilder};
|
2023-01-27 02:33:17 +00:00
|
|
|
//! use libp2p::{identity, ping, Multiaddr, PeerId};
|
2021-04-01 15:46:41 +02:00
|
|
|
//! use std::error::Error;
|
2023-09-20 04:02:29 +05:30
|
|
|
//! use std::time::Duration;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! #[async_std::main]
|
|
|
|
//! async fn main() -> Result<(), Box<dyn Error>> {
|
2023-09-12 13:09:27 +03:00
|
|
|
//! env_logger::init();
|
2021-04-01 15:46:41 +02:00
|
|
|
//! let local_key = identity::Keypair::generate_ed25519();
|
|
|
|
//! let local_peer_id = PeerId::from(local_key.public());
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! let transport = libp2p::development_transport(local_key).await?;
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let behaviour = ping::Behaviour::default();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
2023-09-20 04:02:29 +05:30
|
|
|
//! let mut swarm = SwarmBuilder::with_async_std_executor(transport, behaviour, local_peer_id)
|
|
|
|
//! .idle_connection_timeout(Duration::from_secs(30)) // Allows us to observe pings for 30 seconds.
|
|
|
|
//! .build();
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! // Tell the swarm to listen on all interfaces and a random, OS-assigned
|
|
|
|
//! // port.
|
|
|
|
//! swarm.listen_on("/ip4/0.0.0.0/tcp/0".parse()?)?;
|
|
|
|
//!
|
|
|
|
//! // Dial the peer identified by the multi-address given as the second
|
|
|
|
//! // command-line argument, if any.
|
|
|
|
//! if let Some(addr) = std::env::args().nth(1) {
|
2021-11-15 14:17:23 +01:00
|
|
|
//! let remote: Multiaddr = addr.parse()?;
|
|
|
|
//! swarm.dial(remote)?;
|
2023-01-27 02:33:17 +00:00
|
|
|
//! println!("Dialed {addr}")
|
2021-04-01 15:46:41 +02:00
|
|
|
//! }
|
|
|
|
//!
|
2021-12-06 11:32:58 -05:00
|
|
|
//! loop {
|
|
|
|
//! match swarm.select_next_some().await {
|
2023-01-27 02:33:17 +00:00
|
|
|
//! SwarmEvent::NewListenAddr { address, .. } => println!("Listening on {address:?}"),
|
|
|
|
//! SwarmEvent::Behaviour(event) => println!("{event:?}"),
|
2021-12-06 11:32:58 -05:00
|
|
|
//! _ => {}
|
2021-04-01 15:46:41 +02:00
|
|
|
//! }
|
2021-12-06 11:32:58 -05:00
|
|
|
//! }
|
2023-01-27 02:33:17 +00:00
|
|
|
//! }
|
2021-04-01 15:46:41 +02:00
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! ## Running two nodes
|
|
|
|
//!
|
|
|
|
//! For convenience the example created above is also implemented in full in
|
|
|
|
//! `examples/ping.rs`. Thus, you can either run the commands below from your
|
|
|
|
//! own project created during the tutorial, or from the root of the rust-libp2p
|
|
|
|
//! repository. Note that in the former case you need to ignore the `--example
|
|
|
|
//! ping` argument.
|
|
|
|
//!
|
|
|
|
//! You need two terminals. In the first terminal window run:
|
|
|
|
//!
|
|
|
|
//! ```sh
|
|
|
|
//! cargo run --example ping
|
|
|
|
//! ```
|
|
|
|
//!
|
2023-09-12 13:09:27 +03:00
|
|
|
//! It will print the new listening addresses, e.g.
|
2021-08-09 15:07:14 +02:00
|
|
|
//! ```sh
|
|
|
|
//! Listening on "/ip4/127.0.0.1/tcp/24915"
|
|
|
|
//! Listening on "/ip4/192.168.178.25/tcp/24915"
|
|
|
|
//! Listening on "/ip4/172.17.0.1/tcp/24915"
|
|
|
|
//! Listening on "/ip6/::1/tcp/24915"
|
|
|
|
//! ```
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! In the second terminal window, start a new instance of the example with:
|
|
|
|
//!
|
|
|
|
//! ```sh
|
|
|
|
//! cargo run --example ping -- /ip4/127.0.0.1/tcp/24915
|
|
|
|
//! ```
|
|
|
|
//!
|
2021-08-09 15:07:14 +02:00
|
|
|
//! Note: The [`Multiaddr`] at the end being one of the [`Multiaddr`] printed
|
|
|
|
//! earlier in terminal window one.
|
|
|
|
//! Both peers have to be in the same network with which the address is associated.
|
|
|
|
//! In our case any printed addresses can be used, as both peers run on the same
|
|
|
|
//! device.
|
2021-04-01 15:46:41 +02:00
|
|
|
//!
|
|
|
|
//! The two nodes will establish a connection and send each other ping and pong
|
|
|
|
//! messages every 15 seconds.
|
|
|
|
//!
|
|
|
|
//! [`Multiaddr`]: crate::core::Multiaddr
|
|
|
|
//! [`NetworkBehaviour`]: crate::swarm::NetworkBehaviour
|
|
|
|
//! [`Transport`]: crate::core::Transport
|
|
|
|
//! [`PeerId`]: crate::core::PeerId
|
|
|
|
//! [`Swarm`]: crate::swarm::Swarm
|
|
|
|
//! [`development_transport`]: crate::development_transport
|