我有一个场景与此示例非常接近:
一个主屏幕:
- 此屏幕(客户端)将通过server:9090/scope连接到socket.io服务器(io.connect("http://server:9090/scope)),并向socket.io服务器发送一个事件"userBindOk"(socket.emit("userBindOk", message)); - 服务器接收连接和"userBindOk"。此时,服务器应获取到rabbitmq服务器的活动连接,并将队列绑定到刚刚通过socket.io连接到应用程序的相应用户。示例: socket.on("connection", function(client){ //client id is 1234 // bind rabbitmq exchange, queue, and: queue.subscribe(//receive callback); }) - 到目前为止,没有问题 - 我可以通过socket.io无问题地发送/接收消息。
但是,如果我刷新页面,所有这些步骤都将再次执行。因此,绑定到队列将发生,但这次是与另一个socket.io客户端会话相关的。这意味着如果我向与第一个socket.io会话相关的队列发送消息(在页面刷新之前),那么该绑定应该(我认为)接收该消息并将其发送到无效的socket.io客户端(页面刷新=在socket.io上下文中的新client.id)。我可以证明这种行为,因为每次刷新页面时,我需要发送x倍的消息。例如:我第一次连接:-所以,1条消息-一个屏幕更新;刷新页面:我需要发送2条消息到队列,只有第二条消息将从“实际”的socket.io客户端会话中接收-每次刷新页面都会发生这种行为(20页刷新,20条消息发送到队列,服务器socket.io的“最后”客户端将向客户端socket.io发送消息以呈现在屏幕上)。
我认为解决方案是:
- 找到一种方法在与socket.io服务器断开连接时“取消绑定”队列-我还没有在node-amqp api中看到此选项(等待它:D) - 找到一种重连socket.io客户端并使用相同的client.id的方法。这样,我就可以识别即将到来的客户端并应用一些逻辑来缓存套接字。
有什么想法吗?我试图非常清楚...但是,正如您所知道的那样,在尝试澄清某个特定于某个上下文的问题时,很难表达您的问题...
一个主屏幕:
- 此屏幕(客户端)将通过server:9090/scope连接到socket.io服务器(io.connect("http://server:9090/scope)),并向socket.io服务器发送一个事件"userBindOk"(socket.emit("userBindOk", message)); - 服务器接收连接和"userBindOk"。此时,服务器应获取到rabbitmq服务器的活动连接,并将队列绑定到刚刚通过socket.io连接到应用程序的相应用户。示例: socket.on("connection", function(client){ //client id is 1234 // bind rabbitmq exchange, queue, and: queue.subscribe(//receive callback); }) - 到目前为止,没有问题 - 我可以通过socket.io无问题地发送/接收消息。
但是,如果我刷新页面,所有这些步骤都将再次执行。因此,绑定到队列将发生,但这次是与另一个socket.io客户端会话相关的。这意味着如果我向与第一个socket.io会话相关的队列发送消息(在页面刷新之前),那么该绑定应该(我认为)接收该消息并将其发送到无效的socket.io客户端(页面刷新=在socket.io上下文中的新client.id)。我可以证明这种行为,因为每次刷新页面时,我需要发送x倍的消息。例如:我第一次连接:-所以,1条消息-一个屏幕更新;刷新页面:我需要发送2条消息到队列,只有第二条消息将从“实际”的socket.io客户端会话中接收-每次刷新页面都会发生这种行为(20页刷新,20条消息发送到队列,服务器socket.io的“最后”客户端将向客户端socket.io发送消息以呈现在屏幕上)。
我认为解决方案是:
- 找到一种方法在与socket.io服务器断开连接时“取消绑定”队列-我还没有在node-amqp api中看到此选项(等待它:D) - 找到一种重连socket.io客户端并使用相同的client.id的方法。这样,我就可以识别即将到来的客户端并应用一些逻辑来缓存套接字。
有什么想法吗?我试图非常清楚...但是,正如您所知道的那样,在尝试澄清某个特定于某个上下文的问题时,很难表达您的问题...