-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
@@ -355,7 +355,8 @@ impl<B: BlockT> BlockRequestHandler<B> { | |||
indexed_body, | |||
}; | |||
|
|||
total_size += block_data.body.len(); | |||
total_size += block_data.body.iter().map(|ex| ex.len()).sum::<usize>(); | |||
total_size += block_data.indexed_body.iter().map(|ex| ex.len()).sum::<usize>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might this work well as a size() function on block_data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BlockData
struct is auto generated from protobuf description. Also, we don't need all of the field to be sized here, just the bodies. The rest do not vary much and should definitely fit in the margin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a test would be nice
@@ -62,7 +62,7 @@ pub fn generate_protocol_config(protocol_id: &ProtocolId) -> ProtocolConfig { | |||
name: generate_protocol_name(protocol_id).into(), | |||
max_request_size: 1024 * 1024, | |||
max_response_size: 16 * 1024 * 1024, | |||
request_timeout: Duration::from_secs(40), | |||
request_timeout: Duration::from_secs(20), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you change the timeout?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit off-topic for this PR, but this timeout is too high anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right it was too high in the first place, and since I've also decreased the number of requested blocks the timeout should be readjusted.
Added a test and fixed response start block detection. Rather than trusting that it matches the request it should be detected from the response. |
@arkpar did you missed to push the test changes? |
bot merge |
Trying merge. |
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
Co-authored-by: Arkadiy Paronyan <arkady.paronyan@gmail.com>
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
* Fixed block response limit check * Fixed start block detection and added a test * Missing test
When computing block response size, the code was incorrectly counting extrinsics rather than bytes.
Also decreased
MAX_BLOCKS_TO_REQUEST
so that the nodes can sync without waiting for others to upgrade and tweaked timeout value.Fixes paritytech/polkadot#3778