Socket.io 延迟触发“断开连接”事件？
我有一个连接到 node.js 服务器的 socket.io 客户端。如果我在命令行杀死 node.js，客户端会立即冻结（即通信停止），但在触发“disconnect”事件之前会有大约 20 秒的延迟。这是设计使然吗？是否有配置选项可以减少触发断开连接事件的延迟？
看来这种行为在最近（最近 6 个月）的 socket.io 更新中发生了变化。在将重新连接功能内置到 socket.io 本身之前，我使用“断开连接”事件处理程序实现了自己的重新连接逻辑，当时，当服务器通信停止时，“断开连接”事件几乎立即触发。
I have a socket.io client connected to a node.js server. If I kill node.js at the command line, the client immediately freezes (i.e., communication stops), but there is a ~20 second delay before the "disconnect" event is fired. Is this behavior by design? Is there a configuration option to reduce the delay in firing the disconnect event?
It appears that this behavior changed in a relatively recent (last 6 months) update of socket.io. Before the reconnect functionality was built in to socket.io itself, I implemented my own reconnect logic using a "disconnect" event handler and at that time the "disconnect" event fired almost instantly when server communication halted.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这可能是一种设计模式。客户端可能会假设服务器“暂时”无法访问（网络流量等），并且本质上会继续尝试访问它......直到客户端超时开始。
我直接向服务器发送断开连接（socket.disconnect()）来自客户，我没有得到这个问题。
I think this is likely a design pattern. The client may be presuming the server is 'temporarily' unreachable (network trafic etc) and essentially will keep trying to reach it... until the client timeout kicks in.
I send a disconnect (socket.disconnect()) to the server directly from the client, and I don't get this issue.