pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-13 22:11:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

guide: collator networking & subsystems (#1452)

Browse Source 
* Do a small write-up on collation-generation

* preamble to collator protocol

* notes on protocol

* collation-generation: point to collator protocol

* fix missing bracket

* expand on collator protocol wire protocol

* add a couple more sentences

* expand on requests some more

* go higher level

* network bridge: note peerset

* note peer-set = validation for protocols

* add `ConnectToValidators` message

* use ConnectToValidators in collator protocol

* typo

* remove references to sentry nodes
This commit is contained in:
Robert Habermeier
2020-07-31 11:07:31 -04:00
committed by GitHub
parent ea834b12de
commit 490f80d8c7
11 changed files with 228 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/utility/network-bridge.md
+16 -2
View File
@@ -8,19 +8,24 @@ One other piece of shared state to track is peer reputation. When peers are foun
So in short, this Subsystem acts as a bridge between an actual network component and a subsystem's protocol.
The other component of the network bridge is which peer-set to use. Different peer-sets can be connected for different purposes. The network bridge is not generic over peer-set, but instead exposes two peer-sets that event producers can attach to: `Validation` and `Collation`. More information can be found on the documentation of the [`NetworkBridgeMessage`][NBM].
## Protocol
Input: [`NetworkBridgeMessage`](../../types/overseer-protocol.md#network-bridge-message)
Input: [`NetworkBridgeMessage`][NBM]
Output: Varying, based on registered event producers.
## Functionality
Track a set of all Event Producers, each associated with a 4-byte protocol ID.
Track a set of all Event Producers, each associated with a 4-byte protocol ID and the `PeerSet` it is associated on.
There are two types of network messages this sends and receives:
- ProtocolMessage(ProtocolId, Bytes)
- ViewUpdate(View)
Each of these network messages is associated with a particular peer-set. If we are connected to the same peer on both peer-sets, we will receive two `ViewUpdate`s from them every time they change their view.
`ActiveLeavesUpdate`'s `activated` and `deactivated` lists determine the evolution of our local view over time. A `ViewUpdate` is issued to each connected peer after each update, and a `NetworkBridgeUpdate::OurViewChange` is issued for each registered event producer.
On `RegisterEventProducer`:
@@ -44,3 +49,12 @@ On `ReportPeer` message:
On `SendMessage` message:
- Issue a corresponding `ProtocolMessage` to each listed peer with given protocol ID and bytes.
[NBM]: ../../types/overseer-protocol.md#network-bridge-message
On `ConnectToValidators` message:
- Determine the DHT keys to use for each validator based on the relay-chain state and Runtime API.
- Recover the Peer IDs of the validators from the DHT. There may be more than one peer ID per validator.
- Accumulate all `(ValidatorId, PeerId)` pairs and send on the response channel.
- Feed all Peer IDs to the discovery utility the underlying network provides.