Socket.io - nodejs 服务器端。重新连接后传输关闭

Posted 2023-04-18

【中文标题】Socket.io - nodejs 服务器端。重新连接后传输关闭

【英文标题】：Socket.io - nodejs server side. transfer close after reconnection

【发布时间】：2016-09-12 04:21:51

【问题描述】：

我有两个浏览器 socket.io 客户端。例如。客户端 A 和客户端 B，它们连接到一号房间。

我的电脑上发生了以下行为（安装了 nodejs 5，socket.io 1.4.5）： 我们假设两个客户端都连接到 Room One。当客户端 A 断开连接（丢失连接）并在超时后重新连接并且客户端 B 不使用 emit 向 Room one 发送消息时，则客户端 A 的原始套接字将关闭，传输原因为：超时。这对我有好处。我需要这种行为。

另一方面： 当客户端 A 断开连接（丢失连接）并在超时时间内重新连接并且客户端 B 在断开连接的时间内使用 emit 向 Room one 发送消息时，重新连接后客户端 A 的原始套接字将立即关闭，传输原因为：已关闭且未超时.

看起来有一些行为会在超时时间内选择断开连接的套接字，因为其他一些在线套接字尝试向同一个房间发出消息。当发出的消息无法传递到断开连接的套接字（在客户端）时，则可能选择此套接字以在超时时间内重新连接后立即关闭事务。

【问题讨论】：

你尝试过什么吗？

我想是的。我用其他方法解决了。我为在断开事件时执行的函数添加了 setTimeout。通过这种方式，我可以将数据从旧套接字存储到新套接字的变量中，因为在超时期间，新套接字会在 setTimeout 函数的限制内获取这些数据。

有人知道更好的解决方案吗？

【参考方案1】：

我注意到另一个问题。当移动客户端失去连接并且有人向连接移动客户端的房间发送发射时，移动套接字立即断开连接而不会超时，原因是 linux 上的传输关闭。

上述情况对于mac系统是不同的。如果客户端移动设备重新连接，则套接字会在超时消失或立即断开连接。

任何人都可以帮助解释相同版本的节点（6.2）和相同版本的套接字（1.4.6）上的这种行为不同的原因是什么？

【讨论】：

有人不知道解决办法吗？真的吗？