node.js - Socket.IO 确认交付

Question

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

这是我到目前为止能够收集到的内容:

1. 可以提供回调以在消息被确认时调用
2. 有一种不保证交付的特殊模式“volatile”
3. 有一个默认模式不是“volatile”

这给我留下了一些问题:

1. 如果消息不是易变的，它是如何处理的？会无限期缓冲吗？
2. 如果无法在合理的时间内送达消息，是否可以通过任何方式收到通知？
3. 如果我想放弃，有什么方法可以取消缓冲消息？

对于如何在时间敏感的应用程序中使用 Socket.IO 而不回退到 volatile 模式并使用可以提供故障事件和某种级别的可配置性的外部 ACK 层，我有点不知所措。还是我遗漏了什么？

Answer 1

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

---

您寻求的交货确认与理论相关Two Generals Problem ，这也在 this SO answer 中进行了讨论。 .

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

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

• WebSocket
• FlashSocket
• XHR 轮询
• JSONP 投票

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

1. engine.io 可以改变传输
2. socket.io 可以在底层传输断开连接的情况下重新连接

那么，当管道系统像这样被摆弄时，客户端或您的服务器喷出几条消息会发生什么？ engine.io protocol 中均未说明或 socket.io protocol (截至撰写本文时分别为版本 3 和版本 4)。

正如您在评论中所建议的那样，实现中有一些确认逻辑。但即使是简单的数字通信也有不平凡的行为，所以我不相信不受监督的 socket.io 连接可以可靠地交付用于任务或安全关键操作。在可靠交付成为他们协议(protocol)的一部分并且他们的方法得到独立和正式验证之前，这不会改变。

欢迎您采纳我的政策:

• 给我的消息编号
• 如有疑问请重新发送
• 不要改变我的状态——客户端或服务器——除非我知道我已经准备好了

简而言之:

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