-
Notifications
You must be signed in to change notification settings - Fork 89
Protocol timeouts #1813
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
Protocol timeouts #1813
Conversation
ouroboros-consensus/ouroboros-consensus-test-infra/src/Test/ThreadNet/Network.hs
Show resolved
Hide resolved
d429ebd
to
27a9ee4
Compare
27a9ee4
to
63b6755
Compare
388066e
to
51c77cd
Compare
51c77cd
to
87b14bb
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.
@karknu I realised some of my comments are about size limits, while this PR is only about timeouts. I didn't removed them, as we need to discuss these anyway, but we can ignore them to approve this PR.
where | ||
stateToLimit :: forall (pr :: PeerRole) (st :: BlockFetch block). | ||
PeerHasAgency pr st -> Word | ||
stateToLimit (ClientAgency TokIdle) = smallByteLimit |
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.
@karknu I think it would be good to document why all messages in the TokIdle
state are smaller than: smallByteLimits
. These are mostly trivial things , but it would be good to have it documented.
If we start using ToCBOR
or at least have encodedSizeExpr
for all the codecs we could add tests for these limits, let's create an issue for this. The limitation is that one cannot compute encodedSizeExpr
of things like block
or tx
, but it's possible to do that for headers.
PeerHasAgency pr st -> Word | ||
stateToLimit (ClientAgency TokIdle) = smallByteLimit | ||
stateToLimit (ServerAgency TokBusy) = smallByteLimit | ||
stateToLimit (ServerAgency TokStreaming) = largeByteLimit |
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.
We have a dependency between these limits and blockFetchProtocolLimits
; I was more conservative there: I estimated max message size to 2_097_154
bytes (which is 2MB block + cbor overhead); I think these two limits (mux ingress queue size limits & per protocol state limits) should agree.
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.
Strictly speaking they don't have to agree. The conjunction is enforced. But yes it's more consistent.
where | ||
stateToLimit :: forall (pr :: PeerRole) (st :: ChainSync header tip). | ||
PeerHasAgency pr st -> Word | ||
stateToLimit (ClientAgency TokIdle) = smallByteLimit |
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.
The same here; But we actually know the maximal header size. It's documented in NodeToNode
module, so we can give more adequate limits.
where | ||
stateToLimit :: forall (pr :: PeerRole) (st :: TxSubmission txid tx). | ||
PeerHasAgency pr st -> Word | ||
stateToLimit (ClientAgency (TokTxIds TokBlocking)) = largeByteLimit |
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.
Also here we can use estimations which were calculated for mux ingress queue + enhancing the haddocks.
@coot I will update the size limit ticket with references to your byteLimits comments to ensure that they aren't forgotten. |
@karknu thanks; then just please update the haddocs in this PR and I'll accept it. |
87b14bb
to
e3cab58
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; just a reminder to append to a comment.
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.
Looking very good.
A couple questions and comments below.
PeerHasAgency pr st -> Word | ||
stateToLimit (ClientAgency TokIdle) = smallByteLimit | ||
stateToLimit (ServerAgency TokBusy) = smallByteLimit | ||
stateToLimit (ServerAgency TokStreaming) = largeByteLimit |
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.
Strictly speaking they don't have to agree. The conjunction is enforced. But yes it's more consistent.
stateToLimit (ClientAgency (TokTxIds TokBlocking)) = largeByteLimit | ||
stateToLimit (ClientAgency (TokTxIds TokNonBlocking)) = largeByteLimit |
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 think these can be the small byte limit. The messages in this state are transaction ids, not transactions. With the 64k limit you could fit 2k tx ids. Our maximum outstanding window size is less than 2k. It's currently 100.
Also, this could be collapsed into one case with a wildcard on the blocking type.
6393b47
to
a3fb47d
Compare
bors r+ |
1813: Protocol timeouts r=karknu a=karknu Implements #1395, apart from the multi-chunk message timeout. Co-authored-by: Karl Knutsson <[email protected]>
bors r- |
Canceled |
a3fb47d
to
4d72207
Compare
Implement an optional timeout for reading Mux SDUs. This adds a 30s timeout when reading SDUs over a socketSnocket (IPv4/IPv6). There is no timeout for reading messages over localSnockets.
4d72207
to
e0445d0
Compare
bors r+ |
Implements #1395, apart from the multi-chunk message timeout.