Skip to main content
Version: 0.5.0
Docs.rs: ironrdp-dvc

Overview

The ironrdp-dvc crate provides infrastructure for RDP Dynamic Virtual Channels (DVCs). Unlike static channels (SVCs), dynamic channels:
  • Can be created and destroyed at any time during the session
  • Have no hard limit on the number of channels
  • Don’t require packet reconstruction (handled by the DVC manager)
  • Use the DRDYNVC static channel as a control channel
This crate provides:
  • The DRDYNVC static channel implementation
  • DvcProcessor trait for implementing custom DVCs
  • Client and server-side DVC managers

Core Traits

DvcProcessor

Implement this trait to create a custom dynamic virtual channel. Methods:
fn(&self) -> &str
Returns the channel name (e.g., “Microsoft::Windows::RDS::Geometry”)
fn(&mut self, channel_id: u32) -> PduResult<Vec<DvcMessage>>
Called when the channel is opened. Returns initial PDUs to send.
fn(&mut self, channel_id: u32, payload: &[u8]) -> PduResult<Vec<DvcMessage>>
Process a received PDU. Returns response PDUs to send.
fn(&mut self, channel_id: u32)
Called when the channel is closed (optional handler)

DvcEncode

Marker trait for types that can be sent as DVC messages. Similar to SvcEncode.

Client API

DrdynvcClient

Example:

Server API

DrdynvcServer

Similar to the client but waits for clients to initiate channel creation.

DVC Message Encoding

Encode DVC messages for transmission over the DRDYNVC static channel. Parameters:
u32
The DVC channel ID (assigned by the server)
Vec<DvcMessage>
Messages to encode
ChannelFlags
Additional SVC flags (compression, etc.)
This function automatically splits large messages using DataFirstPdu and DataPdu.

PDU Types

Implementation Example

Internal Types

DynamicVirtualChannel

Internal wrapper around a DvcProcessor. Handles message reassembly from DataFirst and Data PDUs.

Type Aliases

Data Splitting

DVC messages larger than DrdynvcDataPdu::MAX_DATA_SIZE are automatically split:
The first fragment uses DataFirstPdu (includes total size), subsequent fragments use DataPdu.

Features

feature
Enables standard library support
This crate supports no_std environments (with alloc).

Dependencies

  • ironrdp-core - Core traits (public)
  • ironrdp-svc - Static channel infrastructure (public)
  • ironrdp-pdu - PDU structures (public)
  • slab - Efficient channel ID allocation
  • tracing - Logging

Usage Notes

DVC Lifecycle:
Dynamic channels go through these states:
  1. Added to DrdynvcClient (client) or DrdynvcServer (server)
  2. Create Request/Response exchanged
  3. Channel ID assigned
  4. start() called
  5. Data exchange via process()
  6. Close PDU exchanged
  7. close() called
Channel Naming:
DVC names are typically hierarchical with :::
  • Microsoft::Windows::RDS::DisplayControl
  • Microsoft::Windows::RDS::Geometry
  • Microsoft::Windows::RDS::VideoControl
Custom channels should follow a similar pattern.
Thread Safety:
Both DrdynvcClient and DrdynvcServer require Send but not Sync. They’re designed for single-threaded event loops or message-passing architectures.

Common Dynamic Channels

IronRDP provides implementations for these standard DVCs:
  • ironrdp-displaycontrol - Display resolution/orientation control
  • ironrdp-egfx - Enhanced graphics pipeline (RemoteFX)
  • ironrdp-rdpdr - Device redirection (via DVC in some configurations)

See Also