Support for unrealiable delivery of WebTransport datagrams

[CoryG89]

Hi, I noticed that socket.io has added support for WebTransport using the polyfill provided by fails-components. I tried to find more information about how socket.io is using WebTransport, but couldn't find much beyond the small amount of information in the changelog when it was added.

With the current support for WebTransport is it possible to configure socket.io to only use unreliable delivery with datagrams beneath the hood and to not fallback to websockets, http long-polling, etc, such that I would then be able to cancel loading the app entirely if the environment/connection cannot support unreliable delivery with WebTransport?

Also, if socket.io can use unreliable delivery through WebTransport, then I assume this would also mean that in such a case socket.io would no longer be guaranteeing the order in which messages are received. Is this correct?

[darrachequesne]

Hi!

With the current support for WebTransport is it possible to configure socket.io to only use unreliable delivery with datagrams beneath the hood

It is not currently possible to use datagrams, as we rely on a bidirectional stream: https://github.com/socketio/engine.io-client/blob/218c3443f6059de43e916e9add09e9f96d529644/lib/transports/webtransport.ts#L43

Also, if socket.io can use unreliable delivery through WebTransport, then I assume this would also mean that in such a case socket.io would no longer be guaranteeing the order in which messages are received. Is this correct?

True. In that case, the order and the actual transmission of the messages would no longer be guaranteed.

Reference: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/datagrams

[ependergrass]

Speaking of reliability.. does WebTransport really have more to offer than WebSocket transport for Socket.io? Is it worth having your transport options set to Polling, Web Socket, THEN upgrade to WebTransport? Seems like a lot of phases to get through to me.

Edit: I see WebTransport DOES brag about actually having some reliability, so this is really tempting. Still curious about whether it's worth it to upgrade thru all 3 options though @darrachequesne

Thanks!

[juanjaho]

That would indeed be incompatible with the guarantees (actual delivery & order) provided by the library, so I don't think this would make sense.

Hello, I know this is an old thread, but I wanted to revisit this.

Guarantees of actual delivery and order are core to the library's design, making it incompatible with a datagram approach.

However, with the introduction of WebTransport, specifically its unreliable datagrams, I believe there's a compelling case for reconsideration.

The existing io.volatile.emit() functionality in Socket.IO already signals an intent to send data without certain delivery guarantees.

It seems like WebTransport's datagrams would be a perfect fit for this particular use case, offering a more native and potentially optimized way to achieve that "fire-and-forget" behavior.

I've been seriously considering Socket.IO as a very strong contender for a peer-to-peer data passthrough server, and the ability to leverage unreliable datagrams efficiently is truly the last feature I feel is missing to make it an ideal solution for certain real-time scenarios.

Would it make sense to explore how WebTransport datagrams could enhance or integrate with the existing volatile emission strategy?

[juanjaho]

@darrachequesne bumping this up 👍

[juanjaho]

#5378 (comment)

Started a new thread for cleaner converstion

[darrachequesne]

(since I'm replying on another comment in this thread)

Another potential option would be to create a new transport which would use datagrams (without delivery and ordering guarantees).

Something like:

import { XHR, WebTransportDatagram, io } from "socket.io-client";

const socket = io({
  transports: [XHR, WebTransportDatagrams]
});

socket.volatile.emit("event");

[sanjomo]

@darrachequesne

As per this implementation:
https://github.com/socketio/engine.io-client/blob/218c3443f6059de43e916e9add09e9f96d529644/lib/transports/webtransport.ts#L43

Are all Engine.IO messages sent over a single bidirectional WebTransport stream? Since QUIC supports multiple independent streams, it seems we could potentially leverage them to avoid stream-level head-of-line blocking. If all traffic is multiplexed onto a single stream, wouldn't that limit one of the key advantages of using QUIC/WebTransport in the first place?

[darrachequesne]

Hi!

Yes, that’s a valid point. The current WebTransport support uses one bidirectional stream per Engine.IO session, so Engine.IO packets remain globally ordered, similarly to WebSocket. This keeps the existing protocol semantics simple and compatible.

WebTransport/QUIC could theoretically be used with multiple streams to reduce stream-level head-of-line blocking, but Engine.IO currently has no protocol-level notion of mapping packets to different streams or relaxing global packet ordering. Adding that would require defining ordering, backpressure, prioritization, and compatibility semantics.

[sanjomo]

@darrachequesne Thanks for the clarification. I completely understand the desire to preserve the existing Engine.IO semantics and compatibility guarantees.
That said, would it be worth exploring namespace-level stream separation as a possible middle ground? For example, keeping a control stream for Engine.IO/session management while assigning each Socket.IO namespace its own bidirectional WebTransport stream.
This seems like it could preserve ordering within a namespace while allowing independent namespaces to benefit from QUIC's stream multiplexing and avoid stream-level head-of-line blocking. Of course, there are likely protocol and compatibility considerations that I'm not accounting for, but it feels like a potentially interesting sweet spot between maintaining current semantics and leveraging more of WebTransport's capabilities.

[darrachequesne]

Yes, that is an interesting idea.

Mapping each Socket.IO namespace to its own WebTransport bidirectional stream could preserve per-namespace ordering while allowing independent namespaces to avoid stream-level head-of-line blocking.

The main challenge is that Socket.IO currently multiplexes namespaces at the packet layer over a single Engine.IO transport, so this would not be a purely internal transport optimization.

[sanjomo]

@darrachequesne I agree with you. If there's ever a future version or proposal to explore this direction, please let us know. We'd be happy to contribute to the design, architecture, and implementation discussions.