[maxolgi]

What this adds

SRT sockets can now exchange their datagrams through an owner-supplied
userspace transport (for example WebTransport/QUIC) instead of an OS UDP
socket, with no change to the behavior of regular UDP sockets in the
same process. Everything above the multiplexer channel — handshake, ARQ,
crypto, TSBPD — runs unchanged; the feature is gated behind the CMake
option ENABLE_VIRTUAL_TRANSPORT (OFF by default, Linux and Emscripten).

Motivating use case: serving SRT sessions to browser/WASM clients over
WebTransport, where the browser hands datagrams to the application and
there is no UDP socket to bind.

The seam

• srt_attach_virtual_transport() wires an unbound socket to an
  owner-supplied send callback; outgoing datagrams are delivered to it
  as one contiguous network-order buffer, exactly the bytes a UDP
  sendto() would have emitted.
• srt_virtual_transport_inject() feeds received datagrams back in,
  thread-safe, from any thread.
• srt_detach_virtual_transport() / srt_virtual_transport_release()
  manage lifetime; the transport object is reference-counted so the
  caller's handle stays valid concurrently with socket closure.
• The seam lives behind CChannel; every attached socket owns a
  dedicated multiplexer, so stock UDP sockets are unaffected.

Two accompanying options

• SRTO_SKIP_INDUCTION — conclusion-first handshakes. The enclosing
  transport already authenticates the peer (e.g. WebTransport TLS), so
  the Induction round trip is redundant. A caller with this option sends
  the Conclusion immediately with cookie 0; a listener accepts it only
  when the request arrived over a virtual-transport channel — a plain
  UDP listener keeps the full cookie validation.
• SRTO_INITIAL_RTT — seed the RTT estimator from the enclosing
  transport's measured RTT (e.g. QUIC's smoothed RTT) until the first
  live sample. Skipping Induction removes the round trip that normally
  delivers the first sample, so the two options are designed to
  accompany each other.

Included stock fixes

Four independent fixes to existing code, found while stress-testing this
work; each is self-contained and useful on its own:

1. False SRTS_BROKEN window in postConnect (status poller could see
   BROKEN while the handshake was completing)
2. Unlocked receiver-loss-list reads in the LOSSREPORT sender
3. Unsynchronized buffer publication vs. the GC scan (plus the same
   pattern in the CLOSE_SYNCH wait)
4. Demoted a spurious Warn-level log on empty reads

We're happy to split these into separate PRs first if that's easier
to review — say the word.

API shape (open to discussion)

The new symbols follow the ENABLE_BONDING precedent: declared and
linkable in every build; in builds without the seam they fail at runtime
(attach returns NULL, the int-returning functions -1/SRT_EINVPARAM,
the options rejected as unsupported). This keeps a single libsrt.so
ABI stable across build configurations. If maintainers prefer a
different gating scheme, happy to adjust.

Testing

• 16-case suite over in-memory wires: positive paths, rejection paths
  (rendezvous, stock-UDP, attach-after-bind), detach under live traffic,
  queue pressure, and a wire-level assertion that the first skip-induction
  flight is a cookie-0 Conclusion.
• 4-case stock-build suite asserting the clean-failure behavior of the
  symbols and options when the seam is compiled out.
• Full suites pass in both configurations (316 VT / 297 stock),
  C++11-strict.

Reviewing

The commit series is structured feature-first, then the stock fixes,
then review polish; the significant files are srtcore/virtual_transport.{h,cpp}
(the transport object), srtcore/channel.* (the seam), srtcore/api.cpp
(attach/detach plumbing), srtcore/core.cpp (handshake and options),
test/test_virtual_transport*.cpp, and the docs/API sections.

CI notes

Full CI was validated on a fork rehearsal: every workflow that can pass, passes;
plus a dedicated virtual-transport workflow that builds with
ENABLE_VIRTUAL_TRANSPORT=ON, C++11, warnings-as-errors, and runs the
complete test suite (325 tests, including the 16-case virtual-transport
suite and the 4-case stock-build rejection suite).

Three checks fail on the fork's runners for reasons unrelated to this
change, each reproduced on unmodified upstream master in
this probe PR:

• Linux C++11, ARM job — flaky upstream test; upstream's own runs
  from Oct 9, Oct 15, and Oct 30 (twice) show the same failures on
  Haivision's own runners.
• QEMU s390x — fails at the configure step, before any build;
  runner infrastructure.
• ABI checks — GitHub is migrating ubuntu-latest from Ubuntu
  24.04 to 26.04 gradually between Oct 19 and Nov 19, 2026
  (runner-images #14748).
  Runs that land on the new image get CMake 4, which refuses to configure
  the 2021-era v1.5.0 baseline tag (its cmake_minimum_required
  predates CMake 3.5). Haivision's own Oct 30 run passed on the old
  image; the same unmodified code fails on the new one. This affects
  every ubuntu-latest workflow in this repository as the rollout
  completes — not just this PR.

One real portability bug was found thanks to the new image and is fixed
in this PR: a one-past-the-end std::vector access in the virtual
transport receive path, trapped by GCC 15's hardened libstdc++ (default
on 26.04). The suite passes under -D_GLIBCXX_ASSERTIONS.

[maxolgi]

"Marking ready for review. Full CI validated on the fork (see CI notes); the three red checks reproduce identically on unmodified upstream master."

[ethouris]

Ok, first things first: As this would have to be a new feature, it cannot be drawn off master - this one holds the stable versions for 1.5.* line and no new features are allowed.

The dev branch contains new features and it's the only allowed target to use with new features. That said, note that there's a big change in the multiplexer management, as well as the buffer management for reading is completely refactored.

As for this solution itself, it's also not acceptable in this form by the following reasons:

1. This can't be a setting applied on the socket as such. This effectively applies to the multiplexer, and multiplexers are potentially shared between sockets. There are also other solutions that work this way, notably options that apply to the UDP socket as such. These may make the multiplexer either non-sharable between SRT sockets or at least require that these setting be set the same.
2. The functions that manage sending and recevig in the virtual transport should accept an array of buffers, just as the ::sendmsg and ::recvmsg do. These solutions are created specifically for sending at once multiple data that are contained in differet pieces of memory, without copying them, as this would sit on performance.
3. The object management is done wrong. The actual resolution should be directly in the CChannel class; it should either contain both UDP socket descriptor and the handler function, to be selected if exists, or the sendto and recvfrom methods shall be made virtual, with instantiation classes like CChannelUDP and CChannelCustom, something like that - whichever offers better performance.
4. Skipping INDUCTION part of the handshake changes the protocol, and this shouldn't be something to be set separately on the socket, rather as a part of the configuration done for the virtual transport configuration as such.
5. Setting up an alternative transport shall be done the same way as currently setting up the multiplexer, as it actually is setting up the multiplexer, so the actual activity should be done through "binding". And as such, it should be under the direct control of the operation done on the socket - meaning, you don't create any object "in the socket" (because there's no need for this), you access the data through the socket to operate directly on the multiplexer. The socket shall completely contain no data related to this. Also, everything that is a setting specific for this very feature shall be contained in the structure that is used to configure binding the socket to this virtual tansport - meaning, it should pass exactly the same procedure as "binding" so far: finding the suitable multiplexer, or creating a new one, configuring it with the data directly passed by the user. Selection of the right pass for the updateMux, for example, likely would have to be reworked to select the right function depending on how it is configured - currently it's srt_bind, which requires that SRT create the UDP socket itself, or srt_bind_acquire, where the user can pass the pre-created UDP socket himself. This would have to be yet another binding function, like srt_bind_virtual or srt_bind_custom, where the structure with all settings and required data is passed to it.

[maxolgi]

Thank you for the detailed review — this is very helpful.

Before I rework it, here's my understanding of the target design, so please
correct me if I got anything wrong:

• I'll retarget to dev and reimplement on top of the new multiplexer
  management rather than textually rebase (I can see the CMultiplexer /
  queue refactoring changes most of the touched code).
• The virtual transport becomes a multiplexer-level setting configured
  through a new binding function, srt_bind_virtual() (or
  srt_bind_custom, if you prefer that name), which takes a structure
  with all settings and required data (send callback + opaque,
  skip-induction, etc.). The socket itself keeps no data related to this,
  and updateMux selects the right path: srt_bind, srt_bind_acquire,
  or srt_bind_virtual.
• Every srt_bind_virtual() gets a dedicated multiplexer — virtual
  multiplexers are not reuse candidates for new bindings (accepted
  sockets still join the listener's multiplexer through the normal
  accept path). This can be relaxed to same-settings sharing later if
  you prefer.
• The resolution moves into CChannel. I plan to make sendto/recvfrom
  virtual with CChannelUDP / CChannelVirtual subclasses — the dynamic
  allocation is already there and the XXX comment in
  CMultiplexer::configure seems to anticipate exactly this. The virtual
  dispatch also keeps the stock UDP path untouched. If you'd prefer the
  both-members-and-branch variant instead, I can do that too.
• The send and receive functions of the virtual transport will accept an
  array of buffers (like ::sendmsg/::recvmsg), so the header and
  payload blocks are passed through without gathering or copying.
• Skipping INDUCTION becomes part of the bind configuration, not a socket
  option. The synthetic binding currently synthesized in listen()
  disappears — a listener binds explicitly via srt_bind_virtual().

One thing I'd like to confirm before I implement: datagram injection.
I'd make it go through the socket — srt_virtual_transport_inject(SRTSOCKET, ...),
resolving socket → multiplexer → channel, with no extra handles or
reference counting (lifetime tied to the multiplexer). Acceptable?

And one scoping question: the PR also adds SRTO_INITIAL_RTT, an optional
seed for the RTT estimator before the first live sample (useful when
INDUCTION is skipped, and potentially for high-RTT links generally).
The review didn't mention it — should I keep it inside the virtual
transport bind configuration, or split it out as a separate PR for
general sockets?

[ethouris]

Ok, so responding to your questions:

• Every srt_bind_virtual() gets a dedicated multiplexer — virtual
  multiplexers are not reuse candidates for new bindings (accepted
  sockets still join the listener's multiplexer through the normal
  accept path). This can be relaxed to same-settings sharing later if
  you prefer.

The most important now is that the multiplexer sharing works correctly
on the listener (as it wouldn't work otherwise); sharing on caller is
not that important, and can be added later, if needed.

• The resolution moves into CChannel. I plan to make sendto/recvfrom
  virtual with CChannelUDP / CChannelVirtual subclasses — the dynamic
  allocation is already there and the XXX comment in
  CMultiplexer::configure seems to anticipate exactly this. The virtual
  dispatch also keeps the stock UDP path untouched. If you'd prefer the
  both-members-and-branch variant instead, I can do that too.

As I said, from the design point of view both are acceptable. Important for
this choice is performance.

• Skipping INDUCTION becomes part of the bind configuration, not a socket
  option. The synthetic binding currently synthesized in listen()
  disappears — a listener binds explicitly via srt_bind_virtual().

Ok, note that we have also considered using conclusion-only handshakes
for specific configurations, however the sole mechanism for it is not
to be freely settable by the user through the API, but to be set internally
for various purposes. So it would be nice that the mechanism as such
remains available, but only through this internal function, not through
any API call.

One thing I'd like to confirm before I implement: datagram injection. I'd
make it go through the socket — srt_virtual_transport_inject(SRTSOCKET, ...), resolving socket → multiplexer → channel, with no extra handles or
reference counting (lifetime tied to the multiplexer). Acceptable?

Imagine this the same way as you would replace the UDP socket with a
pipe descriptor, and passed to srt_bind_acquire (this isn't possible
actually because this function does check if the passed descriptor is
a socket by doing socket-only operations on it), then you feed this in.

What you are providing for SRT is a replacement for UDP socket; normally
the UDP socket is operated by the operating system, and this one provides
it with packets to read and accepts packets to send. Here you need to
replace this complete mechanism, while providing a functional equivalent
API.

So, you likely need:

• A structure that contains all the data: specific settings and callbacks:
  • to send the data
  • to wait for reading, with timeout (see how it is done when reading from socket)
  • to deliver data, once read-ready (including reporting broken medium)

(Not sure about sender readiness check - likely it should suffice if this
situation is reported by some returned error, but it should be also handled
carefully inside; broken medium should result in a broken connection and
the SRT socket).

SRT only needs the right callbacks provided to be able to use this thing.
Everything else should be programmed outside SRT.

In other words, the mechnism to "deliver" the wrapped packet by pushing
it into the queue and informing about readiness through the CV should be
a separate facility; a model for it can be added, but rather in a separate
directory, compiled to a separate library (likely only static one is
necessary - mind that "srt_virtual" is a reserved name already in the cmake
as a method to compile both static and shared SRT library; something like
"libsrttransport.a" on Linux should be ok I think). This can then use
the configuration structure for binding to virtual transport and filling it with
appropriate data, while providing an object - no matter how implemented - that
will facilitate the intermediate packet delivery ("injection"); this can be
simply provided so that applications using this mechanism can be created
easier, but it shouldn't be a part of the SRT library. Note that theoretically
this can be implemented using various underlying libraries, not necessarily
the C++ standard library (don't forget that SRT still has a limitation to
C++98 standard, and you broke it by not using exclusively the srt::sync wrapper -
if you create a separate library for transport only, as an optional component, it can
be also free of that limitation).

And one scoping question: the PR also adds SRTO_INITIAL_RTT, an optional
seed for the RTT estimator before the first live sample (useful when
INDUCTION is skipped, and potentially for high-RTT links generally). The
review didn't mention it — should I keep it inside the virtual transport bind
configuration, or split it out as a separate PR for general sockets?

That's a kind of problem. SRT does have a mechanism for this - see the CCache
class (plus the underlying CInfoBlock), however not accessible through the
API. The reasoning for it (can't speak for myself as this was done already
in the original UDT project) was to keep the remembered data from the used
links so that they can be restored later when connecting to the same endpoint.
Not sure if this mechanism can be reused here. Still, from the API point of
view this is another thing to be done on the transport descriptor object.
The CInfoBlock object in SRT is used at the connection point: in postConnect()
and acceptAndRespond(), which is the last phase of the connection on both
sides. Likely the same mechanism would have to be reused here, just the
mechanism of indexing and searching of the data would have to be extended
to handle also the virtual transport specification. At least you have already
a certin binding to the multiplexer and you can check things at this point.

NOTE: this design is a bit flawed (I have some plan prepared to fix it, but
we have limited resources) and this thing is remembered PER SOCKET simply
because even if two sockets share the same multiplexer, they can be connected
to a different endpoints and therefore will send packets to a different
address, even though they use the same UDP socket for sending. With virtual
transport this would likely have to be done differently, but if you state
that such multiplexers need not be shared, it should suffice if you ask
the multiplexer about the medium type, and if it's not UDP, you will take
these data directly from the virtual transport configuration object,
otherwise you'll extract them the old way.

What I had in mind to redesign it is that a single facility to send to
a certain remote address is managed by a "pipe manager", while you may
also have separate pipe managers, each of which separately collects the
data concerning bandwidth and RTT (as they are separate network links)
and SRT sockets directly only them; then a multiplexer can contain
multiple pipe managers, while on the other hand multiple SRT sockets may
also share pipe managers, independently on sharing multiplexers. But
that's not how UDT was designed and we had no possibility earlier to change
it, hence for now all the link-related data are kept in the socket,
even if potentially multiple sockets may share not only a single UDP
socket, but also the exact UDP link (packets will be sent to the same
endpoint using the same UDP socket). Likely however, you'll have to
distinguish sharing the medium from sharing the network link, and if the
mechanism of sharing the network link doesn't sound useful for this case,
you should avoid it - meaning:

• caller sockets cannot share multiplexers with virtual transport (as now)

• listener sockets shall reject a connection from the address that this
  multiplexer is already handling

If you decide to do it this way, at least you'll get rid of the problem of
shared links and you can safely state that the socket shall carry the
characteristic data of the network link. Thefore, the link measurement
data can be restored directly to the data in the socket, as it is now.