IronRDP: a Rust implementation of Microsoft's RDP protocol

I wonder how Apple's ProRes would work for remote desktop over wired networks, especially now that consumer equipment is starting to move beyond 1GbE. They have hardware encode and decode on everything newer than the original M1, and ProRes only does intra-frame compression so a fairly low-latency implementation should be possible.

> Sunshine/Moonlight on the other hand reduce image quality keeping the latency low

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

Tested this out again with Overwatch - latency is single-digit milliseconds even at 4k120. I can feel a _slight_ bit of lag at those settings, anything below that is as good as local.

I'm not exaggerating at all. I regularly play Overwatch over this setup and it's totally fine.

> in sunshine/moonlight such as you still have monitor output

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

You gave up too early! I host my own server on a 5$ DO droplet. Have >100 clients, RustDesk never failed me once. Works like a charm.

I know it's not made for games, but the thing is I am seeing Parsec-level performance and quality from RustDesk which why I am liking it so much.

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.

I've had issues with some software & games not being able to get a proper display context and refusing to start.

OpenSSH is an implementation, SSH is a technology and/or protocol, it doesn't make a lot of sense to compare them that way. Although from later comments RDP seems to have a history in Citrix prior to it's life as RDP, so there are likely clear reasons why it didn't use the SSH protocol (namely that the underlying technology RDP was built on does predate the SSH protocol).

According to Wikipedia, RDP = June 16, 1998 SSH = 1995. OpenSSH = 1999

In the several decades since, nothing has stopped them from coming out with a "RDP v2."

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

Yeah I messed with that. Sidechannel DLLs for RDP aren't fun. XFreeRDP actually also supports that on Linux.

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 remote desktop from my Mac into Windows for work. I used to then remote from that Windows into another Windows server, at which point figuring out what the keyboard mappings were became extremely difficult!

RDP-over-SSH will break Kerberos authentication for two reasons: 1) you'll point the RDP client to localhost and a random port and 2) you won't get a KDC line-of-sight. The irony is Microsoft has demoed this with SSH over Azure Arc, which can only result in an NTLM downgrade.

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/

RD Gateway leverages SSL for encrypted transport for RDP between client and host. Maybe it is possible :-)

Weren't there any other solutions? (Searching ...) Norton? Citrix? VNC?

That article instructs readers to use H.264 rendering and to set DWMFRAMEINTERVAL - thing is, DWMFRAMEINTERVAL is a host-side parameter and apparently all it does is set an upper-limit on the possible refresh rate [1], rather than force the entire RDP system (client and server) to run at a specific frane-rate. This also conflicts with a personal experience of mine: possibly around 2007-2009 I remember using a FOSS RDP client meant for Linux but ported to Windows for some reason, and I preferred using it to connect to a shared WS2003 TermSrv box on the LAN because it sure felt like 60fps, despite everything else wrong with a barely-complete Win32 port (I don’t think they even used MINGW; mad lads…). It was my own TermSrv box and I know I didn’t do anything server-side to make it work so buttery-smooth.

…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...

The main protocol should be well outside patent protection, but some of the extensions (RemoteFX, audio support, etc) may still be covered, would have to double-check. Likely fine.

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.

https://www.microsoft.com/en-us/legal/intellectualproperty/t...

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.

TypeScript as it exists from Microsoft isn't a runtime engine.

Iron* is based on dynamic language support... JScript.Net wasn't and was abandoned well before.

Thanks not only for your reply and chat invitation but also all of you for the work on this nice project!

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

Note that this is a bit of a POV thing. For one, CPU cycles handling display also go (indirectly) to your user. And if your users gets a crisper and better picture with less bandwidth due to a modern codec then it can be also seen as win in my book.

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.

Wouldn't it also be a problem that, IIUC, a CPU only has one encoding engine, so you could only have one active stream (at full speed), in a multi-tenant scenario?

Here I'm talking about our integration, which means full audit of what's possible in a simple POC, then a more involved look to see how we can integrate it nicely in the Proxmox VE stack, from low level QEMU to the REST API and its ACL system.

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.

Lots of tradeoffs. If you invent a new codec, it's unlikely to make it into hardware for a while (even AV1 encoders are not yet as widely supported) and therefore you will have to do encoding and even decoding in CPU, which takes away resources from the workload. h.264 is still probably the best general purpose codec for real-time desktop streaming - low bandwidth requirements, 444 support, build to lossless, low latency, moderate CPU usage if GPU is not available, and well supported in GPUs for a long time (e.g. even back to Kepler).

VNC with compression does already exist in the form of TightVNC[0].

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

Low CPU overhead. VNC streams screen grabs with minimal (if any) compression, which results in lower CPU overhead, high bandwidth consumption and low frame rate. This is okay for the use-case of low-level VM debugging that it's used for in context of virtualization management systems, not so great for desktop remoting.

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 don't know if Gnome/KDE leverage the partial update mechanism

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?

RDP doesn't need to tie into the OS like that. Plenty of ways to run X11 over RDP, for instance. And unlike in VNC, you can actually use the forward/back buttons on your mouse!

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.

Yes, IronRDP is written entirely in Rust, but we also have bindings for .NET and the web. We originally developed it for our RDP web client for Devolutions Gateway (https://github.com/Devolutions/devolutions-gateway) but now also support it as an option in Remote Desktop Manager (https://devolutions.net/remote-desktop-manager/).

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.

Github's languages analysis says 87.7% Rust, 9.3% C#, 1.3% TypeScript.