-
Notifications
You must be signed in to change notification settings - Fork 545
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
Don't do full drain on chunks containing future buffered data #4215
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4215 +/- ##
==========================================
+ Coverage 84.22% 85.33% +1.11%
==========================================
Files 56 56
Lines 15358 15359 +1
==========================================
+ Hits 12935 13107 +172
+ Misses 2423 2252 -171 ☔ View full report in Codecov by Sentry. |
We still have some failures on the stress tests even with this fix, (dotnet/runtime#100064 (comment)), let's not merge just yet, I will see if there is more to be done in this PR. |
src/core/recv_buffer.c
Outdated
@@ -907,7 +907,12 @@ QuicRecvBufferDrain( | |||
} | |||
|
|||
do { | |||
if ((uint64_t)RecvBuffer->ReadLength > DrainLength) { | |||
if ((uint64_t)RecvBuffer->ReadLength > DrainLength || |
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.
This isn't quite the right fix. It should still call QuicRecvBufferFullDrain
to indicate it drained everything that was read, but QuicRecvBufferFullDrain
should be handling the fact that just because it read everything doesn't mean there isn't more after a gap to read.
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 am looking into what the right fix should be.
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 got more luck with this sort of change: rzikm@2beca9d
The gist of it is adjusting the ReadStart
for multi/circular mode buffers, and moving the rest of the data for "single" mode buffers (not done in referenced commit, I just wanted to have something quic to run in stress env)
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 talked over IM and maybe using the partial drain is the right way to go. We'd just kind of redefine 'partial drain' here to indicate it's not partial of the read length, but of all (possibly discontiguous) data in the buffer.
Description
This PR fixes bug where in certain situations, MsQuic would drop/corrupt data when received out of order + specific read timing from application side.
Testing
Failing test added to detect future regressions.
Documentation
N/A.