Enforce the TCP receive window to bound per-session memory - #90
Open
IntellyCode wants to merge 2 commits into
Open
Enforce the TCP receive window to bound per-session memory#90IntellyCode wants to merge 2 commits into
IntellyCode wants to merge 2 commits into
Conversation
The receive window ipstack advertises now holds. A segment beyond it is dropped for the peer to resend, the head-of-line segment always admitted so the stream advances. The handoff channel to the reader is bounded and filled by reserving a slot before consuming, so buffered data leaves the reassembly map only once it has a home; a reader that frees space wakes the loop to flush more and the follow-up ACK carries the reopened window. The window is advertised as zero below one segment, so a stalled reader puts the peer into persist mode until space frees. Consuming trims a stale head entry a re-segmented retransmission left below the ack, and a FIN is accepted only once the data before it has been consumed, so a full channel never strands the tail.
The stream's first tokio test drives extract_data_n_write_upstream against a full handoff channel: buffered data stays in the reassembly map and the ack holds until the reader drains a slot, then the tail flushes and the ack advances.
IntellyCode
force-pushed
the
enforce-recv-window
branch
2 times, most recently
from
August 25, 2026 17:01
323baf0 to
d0785d6
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
ipstack advertises a receive window but never enforces it: the reassembly buffer and the
data_txhandoff channel are both unbounded, so a peer that outpaces the reader (or holds a reassembly gap open) grows a session's memory without limit — an OOM risk on memory-constrained hosts.This makes the window real:
add_unordered_packetdrops out-of-order segments once the reassembly buffer reachesread_buffer_size(head-of-line always admitted).data_tx/data_rxare bounded;extract_data_n_write_upstreamreserves a slot before consuming, so a stalled reader shrinks the advertised window and backpressures the peer.poll_readsignals aNotifyto re-drive the flush when space frees.ackreaches its sequence, so a full channel can't strand the tail.consume_unordered_packetstrims a segment a retransmission left straddlingackinstead of wedging.Covered by unit tests and an async test; validated live against a real TCP connection (reader stalled → server throughput drops to zero, recovers on resume, clean close). If you'd prefer an in-repo integration test, I can add ~200 lines to
tests/that build a packet-framed in-memory device and assert the window closes under a stalled reader and reopens on drain.