RustDeskandClaude Opus 5
7eb9150116
* fix: retry audit posts and add per-record nonce A single post_request attempt meant any transient failure (timeout, DNS, connection reset) silently dropped the audit record. Retry up to 3 times with backoff and log at error level when a record is finally dropped. Retries (and the existing TCP-proxy fallback) can deliver the same record twice; attach a per-record nonce so the api server can dedup. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: fail audit posts on http error status post_request discards the status code, so a 5xx from a reverse proxy (e.g. nginx answering 502 while hbbs restarts) or any 4xx rejection was treated as success and the audit record silently dropped without a log line. Add post_request_with_status (same semantics and TCP-proxy fallback as post_request, status preserved; existing callers untouched) and use it for audit posts: 2xx succeeds, transport errors and 5xx retry, 4xx fails immediately since retrying a deterministic rejection cannot help. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: report audit posts rejected with 200 error body hbbs maps handler failures (e.g. a database write error) to HTTP 200 with an {"error": ...} body (WebError::ServerError), so the client treated them as success and the audit record was silently dropped. Detect the error body and fail visibly. No retry: the server already consumed the nonce, and persistence failures are the server's job to solve; the client's job is to make the loss visible. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: give audit retries a delay long enough to outlive a restart The backoff was 1s then 2s, so all three attempts landed within about three seconds. That does not cover the case the retry exists for: a reverse proxy answering 502 while the api server restarts fails fast, so every attempt hits the same outage and the record is dropped anyway. Use 10s and 30s instead. The window is bounded on the other side - the api server dedups by nonce for five minutes, and a retry arriving after that expired would be stored twice - so the worst case is now about three minutes, leaving room under that limit. Derive the attempt count from the delay table so the two cannot drift apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: retry audit posts the server answered with an error body hbbs reports handler failures as 200 with an {"error": ...} body, and this treated them as final on the grounds that the server had already consumed the record's nonce. That is no longer how the server behaves: it releases the nonce when the write fails, and answers a post whose earlier attempt is still being written with an error as well. Both are exactly the cases where trying again is what gets the record stored, so giving up after the first attempt drops audit records the retry was added to save. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: bound audit retries by elapsed time, and retry 408 and 429 The comment claimed the retry window fit inside the server's five-minute nonce memory with room to spare, and that was wrong: one attempt is up to 84s, not 12s, because post_request_ retries the TLS handshake up to four times at 12s each before the 36s TCP-proxy fallback. Three of those plus the delays is 292s against a 300s window, and a suspend between attempts stretches the wall clock without any bound at all, so counting attempts cannot bound this. Stop by elapsed time instead: no new attempt starts past 120s, which leaves the last one room to finish well inside the server's window. Also retry 408 and 429. Both are transient - the request timed out upstream, or a proxy is shedding load - but the 5xx test dropped the record after the first attempt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: only an empty 2xx body counts as a stored audit The success check was inverted: any 2xx body that failed to parse as an {"error": ...} object was reported as stored. A proxy interposing a 2xx maintenance page, or a malformed error value, therefore ended the retry loop with success and silently dropped the record - the exact loss the retry was added to prevent. The audit handlers' success contract is an empty body, so treat exactly that as success. A nonempty body with a valid error message stays a retryable server error; any other nonempty body is now a retryable "unexpected response body" instead of an accepted store. Both old and new hbbs answer success with an empty body, and no caller reads the returned text, so nothing depends on the previous acceptance. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: do not start an audit retry past the deadline The deadline was only checked after an attempt returned, so an attempt could still begin up to one backoff delay past it - starting as late as ~150s and landing at ~234s, while the comment claimed no attempt starts past 120s. Re-check after the delay so the stated bound actually holds: the last attempt now starts before 120s and lands by ~204s, inside the server's five-minute nonce window with margin restored. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: drop a retry rationale the server no longer backs The comment claimed hbbs answers a post whose earlier attempt is still being written with an error, so that retrying it is what stores the record. That stopped being true: hbbs now answers a concurrent duplicate as already stored rather than as retryable, having dropped the in-flight rejection along with the claim state machine it needed. Nothing in the handling changes - a 2xx carrying an {"error": ...} body is still retried, and that is still right, because the server releases the record's nonce when its write fails. Only the half of the rationale the server no longer backs is gone, since this comment is where the contract between the two repos is written down. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Build •
Docker •
Structure •
Snapshot
[Українська] | [č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 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 libpam0g-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 pam-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 pam-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, protobuf, fs functions for file transfer, and some other utility functions
- 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
- flutter/web/js: JavaScript for Flutter web client