mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-04-27 03:27:58 +00:00
network: Use "one shot" protocol handler. (#3520)
* network: Use "one shot" protocol handler. Add two new `NetworkBehaviour`s, one handling remote block requests and another one to handle light client requests (both local and from remote). The change is motivated by the desire to use multiple substreams of a single connection for different protocols. To achieve this, libp2p's `OneShotHandler` is used as a protocol handler in each behaviour. It will open a fresh substream for the duration of the request and close it afterwards. For block requests, we currently only handle incoming requests from remote and tests are missing. For light client handling we support incoming requests from remote and also ported a substantial amount of functionality over from `light_dispatch.rs` (including several tests). However the result lacks in at least two aspects: (1) We require external updates w.r.t. the best block per peer and currently nothing updates this information. (2) We carry a lot of peer-related state around. Both aspects could be simplified by externalising peer selection and just requiring a specific peer ID where the request should be sent to. We still have to maintain some peer related state due to the way libp2p's swarm and network behaviour work (e.g. we must make sure to always issue `NetworkBehaviourAction::SendEvent`s to peers we are connected to, otherwise the actions die a silent death. Another change implemented here is the use of protocol buffers as the encoding for network messages. Certain individual fields of messages are still SCALE encoded. There has been some discussion about this in another PR (https://github.com/paritytech/substrate/pull/3452), so far without resolution. * Uncomment `Behaviour::light_client_request`. * Add license headers.
This commit is contained in:
@@ -0,0 +1,59 @@
|
||||
// Schema definition for block request/response messages.
|
||||
|
||||
syntax = "proto3";
|
||||
|
||||
package api.v1;
|
||||
|
||||
// Block enumeration direction.
|
||||
enum Direction {
|
||||
// Enumerate in ascending order (from child to parent).
|
||||
Ascending = 0;
|
||||
// Enumerate in descendfing order (from parent to canonical child).
|
||||
Descending = 1;
|
||||
}
|
||||
|
||||
// Request block data from a peer.
|
||||
message BlockRequest {
|
||||
// Unique request id.
|
||||
uint64 id = 1;
|
||||
// Bits of block data to request.
|
||||
uint32 fields = 2;
|
||||
// Start from this block.
|
||||
oneof from_block {
|
||||
// Start with given hash.
|
||||
bytes hash = 3;
|
||||
// Start with given block number.
|
||||
bytes number = 4;
|
||||
}
|
||||
// End at this block. An implementation defined maximum is used when unspecified.
|
||||
bytes to_block = 5; // optional
|
||||
// Sequence direction.
|
||||
Direction direction = 6;
|
||||
// Maximum number of blocks to return. An implementation defined maximum is used when unspecified.
|
||||
uint32 max_blocks = 7; // optional
|
||||
}
|
||||
|
||||
// Response to `BlockRequest`
|
||||
message BlockResponse {
|
||||
// Id of a request this response was made for.
|
||||
uint64 id = 1;
|
||||
// Block data for the requested sequence.
|
||||
repeated BlockData blocks = 2;
|
||||
}
|
||||
|
||||
// Block data sent in the response.
|
||||
message BlockData {
|
||||
// Block header hash.
|
||||
bytes hash = 1;
|
||||
// Block header if requested.
|
||||
bytes header = 2; // optional
|
||||
// Block body if requested.
|
||||
repeated bytes body = 3; // optional
|
||||
// Block receipt if requested.
|
||||
bytes receipt = 4; // optional
|
||||
// Block message queue if requested.
|
||||
bytes message_queue = 5; // optional
|
||||
// Justification if requested.
|
||||
bytes justification = 6; // optional
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user