P2P [BlockRelayInvsFlow]: Track and suppress unrequired BlockInv message broadcasting. #869
Open
D-Stacks wants to merge 4 commits intokaspanet:masterfrom
Open
P2P [BlockRelayInvsFlow]: Track and suppress unrequired BlockInv message broadcasting. #869D-Stacks wants to merge 4 commits intokaspanet:masterfrom
D-Stacks wants to merge 4 commits intokaspanet:masterfrom
Conversation
… track_and_filter_blockinv_messages-
D-Stacks
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 builds on #810 by adding tracking and suppression of duplicate BlockInv relays, both in respect to their processing, and in regards to the broadcasting of invs to peers that have announced them to us, while we were processing a corresponding inv.
The flow context now keeps a struct that tracks and maps hashes currently being processed by the node to the peers that announced them; we use that to skip redundant processing, and after a block, from a BlockInv, is processed, we can use this to filter out peers from the resulting broadcast, which have in the meantime announced the block to us.
Currently de-duplication of processing happens at the request-scope stage, which still costs about 200–600 µs per inv — time that could be spent awaiting for the next inv from the router. It also offers no way to suppress broadcasts to the peer-set which has, in the meantime, announced the block to us.
This change addresses both issues and (from my local measurements) reduces BlockInv relay traffic by ~30%, significantly cutting down the spam in regards to this message, and allows for general healthier dequeuing of relevant BlockInv relay messages, that are more likely to advance the node's state.