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
feat: add streamReadChunk to StreamIO for bulk-read throughput
Every consumer of StreamIO read one byte at a time, which bounded the
perf test app's download direction at under 5 Mbps (issue #276) while
uploads ran at 0.49-0.80 Gbps. Add a chunk-level read to StreamIO:
streamReadChunk :: Int -> IO ByteString
returning between 1 and n bytes (whatever is buffered or arrives next),
with EOF surfacing as an IOException exactly like streamReadByte. The
max-length argument (not in the issue's sketch) is what lets
readExactBounded use it safely: with no push-back mechanism, an
unbounded chunk read would consume bytes past a message boundary.
Implemented in the yamux adapter and Noise session wrapper (hand back
the buffered chunk / decrypted frame), the TCP socket (recv n), the
in-memory test pairs, and a mkByteStreamIO helper that derives a
one-byte-per-call chunk read for byte-queue test mocks.
readExactBounded now reads chunks, which moves the whole receive path
off byte-at-a-time reads: Noise frame reads from the raw socket, the
yamux read callback, and every length-delimited protocol reader. The
relay's forwardWithLimit also forwards at chunk granularity, still
never consuming a byte beyond the circuit's limit.
Two DCUtR upgrade tests asserted that no direct connection exists 500ms
after the circuit dial; the faster relayed path now lets the automatic
DCUtR upgrade pool a direct connection inside that window (on loopback
the handler-side dial is an ordinary client dial and succeeds). Those
tests now run with the automatic upgrade disabled via zero-length
timeout windows, making their pool preconditions deterministic.
0 commit comments