Implementing WebTransport datagram for volatile emit

[juanjaho]

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.

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

Reference:
#5001 (reply in thread)

[darrachequesne]

Hi!

That sounds indeed reasonable. I think the only downside is that volatile would lose the ordering guarantee, which is not the case today.

It shouldn't be that hard to implement: if the packet is marked as volatile, we use the datagrams stream (transport.datagrams.writable.getWriter()) instead of the bidirectional stream.

Server:

socket.io/packages/engine.io/lib/transports/webtransport.ts

Line 57 in 3be6481

await this.writer.write(packet);

Client:

socket.io/packages/engine.io-client/lib/transports/webtransport.ts

Line 97 in 3be6481

this._writer.write(packet).then(() => {

[juanjaho]

Indeed, ordering guarantee being the main trade-off here. We could either handle ordering client-side for volatile messages by giving a queue number for each payload sent, or just add something like io.ff.emit(...) or io.datagram.emit(...) for true UDP fire-and-forget, which would also keep backward compatibility for now.

However, this would only work with WebTransport, so it should be documented as WebTransport-specific. For other transports, it would need to fall back to the existing reliable channel.