Skip to content

feat(connector,session): dispatch multitransport PDUs on IO channel#1108

Open
glamberson wants to merge 1 commit intoDevolutions:masterfrom
lamco-admin:io-channel-multitransport
Open

feat(connector,session): dispatch multitransport PDUs on IO channel#1108
glamberson wants to merge 1 commit intoDevolutions:masterfrom
lamco-admin:io-channel-multitransport

Conversation

@glamberson
Copy link
Contributor

Companion to #1098 — surfaces multitransport request PDUs through the session layer so applications can respond.

What this does

After licensing, the server may send Initiate Multitransport Request PDUs on the IO channel. These use a BasicSecurityHeader rather than the usual ShareControlHeader, so they need special discrimination in decode_io_channel.

This PR:

  • ironrdp-connector: Adds a MultitransportRequest variant to IoChannelPdu and discriminates it from ShareControlHeader by checking bytes [2..4]ShareControl always has pduType | PROTOCOL_VERSION (≥ 0x11) at that offset, while BasicSecurityHeader has flagsHi == 0.
  • ironrdp-session: Propagates MultitransportRequest through ProcessorOutputActiveStageOutput so applications receive the event.
  • ffi: Exposes the multitransport request fields via diplomat bindings (request ID + requested protocol; security cookie deferred until UDP transport is implemented).

Discrimination approach

The key insight is that ShareControlHeader encodes pduType | PROTOCOL_VERSION at bytes [2..4], which is always >= 0x11. A BasicSecurityHeader with TRANSPORT_REQ flag has flagsHi == 0 at that same offset. This lets us cheaply distinguish the two header types without backtracking.

The discriminant logic uses an inner function (try_decode_multitransport) per the project's style guide preference for inner functions over single-use closures.

Relationship to #1098

Both are needed for full multitransport support, but they're independent — each modifies different files and can be reviewed/merged in either order.

Builds on: #1091
Related: #1098, #140

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Surfaces server “Initiate Multitransport Request” PDUs received on the IO channel up through the session layer (and FFI) so applications can react during the active stage, using a fast discrimination path between ShareControlHeader and BasicSecurityHeader.

Changes:

  • Update IO-channel decoding to opportunistically decode MultitransportRequestPdu before falling back to ShareControlHeader.
  • Propagate and improve visibility of multitransport request events through ProcessorOutput/ActiveStageOutput (incl. structured logging).
  • Adjust FFI-facing documentation around deferred exposure of the security cookie.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
crates/ironrdp-connector/src/legacy.rs Adds/encapsulates multitransport discrimination logic in IO-channel decode path.
crates/ironrdp-session/src/x224/mod.rs Improves docs and emits structured debug fields when receiving multitransport requests.
crates/ironrdp-session/src/active_stage.rs Updates ActiveStageOutput docs for multitransport request propagation.
ffi/src/session/mod.rs Updates diplomat-exposed docs for multitransport request field availability.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Add MultitransportRequest variant to IoChannelPdu, ActiveStageOutput,
and ProcessorOutput to surface server-initiated multitransport requests
through the session layer. Applications receive MultitransportRequest
events and can establish sideband UDP transports.

Discriminate BasicSecurityHeader from ShareControlHeader by checking
bytes [2..4]: ShareControl always has pduType | PROTOCOL_VERSION
(>= 0x11) at that offset, while BasicSecurityHeader has flagsHi == 0.

Changes:
- ironrdp-connector: add multitransport discriminant to decode_io_channel
- ironrdp-session: propagate MultitransportRequest through x224 processor
- ffi: expose MultitransportRequest type via diplomat bindings
@glamberson glamberson force-pushed the io-channel-multitransport branch from 1f3e3f4 to 57fefac Compare February 18, 2026 00:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants