Slow Performance

[DanHolli]

I've been testing out your API server, but the performance in my testing seems to be a bit lacking.
I'm using your api server with the official rustdesk-server

Without being logged in, it takes about 1 second to connect to a remote computer
While logged in, it takes about 9 seconds to connect to the remote computer

Isolating the API server by launching it behind a different port, it appears to not reply until the end of the connection but still takes 7-9 seconds to get there.

Is there something I'm missing?

[danielmarschall]

If you mean with "official rustdesk-server" the public server and not a Pro server, then I think I know the reason why you have performance issues once you are logged in.

The problem lies in the RustDesk client, not in the API server. There is a secure_tcp command that is encrypting the TCP connection if someone is logged into (any) API server, in order to protect the access token.

The secure_tcp command will send a KeyExchange request to the server, but only the Pro server implements this. The OpenSource server does not support the KeyExchange command, hence secure_tcp will fail with a TimeOut. (And in the future versions of RustDesk, it will fail completely to fix a security vulnerability where an attacker could invalidate the KeyExchange package in order to force the client to send the access token unencrypted)

The only way to use a foreign API server is to build a custom client where the secure_tcp method is commented out. But note that the access token might be leaked if you are in an insecure network. The big advantage of a custom client (e.g. build with GitHub actions) is that you can include the API/Relay/Signal server and public key into the binary, so you have an out-of-box working client.

---

Side note / off-topic: A second occurrence of the secure_tcp command seems to be the place where the Rendezvous mediator decides if TCP or UDP is used. If TCP is used, secure_tcp will be called, which will delay (or in the future, fail) with OpenSource servers. But TCP seems to be used if the user chooses a proxy. I don't have access to a SOCKS5 proxy, so I wonder, can someone please test if an SOCKS5 proxy indeed causes a severe delay or failure due to secure_tcp, or did I misinterpreted the source code?

[DanHolli]

Just made a fork of the client commenting out some of the lines related to the timeout and used the Nightly build Action and tested and there's no more delay. So it seems you are correct. I might maintain this fork, problem is I'm not familiar with Rust to make any code edits if they're needed in the future

https://github.com/DanHolli/rustdesk