feat(core): wire AsyncSshTransport into client remote transfer path (#1805)#4290
Merged
Merged
Conversation
…1805) Adds an async-ssh feature on the core crate that pulls in the tokio-backed `rsync_io::ssh::AsyncSshTransport` (PR #4273) and bridges it into the existing synchronous client transfer orchestration. A new `async_ssh_transport` module spawns the async transport, copies bytes between its `AsyncRead`/`AsyncWrite` halves and the sync handshake + server-framing layer via the `ChannelReader`/`ChannelWriter` adapters, and runs the sync server flow under `tokio::task::spawn_blocking`. The client driver picks the async path when the `OC_RSYNC_ASYNC_SSH=1` env var is set; the CLI flag is deferred to #1806. Progress observation and remote-to-remote proxy transfers remain on the sync path for now.
3 tasks
oferchen
added a commit
that referenced
this pull request
May 17, 2026
…4295) Adds the bridge primitives that let the existing synchronous multiplex and transfer code drive an async russh channel without being ported to async. Builds on PR #4290 (#1805) which wired the async SshTransport into the client driver via the OC_RSYNC_ASYNC_SSH env var. The new `ssh::embedded::sync_bridge` module is gated under `embedded-ssh` and exposes: - `SyncAsyncBridge<S>`: a generic facade that takes any `AsyncRead + AsyncWrite + Unpin + Send + 'static` stream (including russh's `ChannelStream`) and exposes `std::io::Read + std::io::Write` by driving an internal current-thread tokio runtime via `block_on`. - `into_sync_halves(russh::Channel)` returning `(SyncReader, SyncWriter)` halves backed by a background pump task and bounded `std::sync::mpsc` / `tokio::sync::mpsc` queues - the inverse of the existing `ChannelReader`/`ChannelWriter` adapters in `channel_adapter.rs`. - `into_sync_halves_with_capacity` for callers that need a different queue depth (used by the backpressure test).
oferchen
added a commit
that referenced
this pull request
May 18, 2026
…1805) (#4290) Adds an async-ssh feature on the core crate that pulls in the tokio-backed `rsync_io::ssh::AsyncSshTransport` (PR #4273) and bridges it into the existing synchronous client transfer orchestration. A new `async_ssh_transport` module spawns the async transport, copies bytes between its `AsyncRead`/`AsyncWrite` halves and the sync handshake + server-framing layer via the `ChannelReader`/`ChannelWriter` adapters, and runs the sync server flow under `tokio::task::spawn_blocking`. The client driver picks the async path when the `OC_RSYNC_ASYNC_SSH=1` env var is set; the CLI flag is deferred to #1806. Progress observation and remote-to-remote proxy transfers remain on the sync path for now.
oferchen
added a commit
that referenced
this pull request
May 18, 2026
…4295) Adds the bridge primitives that let the existing synchronous multiplex and transfer code drive an async russh channel without being ported to async. Builds on PR #4290 (#1805) which wired the async SshTransport into the client driver via the OC_RSYNC_ASYNC_SSH env var. The new `ssh::embedded::sync_bridge` module is gated under `embedded-ssh` and exposes: - `SyncAsyncBridge<S>`: a generic facade that takes any `AsyncRead + AsyncWrite + Unpin + Send + 'static` stream (including russh's `ChannelStream`) and exposes `std::io::Read + std::io::Write` by driving an internal current-thread tokio runtime via `block_on`. - `into_sync_halves(russh::Channel)` returning `(SyncReader, SyncWriter)` halves backed by a background pump task and bounded `std::sync::mpsc` / `tokio::sync::mpsc` queues - the inverse of the existing `ChannelReader`/`ChannelWriter` adapters in `channel_adapter.rs`. - `into_sync_halves_with_capacity` for callers that need a different queue depth (used by the backpressure test).
oferchen
added a commit
that referenced
this pull request
May 18, 2026
…1805) (#4290) Adds an async-ssh feature on the core crate that pulls in the tokio-backed `rsync_io::ssh::AsyncSshTransport` (PR #4273) and bridges it into the existing synchronous client transfer orchestration. A new `async_ssh_transport` module spawns the async transport, copies bytes between its `AsyncRead`/`AsyncWrite` halves and the sync handshake + server-framing layer via the `ChannelReader`/`ChannelWriter` adapters, and runs the sync server flow under `tokio::task::spawn_blocking`. The client driver picks the async path when the `OC_RSYNC_ASYNC_SSH=1` env var is set; the CLI flag is deferred to #1806. Progress observation and remote-to-remote proxy transfers remain on the sync path for now.
oferchen
added a commit
that referenced
this pull request
May 18, 2026
…4295) Adds the bridge primitives that let the existing synchronous multiplex and transfer code drive an async russh channel without being ported to async. Builds on PR #4290 (#1805) which wired the async SshTransport into the client driver via the OC_RSYNC_ASYNC_SSH env var. The new `ssh::embedded::sync_bridge` module is gated under `embedded-ssh` and exposes: - `SyncAsyncBridge<S>`: a generic facade that takes any `AsyncRead + AsyncWrite + Unpin + Send + 'static` stream (including russh's `ChannelStream`) and exposes `std::io::Read + std::io::Write` by driving an internal current-thread tokio runtime via `block_on`. - `into_sync_halves(russh::Channel)` returning `(SyncReader, SyncWriter)` halves backed by a background pump task and bounded `std::sync::mpsc` / `tokio::sync::mpsc` queues - the inverse of the existing `ChannelReader`/`ChannelWriter` adapters in `channel_adapter.rs`. - `into_sync_halves_with_capacity` for callers that need a different queue depth (used by the backpressure test).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
async-sshfeature on thecorecrate that pulls inrsync_io/async-sshanddep:tokio, gating the tokio-backed SSH transport wiring.crates/core/src/client/remote/async_ssh_transport.rsmodule that spawnsAsyncSshTransport, bridges itsAsyncRead/AsyncWritehalves through theChannelReader/ChannelWriteradapters from PR feat(rsync_io): ChannelReader/Writer AsyncRead/AsyncWrite adapters (#1797) #4271, and runs the existing sync handshake + server-framing layer undertokio::task::spawn_blockingvia a pair ofstd::sync::mpscchannels.OC_RSYNC_ASYNC_SSH=1is set; CLI flag work is tracked separately as Handle forced missing cargo tools in packaging tests #1806.SshTransportpath remains the default. Progress observation and remote-to-remote proxy transfers stay on the sync path on the async wiring for now.Architecture
Deferred to #1806
--info=progress2parity).Test plan
cargo fmt --all -- --checkcargo check -p core --features async-ssh --no-default-featurescargo check -p core(default features)cargo check --workspace --all-featurescargo clippy -p core --features async-ssh --no-default-features --all-targets --no-depscargo clippy -p core --all-features --all-targets --no-depscargo nextest run -p core --features async-ssh --no-default-features -E 'test(async_ssh_transport)'(8/8 pass)cargo nextest run -p core -E 'test(ssh_transfer)'(15/15 pass, no regression on sync path)