Skip to content
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

randomize the serialization order of control frames #4069

Merged
merged 2 commits into from
Sep 11, 2023

Conversation

marten-seemann
Copy link
Member

We recently discovered a bug where the receiver relied on frames being sent in a particular order. This PR randomizes the order of what we call control frames (all frames other than ACK or STREAM frames) when packing the packet.

I'd like to randomize the order of the ACK as well (currently it's always serialized first). We could do this, but we wouldn't have a way to (q)log this without changing the tracer call, so this would be a bigger change:

SentShortHeaderPacket(hdr *ShortHeader, size ByteCount, ack *AckFrame, frames []Frame)

// Randomize the order of the control frames.
// This makes sure that the receiver doesn't rely on the order in which frames are packed.
if len(pl.frames) > 1 {
p.rand.Shuffle(len(pl.frames), func(i, j int) { pl.frames[i], pl.frames[j] = pl.frames[j], pl.frames[i] })
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using exp/rand here, since the Shuffle function doesn't allocate.

@@ -151,6 +159,7 @@ func newPacketPacker(
perspective: perspective,
framer: framer,
acks: acks,
rand: *rand.New(rand.NewSource(binary.BigEndian.Uint64(b[:]))),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using exp/rand here, since the rand.Source is small (16 bytes).

@codecov
Copy link

codecov bot commented Sep 6, 2023

Codecov Report

Merging #4069 (9eadca6) into master (591d864) will decrease coverage by 0.01%.
Report is 5 commits behind head on master.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #4069      +/-   ##
==========================================
- Coverage   83.48%   83.47%   -0.01%     
==========================================
  Files         147      147              
  Lines       14906    14934      +28     
==========================================
+ Hits        12443    12465      +22     
- Misses       1967     1971       +4     
- Partials      496      498       +2     
Files Changed Coverage Δ
packet_packer.go 83.50% <100.00%> (+0.16%) ⬆️

... and 4 files with indirect coverage changes

Copy link
Collaborator

@sukunrt sukunrt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks good. Just want to mention that we are now modifying payload.Frames. I can't see any case where this is an issue since it's not used anywhere after appendPacketPayload. So it looks fine to me.

@marten-seemann
Copy link
Member Author

Change looks good. Just want to mention that we are now modifying payload.Frames. I can't see any case where this is an issue since it's not used anywhere after appendPacketPayload. So it looks fine to me.

I agree that it won't be a problem, but to be explicit about it, I added a comment to that function.

@marten-seemann marten-seemann merged commit a7f8078 into master Sep 11, 2023
33 checks passed
@marten-seemann marten-seemann deleted the randomize-control-frame-order branch September 11, 2023 04:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants