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

Outgoing ACK improvements #1415

Merged
merged 2 commits into from Sep 26, 2022
Merged

Outgoing ACK improvements #1415

merged 2 commits into from Sep 26, 2022

Conversation

Ralith
Copy link
Collaborator

@Ralith Ralith commented Sep 24, 2022

Fixes #1413.

Application datagrams may be too large to fit into a packet with ACKs
present. Therefore, if we have unsent ACKs, doing so may push a queued
application datagram into the next packet. If no other data is queued,
the first packet will then be ACK-only. Sending an ACK-only packet
without having received an ACK-eliciting packet following our last
ACK-only packet is illegal, and will trigger a debug assert.

By being slightly less enthusiastic about sending ACKs, we ensure that
any inadvertently generated ACK-only packet is legal and simplify our
logic slightly. This approach also seems to be popular with other
implementations, as indicated by ad-hoc feedback on the slack.
As recommended in RFC 9000 §13.2.4. Simplifies sent packet state and
acknowledgement processing.
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.

Assertion failure when sending a lot of datagrams
2 participants