mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-09-07 21:11:05 +03:00
98c0401134
The same link that streams over KCP crawls over WebRTC. webrtc-sctp runs RFC 4960's AIMD: a fast retransmit halves cwnd, a T3 drops it to one MTU, and slow start only rebuilds it while data is queued behind it. Where the loss is random rather than congestion - a lossy long-haul link - the rate settles at the Mathis ceiling MSS/(RTT*sqrt(p)) however idle the link is: about 1.3 Mbps at 70ms RTT and 1% loss, 0.6 Mbps at 5%, while 1080p wants 2-5 Mbps. KCP's turbo profile (nc=1) has no congestion window at all. The fork now carries a switch that bypasses the two places gating sends on cwnd, and hbb_common turns it on for every peer connection unless `allow-webrtc-congestion-control` is set - the same opt-in KCP has in `allow-kcp-congestion-control`, for the reason at `get_kcp_cc_enabled`. Sender-side only; a browser or an older build on the other end interoperates. Measured over a simulated link (35ms one-way, random loss both ways, 12 KB frames at 30fps, 300 frames): at 1% loss the window stretches 9.9s of video to 20.7s with a mean latency of 5.5s; without it the stream stays realtime at a mean of 113ms. At 3%: 47s and 15s against 10.2s and 290ms. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns