-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2.0: excludes node's pubkey from bloom filter of pruned origins (backport of #2990) #3015
Conversation
Bloom filter of pruned origins can return false positive for a node's own pubkey but a node should always be able to push its own values to other nodes in the cluster. (cherry picked from commit bce28c0)
2e993c5
to
1380fdd
Compare
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.
lgtm!
Is the potential problem here that a node won't push its own values because of a false positive in the bloom filter indicating we pruned this pubkey? And thus, the cluster will have stale values for this node unless they explicitly pull the values? |
Ya when a node gets a CrdsValue, it will check in its push active set which peers it can send this value to. Each peer in the push active set has a bloom filter associated with it. If the origin of the CrdsValue appears in the bloom filter of the peer, the node will not send the CrdsValue to that peer (that peer has pruned the node for messages originating from the CrdsValue's origin). So yes, there is a chance that when a node has a CrdsValue it created, the node's own pubkey shows up in the bloom filter for one or more of its peers in the push active set. As a result, the node would not push its own value it created out into the network. And yes peers would have to explicitly pull these values from the origin node. That's assuming there were only false positives in the push active set. |
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.
Couple minor suggestions, but I'm okay pushing it
// If true forces gossip push even if the node has pruned the origin. | ||
mut should_force_push: impl FnMut(&Pubkey) -> bool + 'a, | ||
) -> impl Iterator<Item = &Pubkey> + 'a { | ||
let pubkey_eq_origin = pubkey == origin; |
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.
I like the idea of naming this something like pushing_my_own_value
Problem
Bloom filter of pruned origins can return false positive for a node's own pubkey but a node should always be able to push its own values to other nodes in the cluster.
Summary of Changes
Excludes node's pubkey from bloom filter of pruned origins
This is an automatic backport of pull request #2990 done by Mergify.