Skip to content

feat(dvc): route channels over Soft-Sync tunnels - #1826

Open
Marc-André Moreau (mamoreau-devolutions) wants to merge 2 commits into
masterfrom
copilot/dvc-soft-sync-routing
Open

feat(dvc): route channels over Soft-Sync tunnels#1826
Marc-André Moreau (mamoreau-devolutions) wants to merge 2 commits into
masterfrom
copilot/dvc-soft-sync-routing

Conversation

@mamoreau-devolutions

@mamoreau-devolutions Marc-André Moreau (mamoreau-devolutions) commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

Add DvcMessageBatch to carry a dynamic channel ID alongside its
encoded SVC messages, and validate that a Soft-Sync-selected tunnel
matches the channel before forwarding tunneled DRDYNVC data.

DrdynvcClient::process_tunnel now takes the tunnel type it was
called for and returns a DvcMessageBatch instead of a bare message
list, so a caller juggling several tunnels can route responses back
onto the correct one. disable_soft_sync_tunnel and
has_channels_on_tunnel let a caller retire a tunnel and check
whether Soft-Sync ever routed a channel onto it.

When a Soft-Sync request selects a tunnel the client does not have
available, the request is rejected outright: per MS-RDPEDYC
3.2.5.3.1 the server manager starts sending data for the selected
channels on that tunnel as soon as it sends the request, before it
sees our response, so silently omitting an unavailable tunnel from
the response would lose that inbound data.

Also includes an unrelated one-line fix in
crates/ironrdp-daemon/src/daemon.rs (separate commit): two tests
added in #1822 constructed a raw tokio::sync::mpsc::channel instead
of the OutputEventReceiver wrapper from #1815, which breaks
cargo test --workspace --locked --no-run on master for every PR
regardless of what it changes. Bundled here to unblock this PR's CI;
tracked upstream as #1830.

Copilot AI balanced review requested due to automatic review settings August 29, 2026 00:03
@github-actions github-actions Bot added maintainer-required Maintainer review or intervention is required risk/unknown Risk could not be determined automatically; needs maintainer-level scrutiny scope/core Touches the core architectural tier size/S Size: up to 199 counted lines and 5 files; exceeds XS in either measure labels Aug 29, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Adds Soft-Sync tunnel-aware routing for client DVC messages.

Changes:

  • Introduces DvcMessageBatch.
  • Validates channel-to-tunnel routing.
  • Adds tunnel lifecycle APIs and tests.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
crates/ironrdp-dvc/src/lib.rs Defines routed DVC message batches.
crates/ironrdp-dvc/src/client.rs Implements Soft-Sync routing and tunnel handling.
crates/ironrdp-testsuite-core/tests/dvc/client.rs Tests unavailable tunnels and batch validation.

Comment thread crates/ironrdp-dvc/src/client.rs Outdated
Comment thread crates/ironrdp-dvc/src/lib.rs Outdated
Add DvcMessageBatch to carry a dynamic channel ID alongside its
encoded SVC messages, and validate that a Soft-Sync-selected tunnel
matches the channel before forwarding tunneled DRDYNVC data.

DrdynvcClient::process_tunnel now takes the tunnel type it was
called for and returns a DvcMessageBatch instead of a bare message
list, so a caller juggling several tunnels can route responses back
onto the correct one. disable_soft_sync_tunnel and
has_channels_on_tunnel let a caller retire a tunnel and check
whether Soft-Sync ever routed a channel onto it.

A Soft-Sync request that selects a tunnel the client does not have
available is still rejected outright: MS-RDPEDYC has the server
start sending tunneled data for those channels as soon as it sends
the request, before it sees our response, so there is no way to
drop the tunnel from the response and keep the channel usable on
the main connection instead.
…ests

Two tests added in #1822 constructed a raw tokio::sync::mpsc::channel
instead of the OutputEventReceiver wrapper introduced by #1815,
breaking 'cargo test --workspace --locked --no-run' on master for
every PR. Use the existing output_channel() constructor, matching
every other test in this module.

Fixes #1830
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maintainer-required Maintainer review or intervention is required risk/unknown Risk could not be determined automatically; needs maintainer-level scrutiny scope/core Touches the core architectural tier size/S Size: up to 199 counted lines and 5 files; exceeds XS in either measure

Development

Successfully merging this pull request may close these issues.

2 participants