And on we go with yet another look at Rustdesk, a cool software for remote support, particularly for smartphones in my case: How does the project set-up look like and how does it transfer data over the network?
Project Setup, Licenses, Code Availability
Before coming to the network traffic, I decided to say a few words about the project setup, because I find it a bit strange. When looking at their website, an address for a company office in Singapore is given. On a different page, it is stated the the laws of the Cayman Islands apply. And that’s pretty much it. In other words, it looks a bit strange.
On the positive side, the server and client software is hosted on Github under the AGPL-3.0 and MIT licenses, so the code can be inspected and forked. Another plus is that the client is available on F-Droid, where it is compiled by the project rather than by the author. Also on the positive side, the project’s documentation and FAQ is very extensive, so it looks to me like it is currently well maintained. Also, apart from the free community edition, they do have paid plans with extra features, so they probably have a sustainable setup.
Network Traffic
So, let’s get to the network traffic. Real time video streaming between two devices over the Internet and NAT gateways is a bit of a challenge, so I was curious to find out how they do it.
Unsurprisingly, they use STUN servers to find out if a client can be reached directly or only through a NAT gateway. For this purpose, they use a number of different public STUN servers that range from Google to Cloudflare and Nextcloud. Have a look at the screenshot above for further details. Tap and open in a new window for the full resolution version.
Once the network translation parameters are known, the client connects to the public RustDesk server. It’s possible to host your own server, but since I will only use the software occasionally, I think the public RustDesk server will suite me just fine. In my case, a public server in Europe was used in one of OVH’s data centers. Sounds good to me.
While I expected to see WebRTC on UDP being used, which is a typical transport-, video- and security protocol and used by many messenger services, Rustdesk uses a TCP connection. On the RustDesk web page, it is stated that encryption is based on the NaCl library. While I’m not a crypt analyst I still had a look at the data stream, and apart from the beginning of the stream, I could only see random looking data being exchanged. How much or little that means is difficult to say from the trace, but those who want to dig deeper can always look at the code to find out more.
And finally, the data rate of the stream is also important, particularly in cases where the remote device only has a marginal Internet connection. As can be seen in the second screenshot above, the data rate is pretty much zero when nothing on the screen moves and peaks at 3 to 4 Mbit/s during changes on the remote smartphone screen. In good network conditions, giving remote help works nicely with these data rates, but I haven’t tried how quickly the remote screen gets updated on the supporting device when only a few hundred kilobits go through the uplink in marginal radio conditions. But OK, it’s a mobile device so it can potentially always be moved more closely to a window.
And here we go, this was the final part of my RustDesk notes, I hope there was some interesting stuff in it for you as well.