socket.io服务器在注册客户端断开连接时非常延迟 [英] socket.io server very delayed in registering client disconnects

查看:137
本文介绍了socket.io服务器在注册客户端断开连接时非常延迟的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个使用xhr作为唯一传输的socket.io连接。当我在浏览器中加载应用程序(在chrome和ff中测试)时,套接字连接并且一切正常,直到我离开页面。如果我重新加载浏览器,我可以看到客户端发送'disconnect'事件,但服务器断开连接事件很长时间没有激活(大概是当客户端心跳超时)。这是一个问题,因为我在客户端断开连接时在服务器中进行了一些清理工作。如果客户端重新加载,我会在触发断开连接之前获得多个连接事件。我也尝试在窗口的'beforeunload'事件中手动从客户端发出断开连接消息,但无济于事。任何想法?

I have a socket.io connection using xhr as its only transport. When I load up the app in the browser (tested in chrome and ff), the socket connects and everything works well until I navigate away from the page. If I reload the browser, I can see the 'disconnect' event get sent out by the client, but the server disconnect event doesn't fire for a very long time (presumably when the client heartbeat times out). This is a problem because I do some cleanup work in the server when the client disconnects. If the client reloads, I get multiple connection events before disconnect is fired. I've tried manually emitting a disconnect message from the client in the window's 'beforeunload' event as well, but to no avail. Any ideas?

我调试了socket.io服务器,我可以确认Manager.prototype.onClientDisconnect只是因关闭超时原因而被点击。

I debugged the socket.io server, and I can confirm that Manager.prototype.onClientDisconnect is only getting hit for "close timeout" reasons.

推荐答案

经过一些调试后,我注意到socket.io Manager对象中的以下配置:

After some more debugging, I noticed the following configuration in the socket.io Manager object:

blacklist : ['disconnect']

这导致namespace.js中的这个分支不处理事件:

That causes this branch from namespace.js to not process the event:

case 'event':
  // check if the emitted event is not blacklisted
  if (-~manager.get('blacklist').indexOf(packet.name)) {
    this.log.debug('ignoring blacklisted event `' + packet.name + '`');
  } else {
    var params = [packet.name].concat(packet.args);

    if (dataAck) {
      params.push(ack);
    }

    socket.$emit.apply(socket, params);
}

此拉取请求中详细说明了更改 https://github.com/LearnBoost/socket.io/pull/569 。我理解为什么XHR适用于此,因为任何人都可以发送带有随机会话ID的HTTP请求,试图断开其他用户与服务器的连接。

The change is detailed in this pull request https://github.com/LearnBoost/socket.io/pull/569. I understand why this is in place for XHR, since anyone could send an HTTP request with random session IDs trying to disconnect other users from the server.

我打算做什么而是检查服务器中现有会话ID的每个新连接,并确保在继续连接逻辑之前运行我的断开逻辑。

What I plan to do instead is to check each new connection for an existing session id in the server, and make sure to run my disconnect logic before continuing with the connection logic.

这篇关于socket.io服务器在注册客户端断开连接时非常延迟的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆