Socket.IO confirmed delivery

Question

Before I dive into the code, can someone tell me if there is any documentation available for confirmed delivery in Socket.IO?

Here's what I've been able to glean so far:

1. A callback can be provided to be invoked when and if a message is acknowledged
2. There is a special mode "volatile" that does not guarantee delivery
3. There is a default mode that is not "volatile"

This leaves me with some questions:

1. If a message is not volatile, how is it handled? Will it be buffered indefinitely?
2. Is there any way to be notified if a message can't be delivered within a reasonable amount of time?
3. Is there any way to unbuffer a message if I want to give up?

I'm at a bit of a loss as to how Socket.IO can be used in a time sensitive application without falling back to volatile mode and using an external ACK layer that can provide failure events and some level of configurability. Or am I missing something?

Answer 1

TL;DR You can't have reliable confirmed delivery unless you're willing to wait until the universe dies.

---

The delivery confirmation you seek is related to the theoretical Two Generals Problem, which is also discussed in this SO answer.

TCP manages the reliability problem by guaranteeing delivery after infinite retries. We live in a finite universe, so the word "guarantee" is theoretically dubious :-)

Theory aside, consider this: engine.io, the underpinnings of socket.io 1.x, uses the following transports:

• WebSocket
• FlashSocket
• XHR polling
• JSONP polling

Each of those transports is based upon TCP, and TCP is reliable. So as long as connections stay connected and transports don't change, each individual socket.io message or event should be reliable. However, two things can happen on the fly:

1. engine.io can change transports
2. socket.io can reconnect in case the underlying transport disconnects

So what happens when a client or your server squirts off a few messages while the plumbing is being fiddled with like that? It doesn't say in either the engine.io protocol or the socket.io protocol (at versions 3 and 4, respectively, as of this writing).

As you suggest in your comments, there is some acknowledgement logic in the implementation. But even simple digital communications has notrivial behavior, so I do not trust an unsupervised socket.io connection for reliable delivery for mission- or safety-critical operations. That won't change until reliable delivery is part of their protocol and their methods have been independently and formally verified.

You're welcome to adopt my policies:

• Number my messages
• Ask for a resend when in doubt
• Do not mutate my state - client or server - unless I know I'm ready

In Short:

Guaranteed message delivery acknowledgement is proven impossible, but TCP guarantees delivery and order given "infinite" retries. I'm less confident about socket.io messages, but they're really powerful and easy to use so I just use them with care.