TheLanc3/rustdesk
1
0
Fork 0
mirror of https://github.com/rustdesk/rustdesk.git synced 2026-09-07 21:11:05 +03:00
Code Issues Packages Projects Releases Wiki Activity

webrtc: trim the comments to AGENTS.md length; drop is_direct_transport

Browse Source 
386 added comment lines down to 287 across client, mediator, kcp_stream
and common. Same rule as hbb_common 3d64e43: out go past-bug narration,
rejected alternatives, measurements and restatements of the code; the
non-derivable why stays.

is_direct_transport goes with them. Judging the race by a transport
label was replaced by the resolved direct flag, leaving it used only by
its own test — and, having been inserted between the doc comment and
race_transports_prefer_webrtc, it had also taken that function's
contract with it. Removing it reattaches the doc where it belongs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ExUfAkYbq8UC9pQCiLy8TQ
This commit is contained in:
rustdesk
2026-08-09 22:38:43 +08:00
parent ccf9afd069
commit cbec70cd6a
4 changed files with 54 additions and 170 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
src/common.rs
View File

@@ -2454,23 +2454,11 @@ pub fn is_udp_disabled() -> bool {
pub const OPTION_ENABLE_KCP_CC: &str = "enable-kcp-congestion-control";
/// Whether to run KCP with its built-in congestion window (nc=0) instead of the pure turbo
/// profile (nc=1) it has always shipped with.
/// Run KCP with its congestion window (nc=0) instead of the turbo profile it has always shipped.
///
/// Opt-in, deliberately: switching it on is a transport-behavior change for every session, and
/// which profile wins depends on why packets are being lost.
///
/// - nc=1 never shrinks the send window. On a link that is genuinely congested it keeps pushing,
/// deepening the loss it is reacting to and crowding out other traffic on the same uplink.
/// - nc=0 adds KCP's congestion window, whose backoff is blunt: a fast retransmit halves it, but
/// an RTO sets `cwnd = 1` outright (ikcp.c) and the recovery slow-starts from one packet. On a
/// link with random loss but no congestion — Wi-Fi interference, a long-haul path — that reads
/// loss as congestion and can stall an interactive video stream for seconds.
///
/// Neither is safely decidable from reasoning, and a loopback benchmark cannot settle it: with
/// no bottleneck queue there is no congestion to control, so it would flatter nc=1 by
/// construction. Until there is evidence from a shaped link or the field, keep the profile users
/// already run and let anyone who wants the other one ask for it.
/// Opt-in: which profile wins depends on why packets are lost — nc=1 deepens real congestion,
/// while nc=0 reads random loss as congestion and its RTO backoff drops cwnd to 1. Undecidable
/// without a shaped link, so keep what users run today.
#[inline]
pub fn get_kcp_cc_enabled() -> bool {
Config::get_option(OPTION_ENABLE_KCP_CC) == "Y"