Thanks for confirming.

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!

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?

@darrachequesne bumping this up 👍

#5378 (comment)

Started a new thread for cleaner converstion