You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation shares contiguous bytes with an AsyncRead consumer through a channel. However, this approach prevents backpressure, which leads to significant memory consumption if the sending rate is too fast. Furthermore, because the buffered data is immediately sent to the channel, the TCP receive window does not shrink. This disables TCP-level flow control, further exacerbating memory accumulation.
The solution I've come up with is to create an ordered list of packets within the TCB. The consumption method, each time it's called, will move the contiguous packets into this list.
The window calculation will also be modified to determine the actual window size by accounting for the sizes of both the in-order (ordered) and out-of-order packets.
Then, in the AsyncRead implementation, it will get the TCB, pop the first packet from the ordered collection, and write it into the read buffer.
Here, every time a new data packet is received, it is sent through the channel, which frees up the receive window. However, the data in the channel might not be consumed in time by the upstream TCP Stream, causing it to accumulate here.
Activity
SajjadPourali commentedon Oct 15, 2025
Do you mean this part?
ipstack/src/stream/tcb.rs
Lines 54 to 55 in 92e5a87
Orvaxis commentedon Oct 19, 2025
Here, every time a new data packet is received, it is sent through the channel, which frees up the receive window. However, the data in the channel might not be consumed in time by the upstream TCP Stream, causing it to accumulate here.
ipstack/src/stream/tcp.rs
Lines 846 to 853 in 92e5a87
Recently, I discovered a similar issue here, which causes traffic to accumulate in bursts during high-throughput uploads.
ipstack/src/lib.rs
Lines 13 to 15 in 92e5a87
ipstack/src/lib.rs
Lines 177 to 181 in 92e5a87