eth/protocols, prp/tracker: add support for req/rep rtt tracking #22608
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.
This PR is a counterpart to #22581, adding metrics to the request/reply RTTs too.
Given that we (currently) do not have a centralized dispatcher which matches requests with replies, this PR introduces a global request tracker (per protocol). The tracker can be notified of outbound requests and inbound replies, and it will match them up and update the relevant metrics.
Since the request/reply pattern is stateful, there are a few caveats in the tracker:
downloader
might use, rather a global number per protocol (5 min foreth
, 1 min forsnap
). This allows us to a) detect loooong deliveries even if the calling code timed out and discarded the request; b) track expiries with a doubly linked list, making deletions and expiry O(1).Open questions:
eth
(backend) and propagating it to all relevant call sites would become quite nasty; and our metrics can't differentiate between 2node
instances running within the same process either way. May or may not be a goo idea, wanted to emphasize it.TL;DR