IronRDP

IronRDP is a from-scratch Rust implementation of the Microsoft Remote Desktop Protocol (RDP), organized as a workspace of small, focused crates (PDU parsing, connection sequencing, session handling, graphics decoding, clipboard/device redirection, and more). The ironrdp crate itself is a meta/facade crate that re-exports the individual sub-crates behind feature flags, so consumers can pull in exactly the protocol surface they need without depending on a dozen separate crate names.

The project targets security-sensitive environments and is used in production by Devolutions and Teleport to power browser- and native-based RDP clients and gateways. It emphasizes #![no_std]-friendly core crates, fuzzing on protocol decoders, and a strict layered architecture (core primitives, protocol PDUs, connector/session state machines, and I/O adapters) documented in an explicit ARCHITECTURE.md.

What You Get

• A meta crate (ironrdp) that re-exports feature-gated sub-crates (core, pdu, connector, session, acceptor, client, server, cliprdr, graphics, input, and more) so you opt into only what you need.
• PDU parsing/serialization for the RDP wire protocol built as #[no_std]-compatible, fuzzed core crates with strict no-I/O architectural invariants.
• Both client and server building blocks: a connector/acceptor state machine, an async or blocking session driver, and an ironrdp-server crate for building your own RDP host.
• Virtual channel extensions out of the box: clipboard redirection (cliprdr), device redirection (rdpdr), sound (rdpsnd), dynamic virtual channels (dvc), and display control.
• Working example binaries (screenshot, server) and a full ironrdp-viewer/ironrdp-client reference implementation showing how the crates compose into a real client.

Common Use Cases

• Embedding an RDP client into a Rust application (desktop, web-via-WASM, or headless automation) without shelling out to FreeRDP.
• Building a custom RDP gateway or server that terminates RDP sessions and forwards graphics/input over another transport.
• Automating remote-desktop screenshots or input injection for testing, monitoring, or bot-driven workflows.
• Adding remote-desktop connectivity to a remote-access product, similar to how Devolutions and Teleport use it in their own gateways.

Under The Hood

Architecture: IronRDP is organized as a Cargo workspace of dozens of crates under crates/, layered into a “Core Tier” (no-I/O, #[no_std]-friendly, fuzzed primitives like ironrdp-core and ironrdp-pdu), a connector/session tier (ironrdp-connector, ironrdp-acceptor, ironrdp-session) implementing the RDP handshake and session state machines, and an I/O tier (ironrdp-async, ironrdp-blocking, ironrdp-futures) that adapts the state machines to real sockets. The ironrdp crate at crates/ironrdp/src/lib.rs is a pure re-export facade: each optional Cargo feature (core, pdu, connector, session, cliprdr, server, etc.) gates a pub use of the corresponding sub-crate, so the public API surface is effectively the union of the sub-crates a consumer opts into. This is documented explicitly in ARCHITECTURE.md, which enumerates “Architectural Invariants” per tier (e.g., core crates may not perform I/O, must be fuzzed, must avoid non-essential dependencies).

Tech Stack: Rust 2024 edition, MSRV 1.89 pinned via rust-toolchain.toml. The workspace depends on tokio/futures for async I/O adapters, rustls or native-tls as pluggable TLS backends (mutually exclusive features), sspi for NTLM/Kerberos network authentication, and image for the example screenshot output. A web-client directory and TypeScript/Svelte crates (iron-remote-desktop) provide a WASM-based browser client built on the same Rust core, and ffi/ exposes a C-compatible surface for non-Rust consumers.

Code Quality: Sub-crates like ironrdp-pdu carry dense tests.rs modules alongside their protocol structures (session_info, server_license, vc, bitmap, fast_path, surface_commands), and a dedicated fuzz/ directory defines over a dozen fuzz targets (PDU round-trip, bulk compression variants, cliprdr format handling, egfx round-trip) reflecting the project’s stated invariant that core/protocol crates must be fuzzed. release-plz.toml and per-crate CHANGELOG.md files indicate an automated, changelog-driven release process; clippy.toml/rustfmt.toml/typos.toml enforce consistent style workspace-wide.

API Design: The meta-crate pattern (ironrdp::core, ironrdp::connector, ironrdp::session, etc. behind features) keeps the default dependency footprint small (default = ["core", "pdu"]) while letting consumers scale up to a full client or server by enabling more features, avoiding the need to depend on internal crate names directly. This trades a small amount of indirection (features must be discovered) for a single, stable top-level crate name and semver surface, and the two runnable examples (screenshot, server) demonstrate the minimum feature combination needed for common client and server scenarios.