mirror of
https://github.com/rustdesk/hbb_common.git
synced 2026-08-27 04:37:35 +00:00
rustdesk
ddea60cd3d
A message that arrives in one fragment was read into a scratch buffer and then copied into a second, freshly allocated one - an allocation and a full copy per message, on top of SCTP's own reassembly copy, for every input event and most audio packets. The read buffer is a BytesMut now, so such a message is split straight out of it: the caller gets a slice sharing the allocation, with no copy and no allocation. Splitting consumes the buffer from the front, so it is re-initialized in chunks rather than per read, which spreads the one remaining cost (zeroing) across every small message that fits in a chunk. Slices keep their chunk alive, so this trades a bounded amount of retention for the copy. Multi-fragment messages still accumulate, unchanged - there is nothing to hand out until the last fragment arrives. Test alternates whole and fragmented messages either side of the fragment boundary for long enough to cross several refills, which is where the consumed-buffer scheme differs from the fixed one; an off-by-one in the split reddens it. The send side keeps its per-fragment copy: prepending the header byte is what forces it, and removing that needs the fragment flag to move into the SCTP PPID - another wire change, so it is deliberately left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ExUfAkYbq8UC9pQCiLy8TQ