Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix #23
This PR adds support for timing games, ie. allows a node operator to fine tune how to send
get_header
requests to relays. This is configured via two new per-relay parameters:target_first_request_ms
: which sets how late in the slot to send the first header requestfrequency_get_header_ms
: which sets how frequently to send header requests after the firstand a global param:
late_in_slot_time_ms
: which sets how late in the slot is "late", acting as a hard upper bound for when to return headers to the CLThe requests are still bound by
timeout_get_header_ms
which is ~what the fullget_header
request can take at most from the CL perspective (plus some small overhead from the module itself).The logic is as follows:
target_first_request_ms
, wait until the target timefrequency_get_header_ms
with decreasing timeoutsExamples
Assuming:
timeout_get_header_ms = 950
,frequency_get_header_ms = 300
,target_first_request_ms = 200
,late_in_slot_time_ms = 2000