Fix force broadcast in herder #2650
Merged
Conversation
This file contains 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
it was preserving mPeersTold so "force" never worked...
In test cases we have situations where we bootstrap a new network, and lose sync within the first few ledgers (before MAX_SLOTS_TO_REMEMBER=12 ledgers). When this happens, we want to ensure that we continue to process SCP messages, regardless of their timestamp. The old code was approximating "never been in sync" by just looking at the ledger window, which is inacurate.
rokopt
approved these changes
Aug 4, 2020
|
r+ 4526d39 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 fixes a couple issues.
First is a major issue with how SCP messages are broadcasted: broadcast has a
forceflag to force sending the latest SCP message to peers, but from what I can tell, that flag never worked.HerderImpl::rebroadcast()was actually not doing anything, which in turn may cause various issues like peers potentially missing SCP messages or connections getting idle (if SCP rounds take too long, an issue mostly in test cases as real networks have transactions flowing)The second issue is minor, in that it doesn't really impact production/testnet and only test cases:
In test cases we have situations where we bootstrap a new network, and lose sync within the first few ledgers (before MAX_SLOTS_TO_REMEMBER=12 ledgers).
When this happens, we want to ensure that we continue to process SCP messages, regardless of their timestamp.
The old code was approximating "never been in sync" by just looking at the ledger window, which is inaccurate.