Making Remote Control Usable—and Bounded

RustDesk's authorization model becomes visible only when it activates real services. This chapter follows what happens after a connection is allowed: how shared display, camera, audio, clipboard, and input services turn capture into a usable stream, and why file transfer, terminal access, tunnels, and privacy mode cross different authority boundaries. The goal is to judge both halves of the experience—whether the system can deliver a responsive session and whether each powerful action remains scoped to the permission that enabled it.

The media plane is shared and demand-driven

A remote desktop is not one camera pointed at a screen. The controlled endpoint has to capture a display or camera, convert the data into a form the peer can decode, manage CPU and network pressure, and send frames to the connections that are authorized to receive them. RustDesk organizes that work through long-lived services. A connection subscribes to the services it is allowed to use; a service can remain hibernated when it has no subscribers and can send a snapshot or format description when a new subscriber arrives.

This ownership model matters when more than one connection is active. A separate capture loop for every viewer could multiply the cost of screen capture and encoding. RustDesk instead treats the display or camera service as a shared producer and keeps connection-specific subscription state around it. The service can send the same encoded frame to several authorized connections while retaining enough information to notice when a subscriber is slow. That is a resource decision with a security consequence: an unauthorised connection should not become a subscriber merely because it reached the transport.

The video pipeline starts with a platform capture adapter. It can obtain a monitor or camera frame, detect changes in display state, and choose an encoder based on negotiated support and platform capabilities. The repository supports several codec families, including VP8/VP9, H.264/H.265, and AV1, with fallback behavior when a preferred encoder cannot be created or a hardware path fails. The exact best codec depends on the endpoint and peer; the source supports negotiation and fallback, not a universal promise of image quality or latency.

Quality is managed as a feedback problem. RustDesk's video service tracks frame pacing and quality through its QoS state, and it can wait for subscribers to receive a frame before allowing capture to run ahead. If a connection is slow, the write path and frame acknowledgements provide evidence of backpressure. The visible result may be lower quality, fewer frames, or a capture loop that waits rather than consuming unlimited memory. That trade-off is why “the network is slow” can appear as a choppy image, a delayed cursor, or a change in encoding rather than one simple error.

The same pipeline has to respond to state changes. A monitor can be added or removed, a display resolution can change, an encoder can stop working, a user can enable recording, or privacy mode can alter which capturer is allowed. The service may refresh its display information or restart the capture path instead of continuing to send frames produced under obsolete assumptions.