mirror of
https://github.com/rustdesk/hbb_common.git
synced 2026-08-27 04:37:35 +00:00
rustdesk
0a36139a58
`next()` read every non-FRAG_END header as "more fragments", so a peer whose framing had diverged was only caught by the MAX_FRAME_LENGTH cap — and a FRAG_MORE carrying no payload was never caught at all: it adds nothing to the accumulator, so the cap never trips and the loop spins for as long as the peer keeps writing, with no error and no teardown. Decide the header's meaning in one match, so a future header kind cannot be handled in one place and missed in the other. Neither case is reachable from send_bytes_inner, which emits FRAG_MORE only for a full MAX_FRAGMENT_PAYLOAD chunk. Release the accumulator on the error paths rather than truncating it: at the cap that is ~1 GiB still referenced through the SESSIONS clone. Doc corrections, all of them overclaims in the previous pass: - the cancel-safety entry held only for the successful read path. read_data_channel does await after dequeuing on its ErrShortBuffer and DCEP branches, and next() awaits pc.close() on its error paths — where RTCPeerConnection::close latches is_closed before its first await, so a cancelled close silently turns every later close into a no-op and leaves the pc in SESSIONS. - recv_state: cancellation drops the guard mid-message, so it is the single-reader assumption, not the mutex, that ultimately keeps two readers from splicing into one accumulator. - is_relayed: stream.rs promised None before pair selection while webrtc.rs documented Some(true) under Relay policy; align both. - get_local_endpoint: examples/webrtc.rs calls it too, not only the tests. - PunchHole.reserved 11: named the wrong writer — PunchHole is written by the rendezvous server, not by peers. Reserve the name as well as the tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>