Anton
e4b1aa1811
* client/network: upgrade to libp2p 0.51.0 * make discovery.rs compile * make peer_info.rs compile * changes to notifications and request-response proto * make service.rs compile * towards making request_responses.rs compile * make request_responses.rs compile * make request_responses.rs compile * fix notifications/behaviour.rs tests * fix warnings * remove old code * allow deprecated code (temporary) * upgrade to libp2p 0.51.1 * add TODO for behaviour tests * return empty vec if peer_id is absent https://github.com/paritytech/substrate/pull/13587#discussion_r1141695167 fyi: I don't really know what the old behaviour was. * update comment to reflect new defaults Closes #13338 * Revert "update comment to reflect new defaults" This reverts commit 7a981abd69308e9d522ec94905f181439a1b1dba. * remove config.rs (from wrong merge) * upgrade to libp2p 0.51.2 * fix formatting * use handle_pending_outbound_connection in networt_state RPC * update deps * use re-exports when we use other libp2p packages * Apply suggestions from code review Co-authored-by: Dmitry Markin <dmitry@markin.tech> * format code * handle potential errors in network_state RPC * only update libp2p crate * update libp2p-core * fix docs * use libp2p-identity instead of libp2p where it's possible. libp2p-identity is much smaller, hence makes sense to use it instead of larger libp2p crate. * Update client/network/src/discovery.rs Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com> * update Cargo.lock * add comment for per_connection_event_buffer_size current value is somewhat arbitrary and needs to be tweaked depending on memory usage and network worker sleep stats. * fix link format * update Cargo.lock * upgrade to libp2p 0.51.3 * deprecate mplex * Revert "deprecate mplex" This reverts commit 9e25820e706e464a0e962a8604861fcb2a7641eb. * Revert "upgrade to libp2p 0.51.3" This reverts commit 6544dd4138e2f89517bd7c7281fc78a638ec7040. * use new libp2p version in `statement` crate * pin version temporarily * libp2p 0.51.3 * deprecate mplex * deprecate legacy noise handshake * fix build error * update libp2p-identity * enable libp2p-identity:ed25519 feature in sc-consensus * enable ed25519 for peerset as well --------- Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com> Co-authored-by: parity-processbot <>
Polite gossiping.
This crate provides gossiping capabilities on top of a network.
Gossip messages are separated by two categories: "topics" and consensus engine ID. The consensus engine ID is sent over the wire with the message, while the topic is not, with the expectation that the topic can be derived implicitly from the content of the message, assuming it is valid.
Topics are a single 32-byte tag associated with a message, used to group those messages
in an opaque way. Consensus code can invoke broadcast_topic to attempt to send all messages
under a single topic to all peers who don't have them yet, and send_topic to
send all messages under a single topic to a specific peer.
Usage
- Implement the
Networktrait, representing the low-level networking primitives. It is already implemented onsc_network::NetworkService. - Implement the
Validatortrait. See the section below. - Decide on a
ConsensusEngineId. Each gossiping protocol should have a different one. - Build a
GossipEngineusing these three elements. - Use the methods of the
GossipEnginein order to send out messages and receive incoming messages.
What is a validator?
The primary role of a Validator is to process incoming messages from peers, and decide
whether to discard them or process them. It also decides whether to re-broadcast the message.
The secondary role of the Validator is to check if a message is allowed to be sent to a given
peer. All messages, before being sent, will be checked against this filter.
This enables the validator to use information it's aware of about connected peers to decide
whether to send messages to them at any given moment in time - In particular, to wait until
peers can accept and process the message before sending it.
Lastly, the fact that gossip validators can decide not to rebroadcast messages opens the door for neighbor status packets to be baked into the gossip protocol. These status packets will typically contain light pieces of information used to inform peers of a current view of protocol state.
License: GPL-3.0-or-later WITH Classpath-exception-2.0