-
Notifications
You must be signed in to change notification settings - Fork 10.1k
-
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)
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 2
Replies: 1 comment 1 reply
-
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:
Client:
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.