|
1 |
| -#![warn(rust_2018_idioms)] |
2 | 1 | #![deny(rustdoc::broken_intra_doc_links)]
|
3 |
| -#![cfg_attr(docsrs, feature(doc_cfg))] |
4 |
| -#![allow(clippy::needless_doctest_main)] |
5 | 2 | //! An implementation of [Discovery V5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md).
|
6 | 3 | //!
|
7 | 4 | //! # Overview
|
8 | 5 | //!
|
9 |
| -//! Discovery v5 is a protocol designed for encrypted peer discovery and topic advertisement. Each peer/node |
10 |
| -//! on the network is identified via it's ENR ([Ethereum Name |
| 6 | +//! Discovery v5 is a protocol designed for encrypted peer discovery and topic advertisement. Each |
| 7 | +//! peer/node on the network is identified via it's ENR ([Ethereum Name |
11 | 8 | //! Record](https://eips.ethereum.org/EIPS/eip-778)), which is essentially a signed key-value store
|
12 | 9 | //! containing the node's public key and optionally IP address and port.
|
13 | 10 | //!
|
14 |
| -//! Discv5 employs a kademlia-like routing table to store and manage discovered peers (and topics tba). The |
15 |
| -//! protocol allows for external IP discovery in NAT environments through regular PING/PONG's with |
| 11 | +//! Discv5 employs a kademlia-like routing table to store and manage discovered peers. The protocol |
| 12 | +//! allows for external IP discovery in NAT environments through regular PING/PONG's with |
16 | 13 | //! discovered nodes. Nodes return the external IP address that they have received and a simple
|
17 | 14 | //! majority is chosen as our external IP address. If an external IP address is updated, this is
|
18 |
| -//! produced as an event to notify the swarm (if one is used for this behaviour). |
| 15 | +//! produced as an event. |
19 | 16 | //!
|
20 |
| -//! For a simple CLI discovery service see [discv5-cli](https://github.com/AgeManning/discv5-cli) |
| 17 | +//! For a simple CLI discovery service see [discv5-cli](https://github.com/AgeManning/discv5-cli) |
21 | 18 | //!
|
22 |
| -//! This protocol is split into four main sections/layers: |
| 19 | +//! This protocol is split into four main layers: |
23 | 20 | //!
|
24 |
| -//! * Socket - The [`socket`] module is responsible for opening the underlying UDP socket. It |
25 |
| -//! creates individual tasks for sending/encoding and receiving/decoding packets from the UDP |
26 |
| -//! socket. |
27 |
| -//! * Handler - The protocol's communication is encrypted with `AES_GCM`. All node communication |
28 |
| -//! undergoes a handshake, which results in a [`Session`]. [`Session`]'s are established when |
29 |
| -//! needed and get dropped after a timeout. This section manages the creation and maintenance of |
30 |
| -//! sessions between nodes and the encryption/decryption of packets from the socket. It is |
31 |
| -//! realised by the [`handler::Handler`] struct and it runs in its own task. |
32 |
| -//! * Service - This section contains the protocol-level logic. In particular it manages the |
33 |
| -//! routing table of known ENR's, (and topic registration/advertisement tba) and performs |
34 |
| -//! parallel queries for peer discovery. This section is realised by the [`Service`] struct. This |
35 |
| -//! also runs in it's own thread. |
36 |
| -//! * Application - This section is the user-facing API which can start/stop the underlying |
37 |
| -//! tasks, initiate queries and obtain metrics about the underlying server. |
| 21 | +//! - [`socket`]: Responsible for opening the underlying UDP socket. It creates individual tasks |
| 22 | +//! for sending/encoding and receiving/decoding packets from the UDP socket. |
| 23 | +//! - [`handler`]: The protocol's communication is encrypted with `AES_GCM`. All node communication |
| 24 | +//! undergoes a handshake, which results in a `Session`. These are established when needed and get |
| 25 | +//! dropped after a timeout. The creation and maintenance of sessions between nodes and the |
| 26 | +//! encryption/decryption of packets from the socket is realised by the [`handler::Handler`] struct |
| 27 | +//! runnning in its own task. |
| 28 | +//! - [`service`]: Contains the protocol-level logic. The [`service::Service`] manages the routing |
| 29 | +//! table of known ENR's, and performs parallel queries for peer discovery. It also runs in it's |
| 30 | +//! own task. |
| 31 | +//! - [`Discv5`]: The application level. Manages the user-facing API. It starts/stops the underlying |
| 32 | +//! tasks, allows initiating queries and obtain metrics about the underlying server. |
38 | 33 | //!
|
39 |
| -//! ## Event Stream |
| 34 | +//! ## Event Stream |
40 | 35 | //!
|
41 |
| -//! The [`Discv5`] struct provides access to an event-stream which allows the user to listen to |
42 |
| -//! [`Discv5Event`] that get generated from the underlying server. The stream can be obtained |
43 |
| -//! from the [`Discv5::event_stream()`] function. |
| 36 | +//! The [`Discv5`] struct provides access to an event-stream which allows the user to listen to |
| 37 | +//! [`Discv5Event`] that get generated from the underlying server. The stream can be obtained from |
| 38 | +//! the [`Discv5::event_stream`] function. |
44 | 39 | //!
|
45 |
| -//! ## Runtimes |
| 40 | +//! ## Runtimes |
46 | 41 | //!
|
47 |
| -//! Discv5 requires a tokio runtime with timing and io enabled. An explicit runtime can be given |
48 |
| -//! via the configuration. See the [`Discv5ConfigBuilder`] for further details. Such a runtime |
49 |
| -//! must implement the [`Executor`] trait. |
| 42 | +//! Discv5 requires a tokio runtime with timing and io enabled. An explicit runtime can be given |
| 43 | +//! via the configuration. See the [`Discv5ConfigBuilder`] for further details. Such a runtime must |
| 44 | +//! implement the [`Executor`] trait. |
50 | 45 | //!
|
51 |
| -//! If an explicit runtime is not provided via the configuration parameters, it is assumed that |
52 |
| -//! a tokio runtime is present when creating the [`Discv5`] struct. The struct will use the |
53 |
| -//! existing runtime for spawning the underlying server tasks. If a runtime is not present, the |
54 |
| -//! creation of the [`Discv5`] struct will panic. |
| 46 | +//! If an explicit runtime is not provided via the configuration parameters, it is assumed that a |
| 47 | +//! tokio runtime is present when creating the [`Discv5`] struct. The struct will use the existing |
| 48 | +//! runtime for spawning the underlying server tasks. If a runtime is not present, the creation of |
| 49 | +//! the [`Discv5`] struct will panic. |
55 | 50 | //!
|
56 | 51 | //! # Usage
|
57 | 52 | //!
|
|
98 | 93 | //! println!("Found nodes: {:?}", found_nodes);
|
99 | 94 | //! });
|
100 | 95 | //! ```
|
101 |
| -//! |
102 |
| -//! [`Discv5`]: struct.Discv5.html |
103 |
| -//! [`Discv5Event`]: enum.Discv5Event.html |
104 |
| -//! [`Discv5Config`]: config/struct.Discv5Config.html |
105 |
| -//! [`Discv5ConfigBuilder`]: config/struct.Discv5ConfigBuilder.html |
106 |
| -//! [Packet]: packet/enum.Packet.html |
107 |
| -//! [`Service`]: service/struct.Service.html |
108 |
| -//! [`Session`]: session/struct.Session.html |
109 | 96 |
|
110 | 97 | mod config;
|
111 | 98 | mod discv5;
|
|
0 commit comments