pub enum Tunnel {
Bidi {
client: Box<dyn AsyncReadWrite + Send>,
upstream: Box<dyn AsyncReadWrite + Send>,
close_reason_tx: Option<Sender<CloseReason>>,
},
SpliceBidi {
client: TcpStream,
upstream: TcpStream,
close_reason_tx: Option<Sender<CloseReason>>,
},
Udp(UdpTunnel),
}Expand description
Bridge between the executor’s ByteTunnel arm and a fetch’s chosen
transport. Bidi is the stream-pair shape that
tokio::io::copy_bidirectional consumes — covers TCP forward, TLS
passthrough, and the H1 WebSocket post-upgrade path. Udp is the
session-driven shape: the fetch has already spawned the per-5-tuple
forwarder task; the executor’s role degenerates to awaiting
join so ConnContext cleanup runs at the right moment.
See spec/crates/engine.md § udp_dispatch for the UDP
session lifecycle and spec/crates/engine.md § Concrete fetches for the TCP arm.
Variants§
Bidi
Fields
client: Box<dyn AsyncReadWrite + Send>upstream: Box<dyn AsyncReadWrite + Send>close_reason_tx: Option<Sender<CloseReason>>SpliceBidi
Zero-copy TCP↔TCP forward suitable for splice(2) on Linux.
Both halves are bare tokio::net::TcpStreams — no TLS, no
peek prelude, no virtual sockets — so the kernel can move
bytes through a pipe without entering user space. The engine
emits this variant from L4ForwardFetch when the inbound
L4Conn::Tcp and the dialed upstream are both raw TCP, and
drive_byte_tunnel routes Linux platforms through
tokio-splice2; non-Linux platforms fall back to the same
tokio::io::copy_bidirectional driver as Self::Bidi.