Socket.IO 确认交付答案

【问题标题】：Socket.IO confirmed deliverySocket.IO 确认交付
【发布时间】：2012-07-31 03:53:46
【问题描述】：

在我深入研究代码之前，谁能告诉我是否有任何文档可用于在 Socket.IO 中确认交付？

以下是我目前能够收集到的信息：

这给我留下了一些问题：

对于如何在时间敏感的应用程序中使用 Socket.IO 而不退回到易失性模式并使用可以提供故障事件和某种程度的可配置性的外部 ACK 层，我有点茫然。还是我错过了什么？

【问题讨论】：

以下是我通过浏览代码收集到的内容。请不要把它当作权威 - 在某些情况下我可能完全错了。
Socket.IO 不会重新发送任何数据。底层传输（即 TCP）有自己的重发机制，但 Socket.IO 不公开对它们的任何控制。
当（非易失性）消息通过未打开的传输在“套接字”上发送时，该消息将被放入队列中，以便在打开传输时发送。消息可以排队的时间似乎没有任何限制，尽管当“套接字”本身关闭时队列会被清除。
如果消息需要确认（回调），则会将条目添加到哈希表中，将消息 ID 映射到其回调函数。当并且如果返回确认数据包时，则调用回调。如果消息本身或确认被丢弃，回调将永远不会触发。
我发布这个问题已经快一年了，似乎没有人对此主题有任何补充。我希望能从更了解 Socket.IO 的人那里得到一些反馈。你可以把上面的笔记记下来，因为它们是令人毛骨悚然的，但目前我不知道我的结论当时或现在有多准确或相关。就我而言，这是一个悬而未决的问题。

【解决方案1】：

TL;DR 除非您愿意等到宇宙消亡，否则您无法获得可靠的确认交付。

您寻求的交货确认与理论上的Two Generals Problem有关，在this SO answer中也有讨论。

TCP 通过在无限次重试后保证传递来管理可靠性问题。我们生活在一个有限的宇宙中，所以“保证”这个词在理论上是可疑的:-)

抛开理论，考虑一下：engine.io，socket.io 1.x 的基础，使用以下传输：

这些传输中的每一个都基于 TCP，而 TCP 是可靠的。因此，只要连接保持连接并且传输不改变，每个单独的 socket.io 消息或事件都应该是可靠的。但是，有两件事情可能会即时发生：

那么，当客户端或您的服务器在管道被这样摆弄时喷出一些消息会发生什么？在engine.io protocol 或socket.io protocol（在撰写本文时分别为版本 3 和 4）中没有说明。

正如您在 cmets 中所建议的，在实现中有一些确认逻辑。但是，即使是简单的数字通信也没有不重要的行为，所以我不相信无监督的 socket.io 连接可以可靠地传递任务或安全关键操作。在可靠交付成为他们协议的一部分并且他们的方法得到独立和正式验证之前，这种情况不会改变。

欢迎您采纳我的政策：

简而言之：

有保证的消息传递确认被证明是不可能的，但 TCP 保证传递和顺序给定“无限”重试。我对 socket.io 消息不太有信心，但它们确实非常强大且易于使用，所以我只是小心使用它们。

【讨论】：

【解决方案2】：

我使用不同的策略确保交付

【讨论】：