Socket.IO确认交付

在我深入了解代码之前,有人能告诉我是否有任何可用于Socket.IO确认交付的文档?

以下是我迄今能够搜集到的信息:

  1. 当消息被确认时,可以提供callback来调用
  2. 有一个特殊模式“易变”,不保证交付
  3. 有一个默认模式不是“易失性”

这给我留下了一些问题:

  1. 如果消息不稳定,它是如何处理的? 它会被无限期地缓冲吗?
  2. 如果邮件无法在合理的时间内传递,是否有任何方法可以通知?
  3. 如果我想放弃,有什么办法可以缓冲消息吗?

对于如何在时间敏感的应用程序中使用Socket.IO而不回落到易失性模式以及使用可提供故障事件和一定级别的可configuration性的外部ACK层,我感到有些不知所措。 还是我错过了什么?

TL; DR除非你愿意等到宇宙去世,否则你不可能有可靠的证实。


你所寻求的交付确认与理论上的两个将军问题有关 ,在这个答案中也讨论了这个问题 。

TCP通过在无限重试之后保证交付来pipe理可靠性问题。 我们生活在一个有限的世界里,所以“保证”这个词在理论上是可疑的:-)

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

  • 的WebSocket
  • FlashSocket
  • XHR轮询
  • JSONP轮询

这些传输中的每一个都基于TCP,TCP是可靠的。 所以只要连接保持连接,传输不会改变,每个socket.io消息或事件应该是可靠的。 但是,有两件事情可以在飞行中发生:

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

那么当一个客户端或者你的服务器正在用这样的方式弄乱pipe道时,会发出几条消息呢? 它没有在engine.io协议或socket.io协议中说明 (分别在本文的第3和第4版中)。

正如您在评论中所build议的那样,在实施过程中有一些确认逻辑。 但即使是简单的数字通信也具有无与伦比的行为,所以我不相信一个无监督的socket.io连接可以为任务或安全关键操作提供可靠的传输 。 直到可靠的交付是其协议的一部分,并且他们的方法得到了独立和正式的validation,这一切都不会改变。

欢迎您采取我的政策:

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

简而言之:

有保证的消息传送确认是不可能的,但TCP保证在给予“无限”重试的情况下传送命令。 我对socket.io消息不太自信,但是它们非常强大,易于使用,所以我只是小心使用它们。