IronRDP: a Rust implementation of Microsoft's RDP protocol

…which tells me that the compromised user-experience caused by the artificially capped frane-rate of the RDP session is entirely at the direction of the client, not the server. But that was… 15+ years ago (…fuck), it’s possible the protocol has changed and maybe it’s something both host and client negotiate, but clearly its possible and clearly someone in the Windows Server group at MSFT enjoys cinema too much because they seem to think 24fps is good enough for everyone.

Also, when you use H.264 in RDP, it defaults to 4:2:0 chroma subsampling[2] which is going to ruin fine-details and make text ugly if not unreadable - there’s a reason we use H.264 for movies but not text documents. I remember around 2013 when a bunch of competing remote-access companies all launched hardware-accelerated-video-based remote-desktop products and being impressed with how they handle remote-Netflix over a pre-LTE mobile tether, but reeling and gasping to throw-up after their aggressive codec motion-estimation, subsampling, and YUV colorspace absolutely butchered a 100% zoom Word document with ClearType enabled. Using the system instilled oneself with a strong discipline against ever moving or resizing a window on the desktop, lest the smears of low-bitrate macroblocks start to appear, warning you the text-on-screen is about to become painfully unreadable for the next few seconds while you curse the DSL connection you’re still forced to use because your apartment complex’s HOA got a sweet deal on satellite TV from the incumbent telco by blocking the local cableco, with their sweet sweet DOCSIS 4, from adding service to the building and I’m done.

[1] https://learn.microsoft.com/en-us/troubleshoot/windows-serve... [2] https://learn.microsoft.com/en-us/azure/virtual-desktop/grap...

I would like to see something as capable make its way into Linux and Mac that's as ubiquitous. RDP tends to work better than the VNC options most other solutions are using under the hood.

I don't think the Free Software ecosystem should touch RDP. It only fuels Microsoft even more.

If Microsoft was the company they pretend to be, they would Open Source (Apache) DOS 6.22, FAT/ExFAT, RDP and they would allow for side loading of applications on Xbox.

IronRDP is designed to work with Devolutions Gateway (https://github.com/Devolutions/devolutions-gateway) for just-in-time RDP connections made from the web or through the desktop client. Devolutions Gateway also supports just-in-time KDC proxying alongside the main RDP connection, making Kerberos possible.

You can install the free standalone web access package of Devolutions Gateway to try it out, it will give you a simple web interface where you can enter the hostname, username and password.

But if you really want the simplest solution, it's with the rest of the Devolutions stack with Remote Desktop Manager and Devolutions Server. In the end, you'll be able to make RDP connections from RDM or through the web with just a double-click, and it'll automatically generate short-lived tokens and make RDP + Kerberos work seamlessly: https://devolutions.net/gateway/

I used it for signalling phone calls from the client to an RDP RemoteApp and initiating calls from the RemoteApp.

I would decline that project if I was asked today.

I trust SSH to be public-facing. Don't have the right private key? Pound sand. You're not getting in.

I trust RDP to allow someone to break into my machine, get admin privileges, and infect / bot it, likely in under an hour.

Smart cards rolls eyes

With modern hardware with RustDesk you are getting HEVC or even AV1 hardware encoded high framerate stream of your desktop.

I have never seen this kind of performance through MS RDP personally.

You can set it to any speed, including LAN speed, according to the available bandwidth/connection.

Apollo[1] fixes this problem really neatly - there's a "Virtual Desktop" option that adds a virtual desktop, and you can disable all the local monitors while in this session so that a local person doesn't see your desktop while you're remoted into it (just remember to lock after you end your session!).

I believe it also preserves monitor layouts when starting/ending sessions.

I used Sunshine and had a bunch of hacks in the startup/teardown scripts to get the same behavior but it was really brittle. Apollo makes this work out of the box.

[1] https://github.com/ClassicOldSong/Apollo

[0]https://en.wikipedia.org/wiki/TightVNC#Encodings

RDP in Windows happens to be implemented using some fancy tricks that make it a much better OS for remote work than any Linux distro, but that doesn't mean that's the only possible implementation. Whatever logic can be used to detect block updates in VNC works just as well over RDP. Audio over RDP also works fine on both Windows and Linux so I don't see what the problem would be anywhere else.

As for the shutdown thing, Linux seems to do that too. Makes sense if you use your computer as a terminal server, I guess. I don't reboot my computer over RDP enough to care, really. Still, that's just an implementation choice, nothing to do with the protocol itself.

While RDP may run okay on 56k with low color mode for some use cases (e.g. simple Windows admin), it requires significantly more bandwidth and compute overhead (either CPU or GPU) for other more advanced use-cases (e.g. video editing, CAD etc.)

I guess that would be something for the wayland compositor to manage. Maybe a wayland compositor that is also an RDP server? or maybe they're all like that already?

Modern CPUs more often have the building blocks included for video encoding, and getting one of those, or a dedicated GPU, probably makes sense if the Users/VMs workload depends on graphical output.

That said, you're definitively also right that it won't be a win for every use case on every hardware, so definitively something to look at more closely, and if it really is worse than the status quo on systems without dedicate GPU and where the CPU has now HW accelleration than the status quo, which I doubt, then adding an opt-out will definitivelys make sense.

We started evaluation a few weeks ago in combination with the QEMU display work, which is still experimental and was initially announced mid-January this year, so we're still at the POC stage and thus this work will be a bit more time. I did nowhere say that IronRDP will need more time.

And FWIW, without an integrated approach RDP gains you almost nothing over plain VNC if you have only the reduced interfaces and access from outside the VM, so using something like IronRDP earlier on its own would not have gained us much besides an extra component to maintain, that's why we did not checked out integration earlier.

I'll relay your invitation to the persons mainly doing the evaluation. And good to hear that QOI image coded is getting further adoption.

This approach is fundamentally limited in terms of performance/responsiveness, as you're ultimately just trying to "guess" what's happening and apply best-effort techniques to speed things up, falling back to just using a video stream.

A proper remote desktop solution like RDP on Windows works in cooperation with the OS's GUI subsystem in a way that makes the RDP server aware of the GUI events, so it doesn't have to guess, and can offload compositing and some 2D operations directly to the client, rather than sending rendered bitmaps.

Thus it didn't catch on because it focuses on a narrow use-case nobody should be using except in emergency/break-glass situations (you should instead be remoting into the VM directly, for reasons explained above), and even for such situations, it didn't offer anything substantial over VNC, except everyone and their dog has a VNC client by now, but good luck finding a functional SPICE client for anything but Linux.

Devolutions Gateway implements the RDCleanPath extension used to bridge WSS to RDP, making the connection from a web client possible. The same IronRDP core can be compiled to a native client for regular RDP connections outside the browser. There is also some work done for the server, but it's not as advanced as XRDP.

But cmake is required by Rustls (or more precisely, aws-lc-rs).