This is very cool. I still think MS RDP is the best remote desktop client and protocol. The performance is just insanely good, and the client is easily available on 95% of computers. The multi-monitor support is also awesome. The only downside is that it's Microsoft...
If you think RDP performance is good, you should try Sunshine+Moonlight. I regularly stream at 4k 120hz from my gaming PC to my laptop and it's basically indistinguishable from running locally. I've even run it over Tailscale from a thousand miles away (though at 1080p60) and it was still markedly better than RDP.
Caveats - You really want a Windows host for fully accelerated on-GPU hardware video encoding, the server setup is _slightly_ more involved than RDP which is usually preinstalled, and Sunshine+Linux+NVidia requires an annoying driver patch. But overall it's _amazing_.
I'd still pick RDP for remote managing any day, its server and client are so much better integrated (clipboard, peripherals, etc.) for this task than Sunshine/Moonlight. It also avoids the whole issue of setting up a virtual display output[1] as is required by Sunshine. I use both for different tasks.
On a related note, as of recent versions, Sunshine and Moonlight stable releases support 4:4:4 chroma subsampling and bitrates up to 500Mbit/s with HEVC, which results in almost indistinguishable image quality compared to native output[2]. Bitrates that high are unusual in normal content, but at least Apple's Media Engine (on M-series Macs) appears to be capable of decoding it.
[1] Here is a pretty good solution that piggybacks off of Parsec's driver, which is fully signed, though its EDID lacks HDR support. The project also includes a C header file for custom implementations: https://github.com/nomi-san/parsec-vdd
[2] Note: I found that I had to enable 10-bit color streaming (which is available when using Parsec's driver) to get rid of some gradient banding that isn't present in native 8-bit. I suspect it's some encoder and/or color space issue.
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.
TBH, After trying both I'd still pick RDP (I used xRDP server on linux) for anything text/GUI related. RDP(not VNC or VNC larpin as RDP) doesn't make image compression artifacts when the connection gets bad it's just add some lag keeping the text crisp.
Sunshine/Moonlight on the other hand reduce image quality keeping the latency low, which is really good when streaming games for example.
> I regularly stream at 4k 120hz from my gaming PC to my laptop and it's basically indistinguishable from running locally
Sunshine+Moonshine is great but lets not exaggerate. On controller it feels fine, on mouse it is still a noticeable difference from local play. I'd compare it to turning on classic v-sync (so not fast sync).
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 use Sunshine and Moonlight when I'm out away from my Windows laptop in my home office and back near the router in the front room over my Macbook air, it's great when you can get directly on the LAN with it. But then, RDP is also better over the LAN, and casual disconnection is easier.
But if I want to do graphics-intensive work on the headless tower, I'll use Sunshine and Moonlight.
There are a few disadvantages, in sunshine/moonlight such as you still have monitor output, so you are stuck to the resolutions supported by your monitor and someone can see what you are doing. Of course there are workarounds like dummy monitors.
I do not have clipboard sharing working (I’m not sure if it is even supported) and there is a bug where some specific keys (including \) do not work on some keyboard layouts (Japanese for example), although there is already a pull request that supposedly fix that.
Still it is an amazing solution. The snappiness of having full 3D acceleration is amazing, and as another plus it works in the home edition of Windows.
> 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.
That doesn't compare to RDP where remote windows act just like local windows in that you can resize them and drag them between monitors, they're not constrained to just being on a virtual desktop.
RemoteApp is basically RDP for one single desktop app running on the remote server but launched and run to appear like a local app. It's improved a lot over the past decade+
There's an extra interesting feature there where the remoteapp windows are aware of each other. It's a niche use case, but the remote side counts as one session, so apps can interact and automation/accessibility mostly works as expected. Although the local system still sees the remote apps as opaque rectangle rather than widgets.
I haven't use them, so please bear my illiteracy around these. Does this mean, it actually creates a local session, not a remote and headless session to serve? If that's the case, it feels like it's just TeamViewer or Remote Assist session where you hop in to an existing session. Or do I misunderstand the concept?
So Sunshine and Apollo are continuations of Nvidia's EOL'd GameStream tech, which is designed to mirror the local display to a device. It doesn't really have the concept of a "user session", it allows you to mirror the currently running local session remotely.
> If that's the case, it feels like it's just TeamViewer or Remote Assist session where you hop in to an existing session
Yes, it's pretty much that, but optimized for A/V latency and game inputs (games that "trap" the mouse in fullscreen are well supported and controller inputs are passed through).
I haven't really used TeamViewer/Remote Assist heavily, but I wager if you wanted to game with those tools it would be a worse experience than something like Sunshine.
>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!).
Does that mean someone with physical access can take control while you're logged in?
Yes - afaik all of the "game streaming" solutions (Sunshine, Apollo, and probably others) derive from Nvidia's GameStream tech which just mirrors the local display remotely.
My buddy was absolutely delighted by Sunshine+Moonlight and basically forced me to try it. Long story short, it is not nearly as responsive for dev tasks, amazing for gamings or streaming, however.
In your experience, how's Moonlight at audio streaming, particularly in terms of latency?
This is something that most mainstream remote access solutions struggle with, hence why e.g. many screen readers come integrated with some bespoke remote access solution of their own. That's not the only reason, but definitely a very important one, and getting audio right would go a long way towards making a single solution work well for both SR and non-SR users.
Disclaimer, I know nothing of the internals of Microsoft RDP, but it does not appear to use an image representation like VLC, etc. do. My suspicion is that Windows APIs are intercepted and used to build the desktop experience. Don't get me wrong, I know A LOT about Windows internals, but I never looked into that part, sadly. What I do know is based upon what I see, and what I see leads me to the comment above.
The thing about Microsoft RDP is that even at high resolutions it's NOT just streaming 4k video. It uses way way way less bandwidth (and requires way less of a performance GPU / CPU). It uses a ton of tricks like having the local client render as much as possible instead of just streaming video. This results in it feeling way more responsive and native desktop like.
At Cloudflare we used IronRDP to build our Cloudflare Access RDP product [0] and scale RDP access across our edge using workers.
I can't say enough good things about the IronRDP project. I didn't write the RDP code deployed in Cloudflare Access, but I did some of the prototyping with IronRDP.
* IronRDP code was excellent, thoughtful and well designed.
* The IronRDP project was friendly, responsive and helpful. They answered some pretty obscure RDP questions I had.
I would recommend anyone doing RDP protocol work to use the IronRDP project.
*edit:* I didn't even realize it until someone pointed it out but our blog post on Cloudflare using IronRDP went live today.
Can IronRDP work with HTML5? I find myself using Guacamole because a lot of firewalls block WebSockets or the admins block WebSockets in their browsers.
I feel like a more modern approach like whatever RustDesk uses is way better. It has such good performance that I can practically play an FPS video game through it or watch a movie through it.
The big thing I hate about regular Microsoft RDP is you aren't getting to use your remote GPU through it.
I tried using RustDesk, but it gave me absolutely no feedback after I entered connection info for my local ID server if it was actually using that or not. I tried enabling debug logging to get a better idea of what was going on, but that wasn't working for me. When I got to the point of trying to figure it out through Wireshark, I realized that was stupid to even have to do and just gave up on RustDesk.
RDP GPU acceleration should be available (on Windows, at least) with the right quality settings. AFAIK nothing API-wise prevents GPU software from running. That said, RDP is an edge case few software developers bother testing so I'm sure there are lots of programs out there that ignore edge cases when it comes to rendering APIs.
It's not optimised for games, though. Something like Parsec would be much better for interactive stuff like that, or maybe something like Moonlight for Nvidia cards if you're looking to go without closed source software.
RDP also supports streaming regions, including the entire desktop, as hardware-encoded video. It was introduced 9 years ago[1].
As for performance, I've been playing full-screen games over it. Latency sucked when I was literally on the opposite side of the earth but if the bandwidth was there it worked fine.
From work to home RDP is typically indistinguishable from being local for me.
Another user of RustDesk here, would definitely recommend it!
My use case is more like replacing a KVM switch, but in addition to being performant and free (I no longer need RealVNC), it lets you run your own relay if you want and also supports virtual monitors - meaning that my laptop can have its screen and 3 virtual monitors, so that I can fill up all 4 of my desktop PC monitors when I want to remote into the laptop!
Yes I have seen OpenGL applications refuse to start with AMD cards in some circumstances due to a bug in the AMD drivers, but never had a problem on NVIDIA cards
It's very good at being a remote _desktop_ protocol, but the fact that it lacks features like tunneling and that authentication is the usual MS mess makes me wish they just went with SSH as transport protocol.
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).
The Citrix/Microsoft relationship is a bonkers story. The world didn't yet know that licensing your tech to Microsoft meant you were going to grab your ankles.
Smart cards is just certificate-based authentication really.
Microsoft did indeed fail hard - if they just made certificate authentication easy to configure on stand-alone machines like SSH key authentication is (and allow to keep the key as a file if desired, instead of in a smart card), a lot of pwnage would've been avoided.
Sometimes i'm using remote desktop inside a remote desktop, and it amazes me every time that it works so well, like there's no visible performance penalty or quality degradation in that. So yes, maybe it doesn't tunnel TCP but does the main task pretty well. And TCP can be tunneled with ssh, which also does its thing very well.
Bitvise SSH client (a great application BTW) has a nice feature that allows you to open tunneled RDP connection to the machine where you're connected via ssh, with a single button click and without the need for another authentication. Plus all the TCP tunneling you need. Highly recommended.
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!
Do you not remember the Microsoft of the late 1990s?
We’re lucky it didn’t cost $250/seat. And we’re luckier that it’s effectively an open protocol, today, though there are still license considerations if you are reaching into Windows.
I was a remote system admin BEFORE Remote Desktop. It was not fun. I would have gladly paid $500/seat at the time for RDP, if that’s what it cost.
None worked well at all. They existed, and I tried them, but they were all either unreliable or unusable because of their bandwidth requirements coupled with 56k modems.
There was no good solution for this until RDP came along.
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/
Kerberos has a protocol for when you don't have a line of sight to the KDC: IAKERB. IIRC MSFT is very interested in it in order to kill off NTLM finally.
IAKerb still hasn't shipped - it's a preview feature. Meanwhile, we've been doing KDC proxying successfully in Devolutions Gateway for several years. Sometimes you can wait forever for a supposedly better solution, or you can just make it work in the most obvious way. In the end, all you need is to forward KDC messages, right? It's annoying that it's out-of-band, but the KDC proxying protocol is just an HTTP POST that takes a request message, and sends the response message back.
RD Gateway has nothing to do with tunneling, it's just a reverse proxy for RDP connections. Funny note: as you've mentioned in other comment, my guess is that RDG was also licensed from Citrix but at the later point.
If I recall correctly one of the main reasons replacing X windows with Wayland is so that we can similar performance of remote desktop for Linux as provided by RDP for Windows. Along that many commentaries on how lousy and ad hoc it was the Linux remote desktop solutions based on X windows unlike RDP and Wayland is touted as modern Linux desktop saviour.
I'm wondering after many years now, what is is the state-of-the-art of Linux remote desktop status that now Wayland is the default Linux desktop windowing system for Linux, is it comparable to Windows RDP now or better?
It will be good to have high performance remote desktop based on Rust or any strongly typed compiled language for Wayland. This can be a good showcase of Rust for Linux instead of the recent Linux kernel brouhaha.
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.
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.
Gnome and KDE both support RDP in recent releases. Works ok, but connecting is not as seamless as Windows, at least with mstsc.exe. I’ve found it somewhat buggy too (blank or black screens until rebooted for example.)
One of the big things holding me back was good Remote Desktop experience on Linux. Using Gnome RDP has been good enough for basic use for me.
How about spice? I don't know anything about the technical details, but it seems to offer most of the advanced features like usb redirect and I think currently gets video support. It's currently really only used in qemu but I don't see a reason why you can't use it as a general open rdp alternative.
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.
It's usually pretty good on windows because it does a lot of local drawing but most Linux servers don't support that and use it just as a dumb blockpusher like VNC :(
Agreed. Its not just that its better, it is also that most of the settings for Linux ends up not using the same desktop you would get if you were sitting in front of it.
I still haven't found a solution for where I can login over the network and accessing the same session I would have gotten by sitting in front of the computer (including GPU acelleration). The guides are either for something like NoMachine that requires your screen to be on and often that you are logged in first, or they start a separate environment up using something like VNC.
Meanwhile Remote Desktop, as you said, just works.
I got so used to working in RDP that I can't really process the difference for non-gaming use cases.
At the end of every day on my personal machine, I will inevitably mouse up to the top-middle of my screen and realize I am not inside some W365 instance.
It is really nice, I'm very sad that Apple's RDP implementations seem fragmented and difficult to use. I've tried a few times with my Mac Mini, and it just doesn't seem to work that well.
They use simple VNC but with some special “applesauce” that makes every non-Mac client I have ever tried break after a minute or so.
But, on a mac, when you “screen share” into another Mac (this is what they call it for some reason; you “screen share into” the remote) it is flawless and quite snappy.
If you want to connect to the built-in macOS remote desktop server, don't use a standard VNC client, use a real ARD client like Remote Desktop Manager. While the server accepts standard VNC, you will only get zlib the codec, which has very poor performance. With ARD, you get a special codec inspired by progressive JPEG, along with server-side downscaling and chroma subsampling, etc. It's actually closer to RDP RemoteFX in terms of performance: https://devolutions.net/integration-center/apple-remote-desk...
