Which features are supported?

[erikschul]

Interesting project, but I'm finding it hard to evaluate what is actually supported.

What platforms do you intend to support?

• browser client (wasm)
• windows
• linux
• macos

Which features?

• clipboard sharing
• audio in/out (low latency and correctly synced to video)
• file sharing (file transfer, or mounting)
• usb sharing (client to server, server to client)
• automatic desktop resolution to match window size
• smooth scrolling with touchpad and mouse wheel
• video playback at 4k60fps
• low bandwidth (e.g. automatic adjustment of quality and fps)
• localhost (ultra high bandwidth)
• webcam sharing
• terminal support (serial)

[CBenoit]

Hi! Thank you for opening this conversation.

We’ve discussed this internally, and we agree that we should document more clearly all this stuff.

The exact feature set varies between platforms and feature flags, and it’s complicated enough that we really need to spell that out somewhere in a clear way.

I’ll try to get something brushed out by the end of the week.

[erikschul]

👍

It helps to know what the project is: features, platforms that are implemented, are being tested against, will be supported, and so on = project scope, project goals, intended direction

and what the project isn't: known anti-features (omissions), known issues (i.e. hard to support because of major challenges)

[erikschul]

Also, regarding my own context: I've been using QEMU and SPICE for years, and it's worked well sometimes, and othertimes it's failed in lots of annoying ways, like having rendering issues, laggy sound, and so on, so I'd argue that the ecosystem really needs a more stable alternative.

[CBenoit]

Thank you for the valuable insight!

By the way, you’ll be happy to learn that @elmarco is working on an alternate QEMU display using IronRDP.
I think we should also add a link to his repository in our README.

[awakecoding]

@erikschul while this project was started primarily with the intent of making web RDP clients possible, the goal is really to have an excellent Rust RDP stack that properly covers the web, desktop and mobile platforms. Server-side and even "proxy-side" usage is encouraged, and we're really glad to have @elmarco to contribute a lot of the server bits.

Now there is what we wish we would have and what we truly have time to focus on depending on our own needs. This is why we welcome community contributions from individuals, but also encourage companies to use it commercially, as building an exhaustive, complete RDP stack with good clients and servers is a major endeavor.

The only non-goal I think we may have is support for ancient versions of RDP. We'd like to focus on protocol support for versions of Windows still actively supported by Microsoft. We still have code for that in FreeRDP and not only it is making the code base messier, those code paths are rarely tested, and often have issues. Protocol features I wish we would never implement in IronRDP include:

• Archaic "standard RDP security" that predates TLS. It's completely broken, insecure, and messy to implement.
• RDP "slow-path PDUs" which have long ago been replaced by "fast-path PDUs", a more compact encoding.

Now if there is a serious contributor who really, really wants to put in the work to support these ancient protocol features and test them, we can change our mind, but I'm crossing fingers we never need to consider it. For really old stuff that's not used in supported versions of Windows, FreeRDP can still do the trick. I'm talking of stuff like Windows XP and Windows Server 2003 here.

[erikschul]

Indeed an important aspect is also what features to reject, to keep the codebase small, maintainable, and testable.

I understand that there's some interest from proxmox in the project, and perhaps also the qemu/spice community?
How does IronRDP compare with spice? Is spice high-performance, low-level, and great for high fps using local sockets, while IronRDP is great for low-fps low-bandwidth scenarios (i.e. traditional remote desktop). How does it perform with remote desktop for browser/video use for example?
One important enterprise application is remote browser VMs that prevent local execution attacks.