以下是我迄今为止收集到的内容：
>可以提供回调,以便在确认消息时进行调用
>有一种特殊模式“挥发性”,不保证交付
>有一种不是“易变”的默认模式
这给我留下了一些问题：
>如果消息不易变,如何处理？它会被无限期缓冲吗？
>如果在合理的时间内无法发送消息,是否有任何通知方式？
>如果我想放弃,有没有办法解除消息？
关于如何在时间敏感的应用程序中使用Socket.IO而不回退到易失性模式并使用可提供故障事件和某种程度的可配置性的外部ACK层,我有点不知所措.或者我错过了什么？
解决方法
您寻求的交付确认与理论Two Generals Problem相关,这也在this SO answer中讨论过.
TCP通过保证无限重试后的交付来管理可靠性问题.我们生活在一个有限的宇宙中,所以“保证”这个词在理论上是可疑的:-)
除了理论之外,请考虑这一点：engine.io,socket.io 1.x的基础,使用以下传输：
> WebSocket
> FlashSocket
> XHR民意调查
> JSONP民意调查
每个传输都基于TCP,TCP是可靠的.因此,只要连接保持连接且传输不会更改,每个socket.io消息或事件都应该是可靠的.但是,有两件事可以在飞行中发生：
> engine.io可以改变运输
>如果底层传输断开连接,socket.io可以重新连接
那么当一个客户端或你的服务器在管道摆弄这样的情况下喷出一些消息时会发生什么呢？它没有在engine.io protocol或socket.io protocol(分别在版本3和4,在撰写本文时)中说.
正如您在评论中所建议的那样,实现中存在一些确认逻辑.但即使是简单的数字通信也具有非常重要的行为,因此我不相信无监督的socket.io连接可以为任务或安全关键操作提供可靠的交付.在可靠交付是其协议的一部分并且其方法已经独立且正式验证之前,这不会改变.
欢迎您采纳我的政策：
>编号我的消息
>如有疑问,请要求重新发送
>不要改变我的状态 – 客户端或服务器 – 除非我知道我已经准备好了
简而言之：
事实证明,保证消息传递确认是不可能的,但TCP保证了“无限”重试的传递和顺序.我对socket.io消息不太自信,但它们非常强大且易于使用,所以我只是小心使用它们.