To give some context, here's some explanation of how the code works at the moment:

Libp2p is what handles connecting to other nodes.
When libp2p has established a connection, it instantiates a couple of "protocols handlers" structs. Substrate provides its own protocols handlers, one per protocol, and the gossiping-related protocol handlers are initially in a pending state (called "initial" state in the code). It is this code.
A few moments later, Substrate will process the event about the newly-established connection and decide, in accordance with the peerset, whether or not the notifications protocols handlers should be enabled or disabled. If enabled, we'll try to initiate gossiping upon this connection, if disabled we won't. It is this code.
In addition, the peerset tells the networking which nodes it should be connected to. If the peerset requests a node it's not yet connected to, the networking asks libp2p to connect to it.
The peerset can theoretically stop requesting a node from the networking at any moment, in which case the networking will close the gossiping and then the connection as a whole.
In order to give a bit of control over the peerset, it has these concepts of "priority group" and "reserved nodes", which are a list of nodes that the peerset will continuously request from the networking. At the moment, the authority-discovery module periodically sets a certain priority group to a list of 10 validators, meaning that the peerset will always ask the networking to be connected to these 10 validators and never ask to disconnect from them.

At the moment, there exists one global peerset for everything. In other words, if the peerset says yes to a connection then we gossip on it with all protocols, and if the peerset says no then we don't gossip on it.

This could be changed by having multiple peersets, one for each overlay network, but we could also bypass the concept of peerset.
The mechanism that permits giving a different purpose for each connection is there with the protocols handlers, but what is missing is the code that keeps track of what the overlay networks should be and informs the networking about which gossiping protocols a certain connection should use.

(disclaimer: at the moment enabling gossiping protocols is an all-or-nothing not only because of the single peerset but also because of backwards-compatibility reasons with the legacy substream, cc #5670)

Improve priority groups #6087

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions