mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-09-29 16:56:25 +00:00
RustDeskandClaude Opus 5
f164c9a9df
* webrtc: recover from a silent peer in about 8s instead of 30s 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 * kcp: recover from a silent peer on the endpoint's own clock KCP is the other transport with nothing to receive when the peer dies, and it was the slower of the two: its endpoint reaps a connection only after 60s without a packet, which is past the 30s inactivity timeout above it, so in practice nothing but that timeout ever noticed. The endpoint already tracks when each connection last heard from its peer and now exposes it, so this reads that rather than anything derived from the session loop - it keeps answering while that loop is busy sending. Its liveness ping now goes out about every 2s rather than every 10s, so silence means the peer rather than an idle link, and eight seconds of it is several missed pings. Same threshold and the same recovery as the WebRTC half, so a user sees the same thing on either transport. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: time the inactivity window off receive progress, bound the parting send Two things the review found, both on the controlling side. The 30s inactivity window still ran off completed messages alone, so the probe added for the fast path did not fix what it was added for: a message larger than the transport's fragment size yields nothing until its last fragment, and a peer sending one steadily was still timed out mid-transfer. It is now timed off whichever is later, a completed message or receive progress. Transports that report no progress leave that at its starting value, so nothing else moves. The parting close-reason send for KCP waited on send capacity with no deadline of its own, and a queue a dead peer will never drain held the finished session's thread until the endpoint reaped the connection a minute later. Bounded once the peer has been declared gone. Still attempted rather than skipped: if the loss was one-way the peer does receive it, and drops its side immediately instead of waiting out its own timeout - which is also the one case where the note below resolves itself. Recorded from the same review, for the case none of this targets - a peer that is alive behind a path that broke for five to ten seconds and then healed. Giving up cannot deliver a close there, because the path is still down at that moment, so the controlled side keeps the old connection until its own 30s expires. For up to twenty of those seconds it holds two authorised connections: its connection manager lists both, and the stale one reports a growing delay that pins the shared frame rate low for the new one. Input is unaffected throughout and both recover once the stale connection goes, so this trades twenty-two seconds of a frozen, uncontrollable session for a controllable one that looks wrong for a while. Closing the displaced connection is controlled-side work and belongs with the rest of it, not here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: reject a disconnected cached session, tidy the detector hbb_common: `is_reusable_for` now also rejects a session ICE reports Disconnected, so a caller is not handed one that already carries the hint; and the receive-progress test no longer races `next()` against a sleeping sibling. Here: the `is_some()` guard on the progress comparison was dead, since a transport answers `None` for its whole life and `None != None` is already false. The parting-send deadline is a `Duration` like every other constant around it rather than bare milliseconds. And the comments are cut back to what is not already evident from the code they sit on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: keep the legacy UI's retrying error when the peer goes silent `restarting-show` is a Flutter control event; Sciter has no case for it and falls through to a plain dialog, which `check_if_retry` marks non-retryable because its type is not `error`. So on that build the new detector would have replaced a timeout that reconnects on its own after 30s with a dialog waiting for a click at 8s - a regression for the one path this was meant to shorten. Send it the message the timeout already sends, so its behaviour is unchanged apart from arriving sooner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: keep the 30s watchdog hard, and let Android's picker hold the reconnect Timing the watchdog off receive progress gave away its upper bound. A fragment bumps the counter as it arrives, ahead of the framing checks that would reject it, so a peer sending one `FRAG_MORE` every twenty seconds and never a `FRAG_END` refreshed the deadline forever while the reassembly buffer grew toward `MAX_FRAME_LENGTH`, a gigabyte away. What it bought - a clipboard image that takes longer than thirty seconds to arrive is not a dead peer - is a pre-existing problem that predates this branch and can be fixed on its own. Receive progress goes back to the one job it was added for, which needs no deadline of its own: telling a transport that has gone quiet from one that is still delivering, so ICE's disconnected hint is not acted on mid-transfer. The Android document picker suppresses a `Connection Error` while it is open and remembers to reconnect once it closes. The peer-gone break reconnects under `restarting-show` with a `Connecting...` title, which matched neither half of that test, so an eight-second stall behind an open picker - Doze and background throttling produce them - threw a dialog up behind the picker and lost the deferred reconnect. It is now named there by its own title rather than by its type: an explicitly restarted remote device sends the same type from a path this leaves alone, on every transport, and deferring that one too would be a change to sessions this has no business touching. The two limits are still not hard upper bounds, and the comment saying so was wrong about why. A send is awaited inline in this loop, so one in progress delays the tick that checks them - bounded on WebRTC by the timeout the stream was built with, not bounded at all on KCP, whose framed stream is constructed with none. The 30s watchdog beside it shares the loop and the same delay. Left alone deliberately. `restarting-show` reconnects without the backoff its `restarting` sibling uses, which can loop while each round gets far enough to establish a session and then loses the transport within eight seconds; a cooldown there would also delay the recovery this exists for when a peer really does come back, and the loading it shows can be cancelled. And the KCP limit reads an accumulated silence rather than a transient hint, so unlike the WebRTC grace it needs no second sample to confirm - one would only move eight seconds to nine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Build •
Docker •
Structure •
Screenshots
[Українська] | [česky] | [中文] | [Magyar] | [Español] | [فارسی] | [Français] | [Deutsch] | [Polski] | [Indonesian] | [Suomi] | [മലയാളം] | [日本語] | [Nederlands] | [Italiano] | [Русский] | [Português (Brasil)] | [Esperanto] | [한국어] | [العربي] | [Tiếng Việt] | [Dansk] | [Ελληνικά] | [Türkçe] | [Norsk] | [Română]
We need your help to translate this README, RustDesk UI and RustDesk Doc to your native language
Caution
Misuse Disclaimer:
The developers of RustDesk do not condone or support any unethical or illegal use of this software. Misuse, such as unauthorized access, control or invasion of privacy, is strictly against our guidelines. The authors are not responsible for any misuse of the application.
Chat with us: Discord | Twitter | Reddit | YouTube
Yet another remote desktop solution, written in Rust. Works out of the box with no configuration required. You have full control of your data, with no concerns about security. You can use our rendezvous/relay server, set up your own, or write your own rendezvous/relay server.
RustDesk welcomes contribution from everyone. See CONTRIBUTING.md for help getting started.
Dependencies
Desktop versions use Flutter or Sciter (deprecated) for GUI. This tutorial is for Sciter only, since it is easier and more friendly to start. Check out our CI for building the Flutter version.
Please download Sciter dynamic library yourself.
Raw Steps to build
-
Prepare your Rust development env and C++ build env
-
Install vcpkg, and set
VCPKG_ROOTenv variable correctly- Windows: vcpkg install libvpx:x64-windows-static libyuv:x64-windows-static opus:x64-windows-static aom:x64-windows-static
- Linux/macOS: vcpkg install libvpx libyuv opus aom
-
run
cargo run
Build
How to Build on Linux
Ubuntu 18 (Debian 10)
sudo apt install -y zip g++ gcc git curl wget nasm yasm libgtk-3-dev clang libxcb-randr0-dev libxdo-dev \
libxfixes-dev libxcb-shape0-dev libxcb-xfixes0-dev libasound2-dev libpulse-dev cmake make \
libclang-dev ninja-build libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
openSUSE Tumbleweed
sudo zypper install gcc-c++ git curl wget nasm yasm gcc gtk3-devel clang libxcb-devel libXfixes-devel cmake alsa-lib-devel gstreamer-devel gstreamer-plugins-base-devel xdotool-devel
Fedora 28 (CentOS 8)
sudo yum -y install gcc-c++ git curl wget nasm yasm gcc gtk3-devel clang libxcb-devel libxdo-devel libXfixes-devel pulseaudio-libs-devel cmake alsa-lib-devel gstreamer1-devel gstreamer1-plugins-base-devel
Arch (Manjaro)
sudo pacman -Syu --needed unzip git cmake gcc curl wget yasm nasm zip make pkg-config clang gtk3 xdotool libxcb libxfixes alsa-lib pipewire
Install vcpkg
git clone https://github.com/microsoft/vcpkg
cd vcpkg
git checkout 2023.04.15
cd ..
vcpkg/bootstrap-vcpkg.sh
export VCPKG_ROOT=$HOME/vcpkg
vcpkg/vcpkg install libvpx libyuv opus aom
Fix libvpx (For Fedora)
cd vcpkg/buildtrees/libvpx/src
cd *
./configure
sed -i 's/CFLAGS+=-I/CFLAGS+=-fPIC -I/g' Makefile
sed -i 's/CXXFLAGS+=-I/CXXFLAGS+=-fPIC -I/g' Makefile
make
cp libvpx.a $HOME/vcpkg/installed/x64-linux/lib/
cd
Build
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
git clone --recurse-submodules https://github.com/rustdesk/rustdesk
cd rustdesk
mkdir -p target/debug
wget https://raw.githubusercontent.com/c-smile/sciter-sdk/master/bin.lnx/x64/libsciter-gtk.so
mv libsciter-gtk.so target/debug
VCPKG_ROOT=$HOME/vcpkg cargo run
How to build with Docker
Begin by cloning the repository and building the Docker container:
git clone https://github.com/rustdesk/rustdesk
cd rustdesk
git submodule update --init --recursive
docker build -t "rustdesk-builder" .
Then, each time you need to build the application, run the following command:
docker run --rm -it -v $PWD:/home/user/rustdesk -v rustdesk-git-cache:/home/user/.cargo/git -v rustdesk-registry-cache:/home/user/.cargo/registry -e PUID="$(id -u)" -e PGID="$(id -g)" rustdesk-builder
Note that the first build may take longer before dependencies are cached, subsequent builds will be faster. Additionally, if you need to specify different arguments to the build command, you may do so at the end of the command in the <OPTIONAL-ARGS> position. For instance, if you wanted to build an optimized release version, you would run the command above followed by --release. The resulting executable will be available in the target folder on your system, and can be run with:
target/debug/rustdesk
Or, if you're running a release executable:
target/release/rustdesk
Please ensure that you run these commands from the root of the RustDesk repository, or the application may not find the required resources. Also note that other cargo subcommands such as install or run are not currently supported via this method as they would install or run the program inside the container instead of the host.
File Structure
- libs/hbb_common: video codec, config, tcp/udp wrapper, and some other utility functions shared with the server
- libs/base: protobuf, fs functions for file transfer, keyboard and platform code used only by this app
- libs/scrap: screen capture
- libs/enigo: platform specific keyboard/mouse control
- libs/clipboard: file copy and paste implementation for Windows, Linux, macOS.
- src/ui: obsolete Sciter UI (deprecated)
- src/server: audio/clipboard/input/video services, and network connections
- src/client.rs: start a peer connection
- src/rendezvous_mediator.rs: Communicate with rustdesk-server, wait for remote direct (TCP hole punching) or relayed connection
- src/platform: platform specific code
- flutter: Flutter code for desktop and mobile