socket.io发射数据将断开客户端

socket.io发射数据将断开客户端

问题描述:

我正在聊天,我注意到有时候我的node.js服务器和iOS客户端之间的连接将在服务器发出一些数据后立即断开连接。socket.io发射数据将断开客户端

我emited连续两个事件的基础上,客户端上的日志,似乎发出的数据“组合拳”:

doQueue() >> 0 
2013-03-16 05:11:45.390 [833:907] start/reset timeout 
2013-03-16 05:11:45.491 [833:907] onData �187�5:::{"name":"threadInformation","args":[{"threadObjects":[{"threadId":"heacrsi1","users":[{"userName":"tester","userId":"123"},{"userName":"Name","userId":"123"}]}]}]}�171�5:::{"name":"message","args":[{"fromUserName":"tester","fromUserId":"123","text":"heiiiii this is going to trigger a message for u!","threadId":"heacrsi1","messageId":1}]} 
2013-03-16 05:11:45.493 [833:907] start/reset timeout 
2013-03-16 05:11:45.495 [833:907] disconnect 
2013-03-16 05:11:45.496 [833:907] onDisconnect() 

我可以一致地重现该问题。数据“结合”是否正常?为什么会发生这种断开连接?

编辑:我设法简化我的问题纳入很简单的东西:

这段代码是好的:

socket.on('online', function(data){ 
     socket.emit("message", {"testField":"testData2"}); 
    }); 

这段代码断开连接客户端!:

socket.on('online', function(data){ 
     socket.emit("message", {"testField":"testData"}); 
     socket.emit("message", {"testField":"testData2"}); 
    }); 

我们是否被允许连续发射东西到套接字?我是否应该自己实现某种队列以确保在发出下一个数据之前每个socket.emit都成功?

===== UPDATE =====

P/S 1:这只发生目标c客户端上。如果我使用JavaScript客户端,我可以收到这两个事件。

p/s 2:我设法在一个非常简单的设置中重现了这个问题: a。首先,一个连接发出时只发出两个事件的服务器: io.sockets.on('connection',function(socket) {0} }); socket.emit( “信息”,{ “文”: “!welcome3”});} b第二,一个简单的iOS客户端(使用socket.IO-OBJ库从这里:https://github.com/pkyeck/socket.IO-objc

从iOS版客户端输出
- (void) viewDidLoad 
{ 
    [super viewDidLoad]; 
    socketIO = [[SocketIO alloc] initWithDelegate:self]; 
    [socketIO connectToHost:@"192.168.1.87" onPort:5000 withParams:@{@"token":@"avalidtoken"}]; 
} 

C:

2013-03-21 01:13:39.355 SocketTesterARC[6391:907] Connecting to socket with URL:   http://192.168.1.87:5000/socket.io/1/?t=16807&token=avalidtoken 
    2013-03-21 01:13:39.620 SocketTesterARC[6391:907] didReceiveResponse() 200 
    2013-03-21 01:13:39.621 SocketTesterARC[6391:907] connectionDidFinishLoading()   fvSZFJMiIXop5uMayU0t:60:60:xhr-polling 
    2013-03-21 01:13:39.622 SocketTesterARC[6391:907] sid: fvSZFJMiIXop5uMayU0t 
    2013-03-21 01:13:39.656 SocketTesterARC[6391:907] heartbeatTimeout: 67.000000 
    2013-03-21 01:13:39.657 SocketTesterARC[6391:907] transports: (
     "xhr-polling" 
    ) 
    2013-03-21 01:13:39.658 SocketTesterARC[6391:907] xhr polling supported -> using it   now 
    2013-03-21 01:13:39.680 SocketTesterARC[6391:907] onData 1:: 
    2013-03-21 01:13:39.681 SocketTesterARC[6391:907] start/reset timeout 
    2013-03-21 01:13:39.683 SocketTesterARC[6391:907] connected 
    2013-03-21 01:13:39.684 SocketTesterARC[6391:907] onConnect() 
    2013-03-21 01:13:39.685 SocketTesterARC[6391:907] connected to server successfully 
    2013-03-21 01:13:39.686 SocketTesterARC[6391:907] doQueue() >> 0 
    2013-03-21 01:13:39.687 SocketTesterARC[6391:907] start/reset timeout 
    2013-03-21 01:13:39.698 SocketTesterARC[6391:907] onData �52�5:::{"name":"message","args":[{"text":"welcome2!"}]}�52�5:::{"name":"message","args":[{"text":"welcome3!"}]} 
    2013-03-21 01:13:39.700 SocketTesterARC[6391:907] start/reset timeout 
    2013-03-21 01:13:39.701 SocketTesterARC[6391:907] disconnect 
    2013-03-21 01:13:39.702 SocketTesterARC[6391:907] onDisconnect() 
    2013-03-21 01:13:39.708 SocketTesterARC[6391:907] disconnected! error: Error Domain=SocketIOError Code=-2 "The operation couldn’t be completed. (SocketIOError error -2.)" 
    2013-03-21 01:13:44.687 SocketTesterARC[6391:907] disconnect! 
+0

你有没有在字符串中的任何不良数据? – kobe 2013-03-14 21:35:01

+0

不,它们是正常数据。 – mkto 2013-03-15 03:32:50

+0

显示您的节点和客户端的代码。 – user568109 2013-03-15 04:26:29

一个小挖之后,APPEA rs问题已经归结为socket.io如何将多个消息分组到一个数据包中。

有两个问题(#65#83)描述了这个问题并进一步讨论了有关该问题的详细信息。

总之,socket.IO-objc库没有处理这些特殊情况,并且始终认为一个数据包只包含一条消息。参考

问题#65:

每过一段时间(期间重插座流量),服务器可以 决定发送在多个数据包在 单个轮询响应返回的有效载荷(如果例如使用xhr-polling)。它们是 由\ ufffd字符分隔的,并且包括各 包的字节长度,如:

�[packet_0 length]�[packet_0]�[packet_1 length]�[packet_1]�[packet_n 

长度] [packet_n]

目前,相信昂达仅仅处理数据 作为一个数据包,但有些情况下服务器在单个响应中发送多个 数据包。

注 是\ufffd字符。

A fix has been submitted较早,并且看起来在本贴子中进行了审查。