[HN Gopher] IronRDP: a Rust implementation of Microsoft's RDP pr...
___________________________________________________________________
IronRDP: a Rust implementation of Microsoft's RDP protocol
Author : mikece
Score : 511 points
Date : 2025-03-21 15:35 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| geenat wrote:
| Does this implement a server? or client only? Linux?
| jeroenhd wrote:
| 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.
| hulitu wrote:
| > React component
|
| > code for a .NET client in Avalonia
|
| So is this written in Rust or not ?
| steveklabnik wrote:
| Github's languages analysis says 87.7% Rust, 9.3% C#, 1.3%
| TypeScript.
| awakecoding wrote:
| 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.
| jeroenhd wrote:
| 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).
| rcarmo wrote:
| And it is superbly performant if you use xorgxrdp-glamor for
| rendering and openh264 for transport.
| Nextgrid wrote:
| 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.
| generalizations wrote:
| 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.
| nix0n wrote:
| VNC with compression does already exist in the form of
| TightVNC[0].
|
| [0]https://en.wikipedia.org/wiki/TightVNC#Encodings
| nemanja wrote:
| 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).
| jeroenhd wrote:
| 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.
| tlamponi wrote:
| 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.
| nemanja wrote:
| 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
| TheRealPomax wrote:
| 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.
| jeroenhd wrote:
| 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.
| TheRealPomax wrote:
| Right, so, RDP _by the people who invented it_ =)
| p_ing wrote:
| What qualifies as "low" overhead?
|
| RDP will run without issue over a 56k modem in a low color
| mode to an RDP Host.
| nemanja wrote:
| 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.)
| andrewf wrote:
| 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." -- ht
| tps://www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/at...
| (1998)
| jeroenhd wrote:
| 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.
| RossBencina wrote:
| > 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?
| tlamponi wrote:
| > 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
| nemanja wrote:
| 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.
| concerndc1tizen wrote:
| 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?
| tlamponi wrote:
| 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.
| KennyBlanken wrote:
| > "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.
| tlamponi wrote:
| 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.
| awakecoding wrote:
| We would be very happy if proxmox were to adopt IronRDP. I
| see you've already found the work from Marc-Andre 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/#/!opeocvkWZVaLDouy
| kU:matrix.org?via=matri...
| tlamponi wrote:
| 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.
| kayson wrote:
| 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...
| DaiPlusPlus wrote:
| > The performance is just insanely good,
|
| It's still artificially capped to a really awkward framerate
| (maybe 24fps or ~32fps?), even today.
| rcarmo wrote:
| You can set that to 60fps -
| https://taoofmac.com/space/protocols/rdp
| DaiPlusPlus wrote:
| 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...
| sitkack wrote:
| And they claim patent protection on it. You have to buy a
| license for Microsoft.
| IcyWindows wrote:
| Still?
| tracker1 wrote:
| 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.
| bee_rider wrote:
| I'm really baffled as to why anybody would downvote this
| comment, anyone want to explain?
| iforgotpassword wrote:
| 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.
| inversetelecine wrote:
| 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.
| sitkack wrote:
| If you are connecting to an RDS host, you need a CAL.
|
| https://github.com/MicrosoftDocs/windowsserverdocs/blob/m
| ain...
| IcyWindows wrote:
| Not to connect to a regular computer. That is only for
| connecting to a terminal server.
| trelane wrote:
| "should be" is fine, right until Microsoft's lawyers show
| up at your door and you get to hire representation to
| defend yourself.
| sitkack wrote:
| 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.
| qsort wrote:
| 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.
| tomjakubowski wrote:
| Windows does support SSH now, so maybe you could rig RDP-
| over-SSH yourself with port forwarding.
| p_ing wrote:
| RD Gateway leverages SSL for encrypted transport for RDP
| between client and host. Maybe it is possible :-)
| chupasaurus wrote:
| 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.
| awakecoding wrote:
| 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/
| cryptonector wrote:
| 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.
| awakecoding wrote:
| 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.
| cryptonector wrote:
| Right, but while I know a lot about Kerberos I know very
| little about AVD. Does Microsoft expose an HTTPS proxy
| for the KDCs?
| awakecoding wrote:
| 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-...
| mmooss wrote:
| Here's RDP over ssh, per one commenter:
|
| https://news.ycombinator.com/item?id=43441584
| password4321 wrote:
| > _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/
| Joe_Cool wrote:
| 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.
| donnachangstein wrote:
| > 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.
| Fidelix wrote:
| According to Wikipedia, RDP = June 16, 1998 SSH = 1995.
| OpenSSH = 1999
| p_ing wrote:
| 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.
| KennyBlanken wrote:
| 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_
| joking wrote:
| That's why you have an vpn or the rdp gateway instead of
| exposing the machines directly to internet.
| Nextgrid wrote:
| 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.
| p_ing wrote:
| You can set up RD Gateway to leverage MFA.
|
| https://learn.microsoft.com/en-
| us/entra/identity/authenticat...
| nijave wrote:
| Iirc you can enable Remote Desktop and block public
| access and connect over an SSH tunnel. Newer versions of
| Windows include an SSH server.
| kbenson wrote:
| 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).
| naikrovek wrote:
| 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.
| mmooss wrote:
| Weren't there any other solutions? (Searching ...) Norton?
| Citrix? VNC?
| naikrovek wrote:
| 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.
| spudnik wrote:
| 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.
| stuartd wrote:
| 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!
| SirMaster wrote:
| 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.
| raggles wrote:
| > 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
| vekatimest wrote:
| I've had issues with some software & games not being able
| to get a proper display context and refusing to start.
| raggles wrote:
| 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
| jeroenhd wrote:
| 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.
| SirMaster wrote:
| 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.
| magicalhippo wrote:
| 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-...
| ziml77 wrote:
| 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.
| twooclock wrote:
| 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.
| RockRobotRock wrote:
| 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.
| twooclock wrote:
| 100%! I was using Teamviewer but got frustrated by their
| licencing. RustDesk is excellent, works on mobile too. No
| affiliation just a happy user...
| KronisLV wrote:
| 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!
| wkat4242 wrote:
| 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 :(
| aappleby wrote:
| 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_.
| winkelmann wrote:
| 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.
| wtallis wrote:
| 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.
| gryn wrote:
| 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.
| Hard_Space wrote:
| > 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.
| Hard_Space wrote:
| 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.
| RockRobotRock wrote:
| 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.
| Joe_Cool wrote:
| You could try Barrier (formerly Synergy) for input and
| clipboard. I found that it's really good latency-wise on
| 100MBit+ LAN.
| CUViper wrote:
| Synergy still exists, but barrier has forked again to
| input-leap.
| jwrallie wrote:
| 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.
| bentcorner wrote:
| > 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
| LiamPowell wrote:
| 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.
| gruez wrote:
| That requires remoteapp I believe, not regular remote
| desktop.
| mmerlin wrote:
| 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+
| viraptor wrote:
| 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.
| gruez wrote:
| >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?
| bentcorner wrote:
| 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.
| feldrim wrote:
| 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?
| bentcorner wrote:
| 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.
| deeviant wrote:
| 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.
| jorvi wrote:
| > 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).
| aappleby wrote:
| I'm not exaggerating at all. I regularly play Overwatch
| over this setup and it's totally fine.
| concerndc1tizen wrote:
| It can be unnoticeable for you, while being noticeable
| for others.
| aappleby wrote:
| 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.
| miki123211 wrote:
| 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.
| Melatonic wrote:
| 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.
| eek2121 wrote:
| 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.
| cryptonector wrote:
| Anytime there's a timeout the Microsoft RDP client makes you
| wait way longer than you might have had to otherwise. That
| kills me.
| inversetelecine wrote:
| Yeah. I usually just close the client and reconnect that way
| instead of waiting for it to auto reconnect.
| singhrac wrote:
| 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.
| naikrovek wrote:
| 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.
| awakecoding wrote:
| 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...
| EthanHeilman wrote:
| 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/
| bob1029 wrote:
| 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.
| teleforce wrote:
| 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.
| tomjen3 wrote:
| 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.
| nailer wrote:
| 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.
| IshKebab wrote:
| It is a lot more advanced than VNC, and the open source world
| doesn't seem to have come up with any alternatives.
| InsideOutSanta wrote:
| RustDesk is intended to be a TeamViewer alternative but works
| quite well as a simple remote desktop application:
|
| https://github.com/rustdesk/rustdesk
| raphinou wrote:
| I thought to have seen some negative comments about its
| security, anyone knowing more about it?
| InsideOutSanta wrote:
| 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.
| Arrowmaster wrote:
| 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.
| IshKebab wrote:
| 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...
| rrdharan wrote:
| 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
| spookie wrote:
| 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.
| jeroenhd wrote:
| 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.
| timewizard wrote:
| Wayland. Move slow and break everything.
| Nextgrid wrote:
| 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.
| j16sdiz wrote:
| I thought RDP is highly coupled with GDI. How could it
| translate native wayland to GDI?
| p_ing wrote:
| 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...
| awakecoding wrote:
| 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.
| tracker1 wrote:
| Possibly a patent threat.
| awakecoding wrote:
| 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
| johnisgood wrote:
| Well, I personally never had any issues with X11vnc ever since
| its existence. I have used it a long time ago though.
| int_19h wrote:
| 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
| graynk wrote:
| 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/
| TheRealPomax wrote:
| Given that it's an implementation of Microsoft's RDP, not sure
| that's a "but" in this very specific case =)
| badlibrarian wrote:
| 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
| graynk wrote:
| yep, that's my first link
| SpaceL10n wrote:
| Iron Icons comes to mind as well
|
| https://www.webcomponents.org/element/@polymer/iron-icons
| tracker1 wrote:
| 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.
| snoman wrote:
| It be weird to see MS make an IronTypescript given that they
| created typescript.
| tracker1 wrote:
| TypeScript as it exists from Microsoft isn't a runtime
| engine.
| ffsm8 wrote:
| Wouldn't that be IronNode, then? Especially now that
| node-ts is a thing
| int_19h wrote:
| Early .NET (pre-4.0) included JScript.NET, which was
| effectively "IronJS", except that it predated the convention.
| tracker1 wrote:
| Iron* is based on dynamic language support... JScript.Net
| wasn't and was abandoned well before.
| 38 wrote:
| cannot build for windows ironically
|
| https://github.com/Devolutions/IronRDP/issues/709
| stodor89 wrote:
| IRONically, hehe
| jeroenhd wrote:
| The error says cmake is missing, not that it doesn't build on
| Windows.
| 38 wrote:
| Just what I want, a C requirement for a Rust project
| paulddraper wrote:
| Sounds like it's not your Rust project.
|
| But cmake is required by Rustls (or more precisely, aws-lc-
| rs).
| nsteel wrote:
| 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.
| iJohnDoe wrote:
| Is this available for Linux? Linux desperately needs RDP. Any
| Linux distros with RDP built-in?
| mhurron wrote:
| XRDP? Only real problem I know of there is it doesn't support
| Wayland.
| allanrbo wrote:
| Yes, Gnome on Ubuntu and Debian has had a built in rdp server
| for the last several releases: settings -> sharing -> Remote
| Desktop -> on
| Saris wrote:
| For some reason the performance with those is never on par
| with windows RDP, it feels a lot more like VNC.
| rcarmo wrote:
| Look into installing xorgxrdp-glamor and openh264.
| jeroenhd wrote:
| 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...
| rcarmo wrote:
| 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).
| alexpadula wrote:
| That is mighty impressive. Thank you for sharing!
| shravankumar8 wrote:
| amazizng
| paulddraper wrote:
| That's...a confusing name.
|
| Given that IronPDF, IronXL, IronQR, IronBarcode, IronZIP,
| IronPPT, IronRuby are written in C#/.NET.
| awakecoding wrote:
| 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.
| password4321 wrote:
| 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.
| MasterYoda wrote:
| 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.
| theragra wrote:
| I bought sketchy Serial number upgrade go windows 11 pro to
| solve that
| TiredOfLife wrote:
| Chrome remote desktop for over internet and sunshine/moonlight
| for local lan
| eitland wrote:
| 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?
| seritools wrote:
| 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.
| eitland wrote:
| Ok, so there is a server for Linux as well?
| shmerl wrote:
| How does it compare to freerdp feature wise?
| inetknght wrote:
| > _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.
| inetknght wrote:
| (derp, I just now realized this is in the wrong post and meant
| to post it here https://news.ycombinator.com/item?id=43439186 )
| stuaxo wrote:
| Ooh.. if this could support GfxRedir, then it could open up
| various interesting virtualisation things.
| reneberlin wrote:
| "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.
| Fidelix wrote:
| Any links to share? I don't care about security for my use
| case.
| reneberlin wrote:
| https://sc.ericom.com/ericom-blaze/
| reneberlin wrote:
| 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.
| RandyOrion wrote:
| 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.
| znpy wrote:
| 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 :)
| noAnswer wrote:
| 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.
| gHA5 wrote:
| Remote Desktop Protocol protocol
| buybackoff wrote:
| 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.
| kuon wrote:
| Do you know a good client on linux with Wayland support? I have
| artefacts with all clients I tried.
| jdadj wrote:
| 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/
| EthanHeilman wrote:
| 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.
| lxe wrote:
| 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.
| hackerbrother wrote:
| 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?
| tgtweak wrote:
| 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.
| londons_explore wrote:
| 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.
| apatheticonion wrote:
| 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).
| sushidev wrote:
| I'm using kasm/webtop containers to work remotely via the
| browser. Is there something similar using rdp/ironrdp?
| codecraze wrote:
| 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, ...)
| htk wrote:
| 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...]
| codecraze wrote:
| Ah thanks. I missed that part. Will give it a try!
___________________________________________________________________
(page generated 2025-03-22 23:02 UTC)