Socket.IO确认交付

Question

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

以下是我迄今为止收集到的内容:

1. 可以提供回调,以便在确认消息时进行调用
2. 有一种特殊模式"挥发性",不保证交付
3. 有一个不是"易变"的默认模式

这给我留下了一些问题:

1. 如果消息不是易失性的,那么它是如何处理的？它会被无限期缓冲吗？
2. 如果在合理的时间内无法发送消息,是否有任何方式可以通知？
3. 如果我想放弃,有没有办法解除消息？

关于如何在时间敏感的应用程序中使用Socket.IO而不回退到易失性模式并使用可提供故障事件和某种程度的可配置性的外部ACK层,我有点不知所措.或者我错过了什么？

Answer 1

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

您寻求的交付确认与理论上的两个一般问题有关,这也在本SO答案中讨论过.

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

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

• 的WebSocket
• FlashSocket
• XHR民意调查
• JSONP轮询

每个传输都基于TCP,TCP是可靠的.因此,只要连接保持连接且传输不会更改,每个socket.io消息或事件都应该是可靠的.但是,有两件事可以在飞行中发生:

1. engine.io可以改变传输
2. 如果底层传输断开连接,socket.io可以重新连接

那么当一个客户端或你的服务器在管道摆弄这样的情况下喷出一些消息时会发生什么呢？它没有在engine.io协议或socket.io协议中说明(分别在版本3和4,在撰写本文时).

正如您在评论中所建议的那样,实现中存在一些确认逻辑.但即使是简单的数字通信也具有非常重要的行为,因此我不相信无监督的socket.io连接可以为任务或安全关键操作提供可靠的交付.在可靠交付是其协议的一部分并且其方法已经独立且正式验证之前,这不会改变.

欢迎您采纳我的政策:

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

简而言之:

事实证明,保证消息传递确认是不可能的,但TCP保证了"无限"重试的传递和顺序.我对socket.io消息不太自信,但它们非常强大且易于使用,所以我只是小心使用它们.