ChainSync client test: model pipelining behavior #3742
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
nfrisby
requested changes
May 17, 2022
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Show resolved
Hide resolved
nfrisby
approved these changes
May 18, 2022
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Outdated
Show resolved
Hide resolved
ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/ChainSync/Client.hs
Show resolved
Hide resolved
amesgen
force-pushed
the
amesgen/CAD-4192-pipelining-test-ChainSync-client
branch
from
92d86eb
to
5d06588
Compare
In the context of diffusion pipelining, it is possible honest behavior for an upstream peer to send us a block we already know is invalid. In this case, we should not promptly disconnect them in ChainSync, as was the case pre-pipelining. This commit models the "learning process" of our local node that certain blocks are invalid by scheduling them in random order in the timeframe of scheduled ticks.
amesgen
force-pushed
the
amesgen/CAD-4192-pipelining-test-ChainSync-client
branch
from
5d06588
to
50d8047
Compare
|
bors merge |
iohk-bors bot
added a commit
that referenced
this pull request
May 18, 2022
3742: ChainSync client test: model pipelining behavior r=amesgen a=amesgen Closes [CAD-4192](https://input-output.atlassian.net/browse/CAD-4192) Co-authored-by: Alexander Esgen <[email protected]>
|
Timed out. |
|
bors retry |
iohk-bors bot
added a commit
that referenced
this pull request
May 18, 2022
3734: ChainSync server: prevent duplicate `RollForward` messages r=amesgen a=amesgen Closes [CAD-4228](https://input-output.atlassian.net/browse/CAD-4228). #### Problem description Consider the following very common scenario prior to this PR: 1. Assume that the node is idle, having selected a chain with tip A 2. It receives a new block B that extends A 3. We set the tentative header to B 3. This wakes up the ChainSync server thread (in an `STM` transaction in `instructionHelper`) - The roll state is updated from `RollForwardFrom A` to `RollForwardFrom B`. - The chain update `AddBlock B` is emitted. 4. After successful validation, the node selects B which involves a call to `fhSwitchFork` with intersection point A. - Because the intersection point is now behind the roll state point, the roll state is set to `RollBackTo A`. - Hence, the follower emits/the ChainSync server sends a `RollBack A`, immediately followed by another `AddBlock B`. These extra messages are redundant, and will be no longer sent with this PR. #### Diagnosis The arguments to `fhSwitchFork` are unaware of the tentative header, so for a *tentative* follower it looks like a rollback is necessary. Before pipelining, the call to `fhSwitchFork` was a no-op when rolling forward by a block because the passed intersection point did not precede (in fact, was equal to) the roll state point. #### Possible solutions (note that these are not mutually exclusive) 1. Make the call to `fhSwitchFork` with arguments aware of the tentative header. 2. Don't call `fhSwitchFork` when selecting our tentative header. 3. Don't call `fhSwitchFork` when extending our chain. We went with the third, as it stresses that `fhSwitchFork` is only necessary when actually switching to a fork, and it is most straightforward to implement. 3742: ChainSync client test: model pipelining behavior r=amesgen a=amesgen Closes [CAD-4192](https://input-output.atlassian.net/browse/CAD-4192) Co-authored-by: Alexander Esgen <[email protected]>
|
Build failed (retrying...): |
iohk-bors
bot
deleted the
amesgen/CAD-4192-pipelining-test-ChainSync-client
branch
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.
Closes CAD-4192