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...
I think of IronPython and IronRuby and IronScheme, early attempts at Microsoft trying to combine cornmeal with .NET and open source and calling it a burrito.
That was my first thought as well. Surprised to see they're still seeing updates. Also surprised to never see an IronJS or IronTypescript or similar really.
Is it feature-complete with RDP and then some? As someone who has spent, over the last ~15 years, probably equal amount of screen time on RDP vs local (even in the office it's usually RDP to a blade, and at home a laptop to a powerful workstation; with remote work recently it's so much more and often nested), and someone who tried Linux on Desktop regularly and gave up because of inferior RDP alternatives (even GNONE 47 is a joke for RDP, but getting closer), - I learned to appreciate all the tiny details that make the RDP proper great.
The demo in the README is pretty impressive for an independent implementation, but I also noticed the repo includes server code (https://github.com/Devolutions/IronRDP/tree/master/crates/ir...). I wonder if tools like Proxmox could use this as a more efficient alternative to VNC (which is slow and weird) or SPICE (for which there are very few non-Linux tools).
> I wonder if tools like Proxmox could use this as a more efficient alternative to VNC (which is slow and weird) or SPICE (for which there are very few non-Linux tools).
Yeah, we at Proxmox are actually evaluating such things, and we hope that IronRDP and QEMU display [0] can be part of a stack that replaces SPICE in the long term, but it will need a bit more time to see how this play out and what exact role it can play in Proxmox VE.
Another experiment is to see if we can add a more modern video encoding to QEMU, as the recently released noVNC 1.6 gained support for H.264 [1]; albeit we naturally would prefer something more open like AV1.
We would be very happy if proxmox were to adopt IronRDP. I see you've already found the work from Marc-André Lureau, he's been doing an incredible job for the IronRDP server side. He's also been working on adding QOI image codec in IronRDP with incredible results. You're welcome to pop in the IronRDP matrix channel: https://matrix.to/#/!opeocvkWZVaLDouykU:matrix.org?via=matri...
Compute overhead of H.264 encoder is non-negligible for a VM host where I want all my CPU cycles to go to user VMs. Datacenter-class Intel CPUs (Xeon) don't include H.264 encoders in hardware. QuickSync circuitry is generally limited to consumer-grade CPUs. Not to mention MPEG licensing issues.
AV1 eliminates MPEG licensing issues, but encoding in hardware is even more limited. Also, AV1 is great for encode-once use cases (e.g. YouTube) since it's heavily geared towards reducing bandwidth requirements vs. encode speed. It's workable for real-time streaming in the lowest settings, but H.264 is still better overall.
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.
Part of what makes RDP performant compared to VNC is that the RDP server is aware of the GUI state and a lot of compositing is actually done by the client.
A hypervisor just sees the video output from the VM and has no knowledge of the underlying GUI's state, so even with RDP it won't be able to do much better than stream compressed bitmaps.
You're right, but that's why SPICE has a so-called Agent that runs inside the guest and provides a neater integration (like seamless switching from client to host, ad-hoc USB passthrough, sharing the clipboard, detecting video streams (theoretically), ...) and that would be also an option for an RDP approach.
True, but that also goes for VNC (though VNC isn't as optimised as RDP is).
Modern RDP also has the option to turn (parts of) the screen into a simple h.264 stream so the connection doesn't die when you open up a web page with an animated background.
Seems like what we need is a specialized compression algorithm. Since the domain is largely constrained it sure seems like there's some low-hanging fruit here.
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).
RDP is aimed at a different use case than VNC. Proxmox and other virtualization managers (e.g. VMWare, Nutanix) use VNC because you get a stream directly from the hypervisor (e.g. KVM, ESX) which is very useful for low-level debugging. The VNC protocol also has very low overhead (you don't really want h264 encoding CPU overhead on your VM host). VNC is not really intended for remote desktop use cases, which require higher fidelity/frame rate, etc.
So -
* VNC: Low overhead / Low fidelity
* RDP (and other remote desktop protocols, e.g. Frame Remoting Protocol, Horizon Blast, Citrix ICA/HDX): Higher overhead / High fidelity
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.)
That might practically be where VNC finds usage today, but when it was introduced in the 90s, remote desktops were the intended use case.
"In the virtual network computing
(VNC) system, server machines supply not only applications and data
but also an entire desktop environment that can be accessed from any
Internet-connected machine using a simple software NC." -- https://www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/at... (1998)
Given the CPU load I've witnessed on VNC servers, I don't think "low overhead" is right these days.
VNC was designed for remote desktop use. All the other streaming features came along later. I don't see why RDP would make for a worse choice here, other than that Windows VM integration would make for an better solution.
RDP used to be far inferior because it was proprietary Microsoft stuff with buggy open source clients and undocumented servers that kept changing stuff around. These days, open source RDP server software is actually quite solid. I don't know if Gnome/KDE leverage the partial update mechanism that makes RDP so useful on Windows (doesn't seem to seeing the performance I'm getting out of VMs), but I find RDP to be a lot more useful for interactive desktop streams than VNC.
> 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?
Also note that there is a critical difference in how they talk to the OS:
* VNC (and other non-RDP solutions like TeamViewer etc): fully independent application, does not change how Windows works because it's effectively just an interactive screen recorder running for your user account.
* RDP: is an actual Windows remote user session that hijacks the computer (so a local user can't see what's happening) and hooks directly into Windows with its own device bindings and login properties (e.g, you can't just click start -> shut down, instead you need to command-line your way to victory).
If you want to remote into a machine that's playing audio without interfering with that, RDP is flat out not an option. Even if you pick "leave audio on the remote", the fact that RPD forces windows to use a different audio device is enough to interfere with playback.
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.
My theory is Wayland happened. As SPICE doesn't work that well through it. I would assume it's another case of a "niche" the Wayland protocol didn't account for, however.
Interesting theory. Any idea on why SPICE wouldn't work well through it? I don't have recall running into any issues with it.
A more Wayland-oriented remote desktop protocol would probably make for an even better VNC alternative, but I don't really know why SPICE never got the uptake it deserved.
Wasn't aware SPICE was deprecated. However, I think it addresses a different use-case than RDP: SPICE is primarily designed for accessing virtual machines by connecting to their hypervisor. Thus it's designed to operate without VM guest awareness nor cooperation, going purely from a framebuffer.
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.
They installed a root certificate on windows computers that could have been used to MITM all traffic.
I personally had issues with the project years before that when I tried to install their Linux .deb and they ran `pip install` as root in the pre install script inside the .deb. That caused so much havoc to clean up I was pissed at them for years. Now that idiocy is blocked by default in current versions of pip.
The RDP GDI messages are from RDP6, graphical messages have changed many times over in the versions of RDP that followed. Would you be surprised to learn that WSLg uses a FreeRDP server hooked to a Wayland compositor running in the Linux guest, and that the RDP client in the Windows host is MSRDC in a special RemoteApp mode? In theory someone could build a similar RDP server using IronRDP
The Desktop Composition extension was never used in practice, check the date on the spec - the last update was in 2017. I don't know the whole story behind the scenes but the feature got pulled early.
Probably coincidentally, in a blog post today, Cloudflare announced clientless, browser-based support for RDP. It seems they're using IronRDP under the hood.
I love RDP! It really is an impressive technology. I work in-office somewhere, and when I'm on campus, RDPing into my desk laptop from a conference room client has native performance, with audio even.
This code seems to be part of some kind of cloud offering for enterprise cloud environments. A lot of RDP code seems to concentrate on a React component for connecting to an RDP server.
Edit: I've juist built the code on Linux and the demo video is recorded on Windows, so this seems multi-platform. There's also code for a .NET client in Avalonia (a cross-platform GUI library) so I'm guessing the entire thing should work on any modern OS.
There's a basic skeleton for an RDP server in the code, but the README is a bit short.
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.
Just a quick note from somebody who's been tinkering with RDP: RDP is so much more than remote desktop, and this ironrdp thing looks cool but is also severely limited.
xrdp supports forwarding audio (playback and microphone forwarding, both ways) as well as local folder forwarding. And I think i also got webcam working (webcam on my laptop forwarded to the browser running on the remote host).
Does someone know why folder forwarding is so slow? Browsing forwarded directories is not production ready at all! (I'm not talking about xrdp, but the original RDP.) Even SMB2 over WAN is faster.
If a program has a deep link and has to process one file, ok. Everything above that and it turns into a waiting game.
RDP has a huge array of features. It can be everything from server side rendered and just sending a video stream over the network to client side rendered and sending openGL commands over the network.
There is a massive difference between a basic implementation that works and a fully featured implementation which works reasonably over a 56k modem.
Interesting to see a Rust implementation of RDP. The protocol has a lot of quirks and edge cases that make it challenging to implement correctly, especially around authentication and session management. The focus on security is good, but I'm curious how they handle RemoteFX and other proprietary extensions that often require licensing. Would be great to see this become a solid foundation for cross-platform RDP implementations that don't rely on the official Microsoft stack.
This is great. I'll have to look into spinning up a client for out of support Mac OS editions via macports -- the last version of the official client sometimes crashes eating up GB of RAM.
I also would like to integrate smart card support into the client instead of passing through the hardware to the host... entering PINs through the normal remote UI always gives me the heebie-jeebies.
My apologies for the name choice, I actually didn't know "Iron" was taken for a lot of C#/.NET projects. We were looking for something that meant "hardened" because it's written in Rust, and went for "IronRDP". This being said, we're generating .NET bindings to IronRDP which we use in Remote Desktop Manager.
Which good free open source alternatives for remote desktop on win 11 are there where you can install both a server ()for win11 home that have the rdp server) and have a client you connect with? Knows only about VNC, but never liked it? And ironrdp just looks like the client. Whant to selfhost the server.
It's instructions for the Windows RDP server to enable RemoteFX support so that the Rust client can make use of it.
Maybe I'm missing something, but for the server side it's only crates that help you build your own server, no direct integration with any system, be it Windows or otherwise.
Wow! It would be amazing if this also supported high performance streaming codecs for local game streaming as the latency/fps of RDP is too low for that - though its ergonomics are unmatched (screen resolution, resizing, etc).
As someone in this thread already stated, if you want smooth remote desktop experience with security requirements, you may try sunshine + moonlight for streaming with tailscale / zerotier for connection.
It's unfortunate Ubuntu doesn't enable that by default. I'd compile the software myself, but for daemons like RDP I'd rather receive regular security updates...
Look into installing xorgxrdp-glamor and openh264. I have zero issues in Fedora, at least, and most of my Debian machines (even ARM) have equivalent packages (although sometimes without full acceleration).
I swear it's forbidden by the language licensing to write any novel software with it. Actually I'm also pretty sure it disproves writing software by oneself in favor of asking others to (re)write their software in it.
It's nearly impossible to have an idea that is truly novel and has no prior art. Even if it isn't the exact same thing, you can see the ideas that inspired this one. All of us are standing on the shoulders of giants all the time.
But you've missed a couple of reasons why Rust rewrites are popular. Rewriting in Rust is proven path to better performance (Python codebases pandas -> polars, black -> ruff) or better security. C/C++ codebases like FreeType being rewritten in Rust for security (https://developer.chrome.com/blog/memory-safety-fonts). What should people looking for performance or security do to mollify you?
You are asking why aren't completely new ideas being implemented in Rust? They are. Check out https://rerun.io. I could be mistaken, but I haven't seen anything similar to rerun. And that was implemented in Rust. Maybe these aren't visible because there genuinely are so few things that are completely novel.
This isn't a public project to write an open source Rust RDP client, it's the result of a company selling cloud software open sourcing their RDP stack. It stands to reason that things like comments and documentation aren't as extensive, because the goal isn't to attract maintainers per se, but to provide context to employees working on the code. I find the READMEs to be more than informational enough for that purpose.
The RDP implementations I've seen are in unsafe languages like C. With the history of memory exploits in RDP (targeting both servers and clients), I think RDP code written in a language where memory bugs don't immediately lead to security issues are an advantage here.
The code also readily compiles to WASM and can be used from within a web browser, which isn't as easy when you need to bundle all the dependencies for a project like freerdp.
As for the comments, they're not great, but the style isn't that uncommon. Documentation is rarely written to explain the program to you, most developers I know write comments to explain the things that may not necessarily be clear by code alone. The expectation for most software developers is that you're ready to read the code if the docs aren't clear immediately. I much prefer extensive documentation, but I have to admit that I've run into issues more than once because nobody bothered to update the extensive documentation above a function after several changes, leading to inconsistent behaviour. A failure of the code review process for sure, but these things happen in software projects, unfortunately.
In my experience these are often generated by IDEs, AI or, the result of including comment coverage in KPIs. They can sometimes be useful, though, like when you write a Rust function declaration with lifetimes and generic types, where notation becomes quite difficult to read.
I wonder if that comment is a result of vibe coding. LLMs often fill their code with comments that restate the literal behavior of a line of code rather than explaining it in a way that adds value.
"I shouldn't have to read code to understand comments"
That's fair, but that's not universally agreed. Some say comment the "why" not the "what" because you can always read the code to understand the what. Also, code will likely be more correct than the comments if code is modified, and the comment isn't. And finally an entirely different school of thought is that you don't need comments if you name your functions right, breaking every few lines, the thing you would have otherwise commented on, into its own function with a good name.
I think all of these are good suggestions to some degree. I'm somewhere in between, leaning toward more comments to help the AI
I read some of your repo. You write a lot of comments. Your response also describes reasons why I avoid reading comments. I think your preference comes off as an attack on different approaches. I attempt to code so clearly that I do not need to document as the code is self documenting. And the code you're talking about is probably AI written. I don't let AI comment on my code unless told to.
Even more precisely would be that it's a requirement for the default rustls backed on some platforms for some features. aws-lc-rs is a pain, but fortunately ring is just a feature flag away.
Sorry, it's not the point of what you were saying. You can tell I've been stung supporting users with this.
"With a focus on security" was the punchline and i had to smile.
While i encourage the great intention and the work that has been done, it seems an oxymoron to create a secure client to connect to unsecure clients.
I will never forget that blazing speed of the BlazeRDP-implemetation that i used in the past that is now long forgotten. I never saw such an speed-optimized RDPish implementation. I knew i was connecting to unsecure clients and used a propietary fix to a MS-based protocol, but it was insanely fast. I never had such a fast remotedesktop since then regardless of the OS. This is not an ad, i'm not affiliated, it's simply a fact in my life, that i recall.
And i forgot to mention something: the mobile client was also the best that i ever used, too. Absolutely intuitive back in the days - but i don't know how it is today. But i expect it to be even better, not degraded.
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.
> 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.
> 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).
I'm not exaggerating at all. I regularly play Overwatch over this setup and it's totally fine.
It can be unnoticeable for you, while being noticeable for others.
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.
[1] https://github.com/ClassicOldSong/Apollo
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.
That requires remoteapp I believe, not regular remote 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.
can you elaborate? I'd assume games have a higher requirement on responsiveness than dev tasks?
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.
If you got remoteFX on RDP working, would the difference be that large for gaming?
One feature I really want is clipboard sharing that works as well as it does on RDP/Parsec.
You could try Barrier (formerly Synergy) for input and clipboard. I found that it's really good latency-wise on 100MBit+ LAN.
Synergy still exists, but barrier has forked again to input-leap.
Oh, thanks for the info.
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.
[0]: RDP without the risk: Cloudflare's browser-based solution for secure third-party access https://blog.cloudflare.com/browser-based-rdp/
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.
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.
Do you think it's good enough for "business"? I pay too much for screenconnect and absolutely hate it, but it does usually just work.
100%! I was using Teamviewer but got frustrated by their licencing. RustDesk is excellent, works on mobile too. No affiliation just a happy user...
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.
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.
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.
[1]: https://techcommunity.microsoft.com/blog/microsoft-security-...
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!
> you aren't getting to use your remote GPU through it.
Um yes you are? I use AutoCAD and other software using GPU all the time over rdp
I've had issues with some software & games not being able to get a proper display context and refusing to start.
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.
> that authentication is the usual MS mess
You mean seamless integration with AD and supports smart cards?
> makes me wish they just went with SSH as transport protocol.
RDP predates OpenSSH by a year.
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
RDP is based on Citrix ICA which builds on Citrix Multiuser released in 1991 for OS/2, and 1992 for DOS, 1993 for Windows.
https://www.basvankaam.com/2017/03/29/a-lesson-in-history-th...
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.
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
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.
You can set up RD Gateway to leverage MFA.
https://learn.microsoft.com/en-us/entra/identity/authenticat...
That’s why you have an vpn or the rdp gateway instead of exposing the machines directly to internet.
Iirc you can enable Remote Desktop and block public access and connect over an SSH tunnel. Newer versions of Windows include an SSH server.
> lacks features like tunneling
TCL over RDP is technically barely possible with a ridiculously custom client and a server-side stub:
https://rdp2tcp.sourceforge.net/
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.
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.
Weren't there any other solutions? (Searching ...) Norton? Citrix? VNC?
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.
Windows does support SSH now, so maybe you could rig RDP-over-SSH yourself with port forwarding.
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.
Right, but while I know a lot about Kerberos I know very little about AVD. Does Microsoft expose an HTTPS proxy for the KDCs?
You need to deploy the KDC proxy yourself, and then add it to the .RDP file options in your AVD feed. It's not something that works out of the box: https://learn.microsoft.com/en-us/azure/virtual-desktop/key-...
Aha. Thanks!
Here's RDP over ssh, per one commenter:
https://news.ycombinator.com/item?id=43441584
RD Gateway leverages SSL for encrypted transport for RDP between client and host. Maybe it is possible :-)
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.
> The performance is just insanely good,
It's still artificially capped to a really awkward framerate (maybe 24fps or ~32fps?), even today.
You can set that to 60fps - https://taoofmac.com/space/protocols/rdp
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...
And they claim patent protection on it. You have to buy a license for Microsoft.
Still?
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.
If you are connecting to an RDS host, you need a CAL.
https://github.com/MicrosoftDocs/windowsserverdocs/blob/main...
Not to connect to a regular computer. That is only for connecting to a terminal server.
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.
"should be" is fine, right until Microsoft's lawyers show up at your door and you get to hire representation to defend yourself.
I’m really baffled as to why anybody would downvote this comment, anyone want to explain?
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.
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...
Anytime there's a timeout the Microsoft RDP client makes you wait way longer than you might have had to otherwise. That kills me.
Yeah. I usually just close the client and reconnect that way instead of waiting for it to auto reconnect.
I get the whole Rust -> Iron thing, but when I see Iron prefix I think of dotnet because of https://github.com/ironlanguages and https://ironsoftware.com/
I think of IronPython and IronRuby and IronScheme, early attempts at Microsoft trying to combine cornmeal with .NET and open source and calling it a burrito.
https://ironpython.net/
https://en.wikipedia.org/wiki/IronRuby
https://en.wikipedia.org/wiki/IronScheme
Iron Icons comes to mind as well
https://www.webcomponents.org/element/@polymer/iron-icons
yep, that's my first link
Given that it's an implementation of Microsoft's RDP, not sure that's a "but" in this very specific case =)
That was my first thought as well. Surprised to see they're still seeing updates. Also surprised to never see an IronJS or IronTypescript or similar really.
It be weird to see MS make an IronTypescript given that they created typescript.
TypeScript as it exists from Microsoft isn't a runtime engine.
Wouldn't that be IronNode, then? Especially now that node-ts is a thing
Early .NET (pre-4.0) included JScript.NET, which was effectively "IronJS", except that it predated the convention.
Iron* is based on dynamic language support... JScript.Net wasn't and was abandoned well before.
Is it feature-complete with RDP and then some? As someone who has spent, over the last ~15 years, probably equal amount of screen time on RDP vs local (even in the office it's usually RDP to a blade, and at home a laptop to a powerful workstation; with remote work recently it's so much more and often nested), and someone who tried Linux on Desktop regularly and gave up because of inferior RDP alternatives (even GNONE 47 is a joke for RDP, but getting closer), - I learned to appreciate all the tiny details that make the RDP proper great.
The demo in the README is pretty impressive for an independent implementation, but I also noticed the repo includes server code (https://github.com/Devolutions/IronRDP/tree/master/crates/ir...). I wonder if tools like Proxmox could use this as a more efficient alternative to VNC (which is slow and weird) or SPICE (for which there are very few non-Linux tools).
> I wonder if tools like Proxmox could use this as a more efficient alternative to VNC (which is slow and weird) or SPICE (for which there are very few non-Linux tools).
Yeah, we at Proxmox are actually evaluating such things, and we hope that IronRDP and QEMU display [0] can be part of a stack that replaces SPICE in the long term, but it will need a bit more time to see how this play out and what exact role it can play in Proxmox VE.
Another experiment is to see if we can add a more modern video encoding to QEMU, as the recently released noVNC 1.6 gained support for H.264 [1]; albeit we naturally would prefer something more open like AV1.
[0]: https://gitlab.com/marcandre.lureau/qemu-display/
[1]: https://github.com/novnc/noVNC/releases/tag/v1.6.0
We would be very happy if proxmox were to adopt IronRDP. I see you've already found the work from Marc-André Lureau, he's been doing an incredible job for the IronRDP server side. He's also been working on adding QOI image codec in IronRDP with incredible results. You're welcome to pop in the IronRDP matrix channel: https://matrix.to/#/!opeocvkWZVaLDouykU:matrix.org?via=matri...
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.
Compute overhead of H.264 encoder is non-negligible for a VM host where I want all my CPU cycles to go to user VMs. Datacenter-class Intel CPUs (Xeon) don't include H.264 encoders in hardware. QuickSync circuitry is generally limited to consumer-grade CPUs. Not to mention MPEG licensing issues.
AV1 eliminates MPEG licensing issues, but encoding in hardware is even more limited. Also, AV1 is great for encode-once use cases (e.g. YouTube) since it's heavily geared towards reducing bandwidth requirements vs. encode speed. It's workable for real-time streaming in the lowest settings, but H.264 is still better overall.
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?
> "need a bit more time to see how this play out and what exact role it can play in Proxmox VE."
It's been around for six years?
Seems like enough to say "let's try it out, see how things go, I bet if we start working with it, things will accelerate rapidly" to me.
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.
Part of what makes RDP performant compared to VNC is that the RDP server is aware of the GUI state and a lot of compositing is actually done by the client.
A hypervisor just sees the video output from the VM and has no knowledge of the underlying GUI's state, so even with RDP it won't be able to do much better than stream compressed bitmaps.
You're right, but that's why SPICE has a so-called Agent that runs inside the guest and provides a neater integration (like seamless switching from client to host, ad-hoc USB passthrough, sharing the clipboard, detecting video streams (theoretically), ...) and that would be also an option for an RDP approach.
True, but that also goes for VNC (though VNC isn't as optimised as RDP is).
Modern RDP also has the option to turn (parts of) the screen into a simple h.264 stream so the connection doesn't die when you open up a web page with an animated background.
Seems like what we need is a specialized compression algorithm. Since the domain is largely constrained it sure seems like there's some low-hanging fruit here.
VNC with compression does already exist in the form of TightVNC[0].
[0]https://en.wikipedia.org/wiki/TightVNC#Encodings
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).
RDP is aimed at a different use case than VNC. Proxmox and other virtualization managers (e.g. VMWare, Nutanix) use VNC because you get a stream directly from the hypervisor (e.g. KVM, ESX) which is very useful for low-level debugging. The VNC protocol also has very low overhead (you don't really want h264 encoding CPU overhead on your VM host). VNC is not really intended for remote desktop use cases, which require higher fidelity/frame rate, etc.
So -
* VNC: Low overhead / Low fidelity
* RDP (and other remote desktop protocols, e.g. Frame Remoting Protocol, Horizon Blast, Citrix ICA/HDX): Higher overhead / High fidelity
What qualifies as "low" overhead?
RDP will run without issue over a 56k modem in a low color mode to an RDP Host.
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.)
That might practically be where VNC finds usage today, but when it was introduced in the 90s, remote desktops were the intended use case.
"In the virtual network computing (VNC) system, server machines supply not only applications and data but also an entire desktop environment that can be accessed from any Internet-connected machine using a simple software NC." -- https://www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/at... (1998)
Given the CPU load I've witnessed on VNC servers, I don't think "low overhead" is right these days.
VNC was designed for remote desktop use. All the other streaming features came along later. I don't see why RDP would make for a worse choice here, other than that Windows VM integration would make for an better solution.
RDP used to be far inferior because it was proprietary Microsoft stuff with buggy open source clients and undocumented servers that kept changing stuff around. These days, open source RDP server software is actually quite solid. I don't know if Gnome/KDE leverage the partial update mechanism that makes RDP so useful on Windows (doesn't seem to seeing the performance I'm getting out of VMs), but I find RDP to be a lot more useful for interactive desktop streams than VNC.
> 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?
Also note that there is a critical difference in how they talk to the OS:
* VNC (and other non-RDP solutions like TeamViewer etc): fully independent application, does not change how Windows works because it's effectively just an interactive screen recorder running for your user account.
* RDP: is an actual Windows remote user session that hijacks the computer (so a local user can't see what's happening) and hooks directly into Windows with its own device bindings and login properties (e.g, you can't just click start -> shut down, instead you need to command-line your way to victory).
If you want to remote into a machine that's playing audio without interfering with that, RDP is flat out not an option. Even if you pick "leave audio on the remote", the fact that RPD forces windows to use a different audio device is enough to interfere with playback.
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.
Right, so, RDP by the people who invented it =)
And it is superbly performant if you use xorgxrdp-glamor for rendering and openh264 for transport.
Fedora recently ditched VNC support in their installer for RDP. https://docs.fedoraproject.org/en-US/fedora-server/installat... (which may be a Wayland think, I just know more about Fedora than general Linux distros).
RDP seems to have taken the zeitgeist in the open source world.
It is a lot more advanced than VNC, and the open source world doesn't seem to have come up with any alternatives.
I don't quite understand what happened to SPICE. I know Red Hat deprecated it, and I can't tell if it was ever fully opensourced or not?
https://www.spice-space.org/developers.html
My theory is Wayland happened. As SPICE doesn't work that well through it. I would assume it's another case of a "niche" the Wayland protocol didn't account for, however.
Wayland. Move slow and break everything.
Interesting theory. Any idea on why SPICE wouldn't work well through it? I don't have recall running into any issues with it.
A more Wayland-oriented remote desktop protocol would probably make for an even better VNC alternative, but I don't really know why SPICE never got the uptake it deserved.
Wasn't aware SPICE was deprecated. However, I think it addresses a different use-case than RDP: SPICE is primarily designed for accessing virtual machines by connecting to their hypervisor. Thus it's designed to operate without VM guest awareness nor cooperation, going purely from a framebuffer.
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.
RustDesk is intended to be a TeamViewer alternative but works quite well as a simple remote desktop application:
https://github.com/rustdesk/rustdesk
I thought to have seen some negative comments about its security, anyone knowing more about it?
They installed a root certificate on windows computers that could have been used to MITM all traffic.
I personally had issues with the project years before that when I tried to install their Linux .deb and they ran `pip install` as root in the pre install script inside the .deb. That caused so much havoc to clean up I was pissed at them for years. Now that idiocy is blocked by default in current versions of pip.
Yeah it just seemed like a slightly suss project to me. I did use it initially but uninstalled it after the Chinese root certificate incident.
I wonder if anyone has forked it...
I haven't heard anything negative about it, and I can only find one CVE:
https://www.cvedetails.com/cve/CVE-2024-25140/
Personally, I'm not exposing my installations to the Internet, so I feel relatively secure regardless.
This probably has something to do with Gnome on Wayland having RDP server support as a standard feature:
https://gitlab.gnome.org/GNOME/gnome-remote-desktop
I thought RDP is highly coupled with GDI. How could it translate native wayland to GDI?
The RDP GDI messages are from RDP6, graphical messages have changed many times over in the versions of RDP that followed. Would you be surprised to learn that WSLg uses a FreeRDP server hooked to a Wayland compositor running in the Linux guest, and that the RDP client in the Windows host is MSRDC in a special RemoteApp mode? In theory someone could build a similar RDP server using IronRDP
That is one of the extensions, in theory others could be built. RemoteFX is an extension as is the (more normal today) Desktop Composition Extension.
https://learn.microsoft.com/en-us/openspecs/windows_protocol...
The Desktop Composition extension was never used in practice, check the date on the spec - the last update was in 2017. I don't know the whole story behind the scenes but the feature got pulled early.
Possibly a patent threat.
Well, I personally never had any issues with X11vnc ever since its existence. I have used it a long time ago though.
Probably coincidentally, in a blog post today, Cloudflare announced clientless, browser-based support for RDP. It seems they're using IronRDP under the hood.
https://blog.cloudflare.com/browser-based-rdp/
Cloudflare person who did some of the very early prototyping on this. I posted about our use of IronRDP here.
https://news.ycombinator.com/item?id=43441709
I would strongly recommend IronRDP, excellent open source project.
I love RDP! It really is an impressive technology. I work in-office somewhere, and when I'm on campus, RDPing into my desk laptop from a conference room client has native performance, with audio even.
What is the best remote desktop server for Linux?
Does this implement a server? or client only? Linux?
This code seems to be part of some kind of cloud offering for enterprise cloud environments. A lot of RDP code seems to concentrate on a React component for connecting to an RDP server.
Edit: I've juist built the code on Linux and the demo video is recorded on Windows, so this seems multi-platform. There's also code for a .NET client in Avalonia (a cross-platform GUI library) so I'm guessing the entire thing should work on any modern OS.
There's a basic skeleton for an RDP server in the code, but the README is a bit short.
> React component
> code for a .NET client in Avalonia
So is this written in Rust or not ?
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.
Just a quick note from somebody who's been tinkering with RDP: RDP is so much more than remote desktop, and this ironrdp thing looks cool but is also severely limited.
xrdp supports forwarding audio (playback and microphone forwarding, both ways) as well as local folder forwarding. And I think i also got webcam working (webcam on my laptop forwarded to the browser running on the remote host).
for reference: https://www.xrdp.org/
I hope this implementation gets to a maturity level to make it actually usable for realistic remote desktop usage :)
Does someone know why folder forwarding is so slow? Browsing forwarded directories is not production ready at all! (I'm not talking about xrdp, but the original RDP.) Even SMB2 over WAN is faster. If a program has a deep link and has to process one file, ok. Everything above that and it turns into a waiting game.
Do you know a good client on linux with Wayland support? I have artefacts with all clients I tried.
RDP has a huge array of features. It can be everything from server side rendered and just sending a video stream over the network to client side rendered and sending openGL commands over the network.
There is a massive difference between a basic implementation that works and a fully featured implementation which works reasonably over a 56k modem.
Interesting to see a Rust implementation of RDP. The protocol has a lot of quirks and edge cases that make it challenging to implement correctly, especially around authentication and session management. The focus on security is good, but I'm curious how they handle RemoteFX and other proprietary extensions that often require licensing. Would be great to see this become a solid foundation for cross-platform RDP implementations that don't rely on the official Microsoft stack.
This is great. I'll have to look into spinning up a client for out of support Mac OS editions via macports -- the last version of the official client sometimes crashes eating up GB of RAM.
I also would like to integrate smart card support into the client instead of passing through the hardware to the host... entering PINs through the normal remote UI always gives me the heebie-jeebies.
Remotefx is a really big feature addition.
I still think modern alternatives like parsec are better in almost every regard but RDP is extremely mature.
That's...a confusing name.
Given that IronPDF, IronXL, IronQR, IronBarcode, IronZIP, IronPPT, IronRuby are written in C#/.NET.
My apologies for the name choice, I actually didn't know "Iron" was taken for a lot of C#/.NET projects. We were looking for something that meant "hardened" because it's written in Rust, and went for "IronRDP". This being said, we're generating .NET bindings to IronRDP which we use in Remote Desktop Manager.
> We were looking for something that meant "hardened" because it's written in Rust, and went for "IronRDP"
Hardened means hardened, hope that helps.
Which good free open source alternatives for remote desktop on win 11 are there where you can install both a server ()for win11 home that have the rdp server) and have a client you connect with? Knows only about VNC, but never liked it? And ironrdp just looks like the client. Whant to selfhost the server.
Chrome remote desktop for over internet and sunshine/moonlight for local lan
I bought sketchy Serial number upgrade go windows 11 pro to solve that
Based on what I see under https://github.com/Devolutions/IronRDP?tab=readme-ov-file#ho...
it seems like the server part is Windows only?
It's instructions for the Windows RDP server to enable RemoteFX support so that the Rust client can make use of it.
Maybe I'm missing something, but for the server side it's only crates that help you build your own server, no direct integration with any system, be it Windows or otherwise.
Ok, so there is a server for Linux as well?
Wow! It would be amazing if this also supported high performance streaming codecs for local game streaming as the latency/fps of RDP is too low for that - though its ergonomics are unmatched (screen resolution, resizing, etc).
Just a random note.
As someone in this thread already stated, if you want smooth remote desktop experience with security requirements, you may try sunshine + moonlight for streaming with tailscale / zerotier for connection.
What would you use to Remote Desktop between 2 mac without latency?
I tried several tools but it was lagging (screen sharing, vnc, spashtop, anydesk, …)
Native screen sharing with the high performance* feature works great for me. (requires the native client to work)
*[https://support.apple.com/en-gb/guide/remote-desktop/apdf8e0...]
Ah thanks. I missed that part. Will give it a try!
I’m using kasm/webtop containers to work remotely via the browser. Is there something similar using rdp/ironrdp?
Ooh.. if this could support GfxRedir, then it could open up various interesting virtualisation things.
Is this available for Linux? Linux desperately needs RDP. Any Linux distros with RDP built-in?
Yes, Gnome on Ubuntu and Debian has had a built in rdp server for the last several releases: settings -> sharing -> Remote Desktop -> on
For some reason the performance with those is never on par with windows RDP, it feels a lot more like VNC.
Look into installing xorgxrdp-glamor and openh264.
It's unfortunate Ubuntu doesn't enable that by default. I'd compile the software myself, but for daemons like RDP I'd rather receive regular security updates...
XRDP? Only real problem I know of there is it doesn't support Wayland.
Look into installing xorgxrdp-glamor and openh264. I have zero issues in Fedora, at least, and most of my Debian machines (even ARM) have equivalent packages (although sometimes without full acceleration).
How does it compare to freerdp feature wise?
Remote Desktop Protocol protocol
That is mighty impressive. Thank you for sharing!
[dead]
[flagged]
Given the number of devastating memory unsafety issues we've seen in RDP, I kinda welcome this effort.
Let's see more $foo implemented in rust.
I swear it's forbidden by the language licensing to write any novel software with it. Actually I'm also pretty sure it disproves writing software by oneself in favor of asking others to (re)write their software in it.
It's nearly impossible to have an idea that is truly novel and has no prior art. Even if it isn't the exact same thing, you can see the ideas that inspired this one. All of us are standing on the shoulders of giants all the time.
But you've missed a couple of reasons why Rust rewrites are popular. Rewriting in Rust is proven path to better performance (Python codebases pandas -> polars, black -> ruff) or better security. C/C++ codebases like FreeType being rewritten in Rust for security (https://developer.chrome.com/blog/memory-safety-fonts). What should people looking for performance or security do to mollify you?
You are asking why aren't completely new ideas being implemented in Rust? They are. Check out https://rerun.io. I could be mistaken, but I haven't seen anything similar to rerun. And that was implemented in Rust. Maybe these aren't visible because there genuinely are so few things that are completely novel.
yet another complaint for no good reason
They were annoyed by something, and made a post about it. Aren't you doing the same?
[flagged]
This isn't a public project to write an open source Rust RDP client, it's the result of a company selling cloud software open sourcing their RDP stack. It stands to reason that things like comments and documentation aren't as extensive, because the goal isn't to attract maintainers per se, but to provide context to employees working on the code. I find the READMEs to be more than informational enough for that purpose.
The RDP implementations I've seen are in unsafe languages like C. With the history of memory exploits in RDP (targeting both servers and clients), I think RDP code written in a language where memory bugs don't immediately lead to security issues are an advantage here.
The code also readily compiles to WASM and can be used from within a web browser, which isn't as easy when you need to bundle all the dependencies for a project like freerdp.
As for the comments, they're not great, but the style isn't that uncommon. Documentation is rarely written to explain the program to you, most developers I know write comments to explain the things that may not necessarily be clear by code alone. The expectation for most software developers is that you're ready to read the code if the docs aren't clear immediately. I much prefer extensive documentation, but I have to admit that I've run into issues more than once because nobody bothered to update the extensive documentation above a function after several changes, leading to inconsistent behaviour. A failure of the code review process for sure, but these things happen in software projects, unfortunately.
In my experience these are often generated by IDEs, AI or, the result of including comment coverage in KPIs. They can sometimes be useful, though, like when you write a Rust function declaration with lifetimes and generic types, where notation becomes quite difficult to read.
I wonder if that comment is a result of vibe coding. LLMs often fill their code with comments that restate the literal behavior of a line of code rather than explaining it in a way that adds value.
"I shouldn't have to read code to understand comments"
That's fair, but that's not universally agreed. Some say comment the "why" not the "what" because you can always read the code to understand the what. Also, code will likely be more correct than the comments if code is modified, and the comment isn't. And finally an entirely different school of thought is that you don't need comments if you name your functions right, breaking every few lines, the thing you would have otherwise commented on, into its own function with a good name.
I think all of these are good suggestions to some degree. I'm somewhere in between, leaning toward more comments to help the AI
"I read comments to understand code"
I read some of your repo. You write a lot of comments. Your response also describes reasons why I avoid reading comments. I think your preference comes off as an attack on different approaches. I attempt to code so clearly that I do not need to document as the code is self documenting. And the code you're talking about is probably AI written. I don't let AI comment on my code unless told to.
fyi your website is down or too slow.
Three slashes makes it a doc comment, just so it shows up nicely here https://docs.rs/ironrdp/latest/ironrdp/core/struct.WriteBuf....
It being FOSS means you can fork and customize it.
Maybe instead use it as a headless automation tool.
amazizng
cannot build for windows ironically
https://github.com/Devolutions/IronRDP/issues/709
IRONically, hehe
The error says cmake is missing, not that it doesn't build on Windows.
Just what I want, a C requirement for a Rust project
Sounds like it's not your Rust project.
But cmake is required by Rustls (or more precisely, aws-lc-rs).
Even more precisely would be that it's a requirement for the default rustls backed on some platforms for some features. aws-lc-rs is a pain, but fortunately ring is just a feature flag away.
Sorry, it's not the point of what you were saying. You can tell I've been stung supporting users with this.
"With a focus on security" was the punchline and i had to smile.
While i encourage the great intention and the work that has been done, it seems an oxymoron to create a secure client to connect to unsecure clients.
I will never forget that blazing speed of the BlazeRDP-implemetation that i used in the past that is now long forgotten. I never saw such an speed-optimized RDPish implementation. I knew i was connecting to unsecure clients and used a propietary fix to a MS-based protocol, but it was insanely fast. I never had such a fast remotedesktop since then regardless of the OS. This is not an ad, i'm not affiliated, it's simply a fact in my life, that i recall.
Any links to share? I don't care about security for my use case.
And i forgot to mention something: the mobile client was also the best that i ever used, too. Absolutely intuitive back in the days - but i don't know how it is today. But i expect it to be even better, not degraded.
https://sc.ericom.com/ericom-blaze/
> 1. Julia has two sisters. That means there are three girls in total (Julia + two more).
False. Julie could be the name of a boy.
> 2. Julia also has one brother, named Martin.
OK
> 3. Altogether, there are four siblings: three girls and one boy (Martin).
Where did you identify the third girl?
> 4. From Martin’s perspective, his sisters are all three of the girls (Julia and her two sisters).
Here's where the answer comes from (Julia and her two sisters).
More directly: "How many sisters does her brother Martin have?"
> 5. Therefore, Martin has three sisters.
OK.
So the reasoning might have come to the "right" answer but the way it arrived at the answer was incorrect.
(derp, I just now realized this is in the wrong post and meant to post it here https://news.ycombinator.com/item?id=43439186 )