Skip to content

Commit eee839f

Browse files
committed
docs(connector): clarify MultitransportPending state vs wire behavior
The doc-comment on MultitransportPending described the connector as "paused waiting for the application to establish UDP transport," which reads as a spec-mandated TCP gate on UDP completion. Per review feedback, real RDP traffic shows TCP and UDP negotiating in parallel, with UDP completion functioning as a DVC migration signal rather than a TCP gate. Rewrite the comment to describe the state as the connector's API yield point (what it is) and add a paragraph describing the actual wire behavior. State machine semantics unchanged. Signed-off-by: Greg Lamberson <greg@lamco.io>
1 parent 130bbc8 commit eee839f

1 file changed

Lines changed: 12 additions & 3 deletions

File tree

crates/ironrdp-connector/src/connection.rs

Lines changed: 12 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -98,12 +98,21 @@ pub enum ClientConnectorState {
9898
/// Multitransport requests received from the server so far.
9999
requests: Vec<rdp::multitransport::MultitransportRequestPdu>,
100100
},
101-
/// The server sent multitransport request(s) and the connector is paused
102-
/// waiting for the application to establish UDP transport or decline.
101+
/// State the connector enters after the server has sent multitransport
102+
/// request(s) and before resuming with the Demand Active PDU. The
103+
/// connector surfaces this as an API yield point so the caller can run
104+
/// UDP transport setup and report the outcome.
103105
///
104106
/// Call [`ClientConnector::complete_multitransport()`] or
105107
/// [`ClientConnector::skip_multitransport()`] to advance. The buffered
106-
/// Demand Active PDU is replayed internally — no re-feeding needed.
108+
/// Demand Active PDU is replayed internally on resume; the caller does
109+
/// not need to re-feed it.
110+
///
111+
/// On the wire, TCP and UDP negotiation happen in parallel: the UDP
112+
/// transport is established alongside the ongoing TCP handshake, and
113+
/// its completion is a signal to the dynamic-channel layer that
114+
/// subsequent channels may migrate to UDP. The connector's suspension
115+
/// here is a Rust-API affordance, not a spec-mandated TCP pause.
107116
MultitransportPending {
108117
io_channel_id: u16,
109118
user_channel_id: u16,

0 commit comments

Comments
 (0)