24

The API provides the emit/send callback mechanism to acknowledge received messages. However, this callback doesn't get fired in case of disconnect or error. It appears to me that upon a disconnection one would need to go through some rather messy procedures to clean up outstanding sent messages (e.g. - assume a use case where you may want to store messages for forwarding later, etc.). Any simple ideas out here on how to accomplish this? Wondering if I'm missing something.... Thanks.

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
Mark
  • 866
  • 9
  • 18
  • 1
    Were you able to find out more about this, maybe a solution? – hjon Mar 21 '13 at 15:41
  • @Mark if you could make any reference to my answer, whether it helped you or anything - that would be great. – Benjamin Gruenbaum Aug 19 '13 at 21:02
  • @BenjaminGruenbaum - after numerous issues with socket.io I decided that "less is more" and went with engine.io (sock.js is also a good candidate), and basically doing everything with explicit messaging, not relying on any infrastructure features. Much much easier that way. – Mark Aug 20 '13 at 07:29

1 Answers1

41

The Real Underlying Issue

This issue isn't just limited to socket.io. It is a well known problem called the Two Generals' Problem.

Two armies, each led by a general, are preparing to attack a fortified city. The armies are encamped near the city, each on its own hill. A valley separates the two hills, and the only way for the two generals to communicate is by sending messengers through the valley. Unfortunately, the valley is occupied by the city's defenders and there's a chance that any given messenger sent through the valley will be captured (this scenario assumes that while the two generals have agreed that they will attack, they haven't agreed upon a time for attack before taking up their positions on their respective hills).

You are trying to reach Common Knowledge over an unreliable link.

At any stage of the communication over socket.io the link can be broken, and a callback can be sent but the other side could not be sure that it arrived.

What Can Be Done

You need to embrace the fact this is always a possibility. There is no trivial solution for this. This problem and its generalization are still actively studied in fields like Multi-Agent Systems research.

What can still be done in your specific case

There are some common approaches to mitigate this issue.

What I did when designing an application using socket.io is attach IDs to messages, if a disconnect happens and one side tried to send an already-sent message, the receiving side will be aware that the message was already received.

Note that in practice you don't need to do this everywhere.

More Reading on the Issue

Community
  • 1
  • 1
Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Yeah - now that I actually know and understand all the things I'm talking about here this answer isn't too helpful. You just use an ID and keep track of the last thing relevant on both ends and then synchronize - the link is reliable and byzantine faults won't happen anyway. – Benjamin Gruenbaum Jun 04 '15 at 06:15