mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-09-19 19:01:05 +03:00
2c613b949f
A controlled peer that is killed, switched away by a user switch, or rebooted leaves no trace on a UDP transport: there is no reset to receive, so the session sees silence, and only the 30s inactivity timeout ends it. By then the remote machine may have finished rebooting and be reachable again, while the user has been watching a frozen frame the whole time and is then told the peer reset the connection. ICE already knows sooner. It reports Disconnected about 5s after it stops hearing from the peer, from its own task, so it stays accurate even while this loop is busy sending. That state is transient by design - a Wi-Fi roam or a sleep/wake recovers from it - so it is treated as suspicion, not as death: three more seconds with the transport receiving nothing, and the session reconnects. Receive progress cancels the suspicion, so a peer that is merely slow, or one ICE was late to clear, is not dropped. This only reaches the existing recovery sooner; it does not replace it. The first reconnect goes out immediately and, if it fails, falls into the same retry the UI already applies to any unexpected disconnect. The restart reconnect event is reused deliberately: it is what asks for exactly that, with no error dialog in front of it, and the UI shows "Connecting..." for it rather than anything about restarting. Its five-minute grace stays reserved for a restart the user actually asked for - silence is no evidence of a reboot. The 30s timeout is unchanged and still backs every transport. TCP and WebSocket are untouched. The controlled side is untouched: it detects a dead controller on the same 30s, which wastes some capture but nothing a user sees. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns