feat(server): wire UDP multitransport into ironrdp-server

[Greg Lamberson (glamberson)]

Summary

• Add RdpServerBuilder::with_udp_transport(udp_bind_addr): opt-in, None by default, no behavior change unless called.
• When set (and the security mode is Tls or Hybrid, matching the reference client's Enhanced-Security-only gate), the acceptor offers UDP multitransport, and accept_finalize uses accept_finalize_with_multitransport with a callback that binds a fresh UDP socket per connection, reuses the connection's own TLS certificate (TlsAcceptor::config()) for the sideband transport, and calls accept_udp().
• Once established, the transport is used to migrate EGFX graphics traffic off TCP: request_reliable_udp is called opportunistically the first time EGFX has data to send (its dynamic channel id is only known once the client opens it). From the request on, every server message on that channel goes over the tunnel, starting with the batch that triggered it: the request carries SOFT_SYNC_TCP_FLUSHED and the server MUST keep using the named tunnel immediately after sending it (MS-RDPEDYC 2.2.5.1, 3.3.5.3.1). DRDYNVC replies for a tunneled channel go over the tunnel too, whichever path produced them. A new client_loop select arm feeds incoming tunnel payloads into DrdynvcServer::process_tunnel(); payloads that arrive before the client's Soft-Sync Response are held and processed once it does (3.3.5.3.2), rather than dropped.
• The UDP accept runs as an ordinary tokio::spawn task, so enabling UDP adds no runtime requirement for the caller.
• A failure before EGFX has moved (bind, handshake, TLS, or the tunnel closing) leaves the session on TCP, matching the reference client's posture. Once EGFX is on the tunnel, the tunnel closing ends the connection: Soft-Sync cannot move a channel back to TCP (MS-RDPEDYC 2.2.5.1), and the tunnel lasts as long as the connection (MS-RDPEMT 1.3.3).
• A client that answers the Initiate Multitransport Request with E_ABORT (MS-RDPBCGR 2.2.15.2) has given up on the sideband transport, so the pending UDP accept is stopped as soon as that response arrives, whether during finalization or later on the message channel, instead of holding its socket until the 15 s accept timeout. Windows clients send it about 2.7 s after connecting.
• When the UDP bind address has an unspecified IP, each connection's socket binds to the local address that client reached over TCP instead. A socket bound to the unspecified address replies from whichever address the routing table picks, and on a host with several IPv6 addresses that is not always the one the client sent to: mstsc dropped the replies and gave up with E_ABORT. run() records the address itself; embedders driving run_connection_with pass it with the new RdpServer::set_connection_local_addr.
• A successful Initiate Multitransport Response that arrives after finalization now enables EGFX migration for the rest of the session, provided Soft-Sync was negotiated. mstsc finishes its UDP bootstrap after the TCP finalization (0.87 s later in my test), so migration was previously decided before its response existed and the session never left TCP even with the sideband transport up.
• The EGFX channel is found whichever way it was registered: an embedder that takes a frame handle from its GfxServerFactory registers it as GfxDvcBridge, which the migration lookup did not recognise, so it never sent the Soft-Sync Request. The Soft-Sync Request, the client's response (with the tunnels and channels it accepted) and the switch of EGFX onto UDP are now logged at debug level.

Validation

cargo xtask check fmt/lints/tests/typos/locks all pass, including --features egfx specifically (the new code has real feature-gated branches).

Two tests in ironrdp-testsuite-extra. The first confirms that configuring UDP transport on the server does not disturb a client that never advertises support for it (the common case for any client predating this feature). The second, egfx_moves_onto_the_udp_tunnel_with_soft_sync, drives a real client through connect_finalize_with_multitransport and the full RDPEUDP2 handshake, then checks that the EGFX batch that triggers the Soft-Sync Request goes over the tunnel, that client tunnel data arriving ahead of the Soft-Sync Response is processed, and that the reply to it comes back over the tunnel. The test enables ironrdp-server's egfx feature as a dev-dependency, so the EGFX-over-UDP path is now compiled in CI.

Notes

One thing caught and fixed while implementing this, not left in the diff:

• An early draft discarded the SvcMessage (the SoftSyncRequest PDU) that request_reliable_udp() returns, meaning the server would decide to migrate but never actually tell the client. Fixed to encode and send it over TCP.

[github-actions]

Potential duplicate detected: #1951.

The acceptor portion (MultitransportBootstrapping state, set_multitransport_offer, GCC advertisement, message-channel request, acceptor.rs tests) matches #1951's described content, and the driver matches #1953's accept_finalize_with_multitransport; this cumulative diff duplicates both stacked PRs, closest single match #1951.

Maintainer review is required.

[github-actions]

The acceptor-level multitransport work is sound (state machine, message-channel gating, GCC advertisement, response tolerance, tests), but the runtime integration has three significant defects: EGFX Soft-Sync is initiated without advertising SOFTSYNC_TCP_TO_UDP or awaiting a successful Initiate Multitransport Response (violates MS-RDPEDYC/MS-RDPBCGR), UdpTransportHandle::recv holds the tokio Mutex across the idle await and can deadlock sends, and the finalize handler awaits the full 15s UDP accept inline, stalling the handshake. Also published: the routing gate treats a declining SoftSyncResponse as acceptance, the false one-connection-at-a-time premise under preemption, unconditional UDP dependencies for an opt-in feature, and two minor cleanup/test-duplication items. Two optional compression proposals (defensive finalize guard, folding the bootstrapping state) were rejected.

[github-actions]

PR wires opt-in UDP multitransport through the acceptor (MultitransportBootstrapping state, late-response tolerance, accept_finalize_with_multitransport), a server-side RDPEUDP2+TLS+RDPEMT accept path, and soft-sync-gated EGFX migration, all default-off behind with_udp_transport. The state machine, GCC gating, strict response decoding, and the dvc outgoing-map fix check out. Published: a high-severity silent EGFX black-hole after mid-session tunnel closure (send failures unhandled, no TCP fallback), a migration gate frozen at acceptance that late responses can never enable, an integration test whose scripted client violates the S_OK/SOFTSYNC rule, and low-severity cleanup items (unused accessor, unconditional deps, two duplications). Rejected the speculative auto-detect swallow finding: the response decoder strictly validates SEC_TRANSPORT_RSP, so mismatched message-channel traffic fails decode and falls through.

1. [code-compressor] Three new hard dependencies back only an opt-in runtime path — low 🟡 — crates/ironrdp-server/Cargo.toml
   ironrdp-rdpemt, ironrdp-rdpeudp, and ironrdp-rdpeudp-tokio are unconditional dependencies yet are consumed solely by src/multitransport.rs, whose runtime path only executes when udp_bind_addr is Some (None by default). Marking them optional behind a dedicated/egfx feature with #[cfg] pairs on the module and its plumbing would shrink the default build with identical runtime behavior; the author acknowledges the mechanical breadth in review.

[Greg Lamberson (glamberson)]

Thanks for the review. On Soft-Sync being one-shot, that is the design, and the docs now say so. The request declares the TCP path flushed for the channel (SOFT_SYNC_TCP_FLUSHED, MS-RDPEDYC 2.2.5.1) and the server sends its data over the tunnel from then on (3.3.5.3.1), so a decline in the response no longer means EGFX stays on TCP: The response only lists the tunnels the client will write on (2.2.5.2). The spec has no path for taking a Soft-Sync back or offering a second one, so I did not add a re-request. The doc on dispatch_egfx_messages no longer calls the repeat request a no-op. It says the request is made once per connection and that the error from a later attempt is expected and only traced, and request_reliable_udp now says the same.

[Greg Lamberson (glamberson)]

Thanks for the second look at this. Gating the three UDP crates behind an optional feature is feasible: A stub UdpTransportHandle for the feature-off build would keep the signatures that carry it unchanged, so only the module, the builder method and the accept call become conditional. It also brings a default-on or default-off choice for the feature, so I am leaving it out of this PR. If it is wanted it can be done in another PR.

[Benoît Cortier (CBenoit)]

LGTM