how do I find out why the client disconnected?

[Eliss Parke]

I have about 10-20 concurrent connections to socket.io from chrome and
android. I've set closeTimeout and timeout for all 6 protocols via
socketOptions (code below). I sent about 10kb of data through the
sockets per send(). however, I get disconnects about once every minute
or two on the client-side. any idea how I can start debugging this?

var socketOptions = {
transportOptions: {
'flashsocket': {
closeTimeout: 1000000,
timeout: 100000
}, 'websocket': {
closeTimeout: 1000000,
timeout: 100000
}, 'htmlfile': {
closeTimeout: 1000000,
timeout: 100000
}, 'xhr-multipart': {
closeTimeout: 1000000,
timeout: 100000
}, 'xhr-polling': {
closeTimeout: 1000000,
timeout: 100000
}, 'jsonp-polling': {
closeTimeout: 1000000,
timeout: 100000
}
}
};
var socket = io.listen(app, socketOptions);

[tapwater]

Are you trying to say your connections disconnect at random times? I'm
having that same problem. No errors, just an oddly normal disconnect.
It happens occasionally on Chrome web sockets, and much more often in
Firefox and IE xhr-polling.

[Dmitry Unkovsky]

I confirm that for websockets on Chrome. Random disconnects at random
times even when the data is continuously sent, say, tens of bytes once
per second.

--
DU

[Tad Glines]

It's possible you are running into the internal send buffer limit. There is an internal send buffer that the browser maintains for each web socket. If that buffer gets filled, the socket is closed. If the server can't read the data faster than the client can send, then you'll eventually max out the send buffer and the browser will close the socket.

When I looked at the source for WebKit, it looked like the default buffer size was 100M, which seems like overkill to me. But it's possible that in Chrome that has been changed.

Set a break point in "WS.prototype._onClose" and then examine the value of socket.bufferedAmount and see how big it is.

-Tad

[Gilbert B Garza]

I don't think that's the cause of the random disconnects. The socket disconnects regardless of how much data it's sending to the server, including when it's sending very little or none at all.

The worst part about this bug is that there is no indication or error message; it looks like a plain, normal disconnect.

[Tad Glines]

On Thu, Feb 17, 2011 at 6:45 PM, Gilbert B Garza <gilber...@gmail.com> wrote:

The worst part about this bug is that there is no indication or error message; it looks like a plain, normal disconnect.

This is one of the things I HATE about the current WebSocket spec. It explicitly states that the implementation provide no reason for the disconnect.

-Tad

[Gilbert B Garza]

The same thing happenings with xhr-polling, though. Should that be silent as well?

[thesec]

Not sure if I am climbing the wrong tree here ... but ...

On the client Socket.IO.Transport['XYZ'].timeout is only reset when data are received from the server.
If no data are received the lib raises a 'disconnect' event and it seems like a regular disconnect while the connection is actually left open.

Is Socket.IO missing a proper timeout handling including connection shutdown here?
Shouldn't this be a 'timeout' event instead?

Best,
Stefan

[Joseph Mordetsky]

Hmm, yikes - so - seems this is related to DNode, I set up a sample with just Socket.IO and I don't see the problem. IE 9 does seem to disconnect after a few hours of pinging, but I suspect that it is something else. Sorry for the misfire.

On Tue, Mar 29, 2011 at 6:33 PM, j03m <jmord...@gmail.com> wrote:

I definitely see the behavior as well. I have a dnode (uses socket io)
ping sample that is sending the word "ping" in an interval. If I open
up firefox 4 and chrome and let them both run after about 5 seconds
the chrome client will disconnect

[j03m]

I definitely see the behavior as well. I have a dnode (uses socket io)
ping sample that is sending the word "ping" in an interval. If I open
up firefox 4 and chrome and let them both run after about 5 seconds
the chrome client will disconnect

On Mar 24, 10:30 am, thesec <der...@googlemail.com> wrote:

[The Yak]

I also see this issue. Here is a log of 2 users connected via FireFox
which is using xhr-multipart (FlashWebSockets aren't working for some
reason) over the course of about 10 minutes:

30 Mar 22:23:18 - Client 8049989403225482 disconnected
30 Mar 22:23:26 - Initializing client with transport "xhr-multipart"
30 Mar 22:23:26 - Client 15185618866235018 connected
30 Mar 22:23:53 - Client 15185618866235018 disconnected
30 Mar 22:23:53 - Couldnt find client with session id
"15185618866235018"
30 Mar 22:23:53 - Couldnt find client with session id
"15185618866235018"
30 Mar 22:24:00 - Initializing client with transport "xhr-multipart"
30 Mar 22:24:00 - Client 398929410148412 connected
30 Mar 22:24:20 - Client 398929410148412 disconnected
30 Mar 22:24:20 - Couldnt find client with session id
"398929410148412"
30 Mar 22:24:20 - Couldnt find client with session id
"398929410148412"
30 Mar 22:24:27 - Initializing client with transport "xhr-multipart"
30 Mar 22:24:27 - Client 9728814959526062 connected
30 Mar 22:24:37 - Client 9728814959526062 disconnected
30 Mar 22:24:44 - Initializing client with transport "xhr-multipart"
30 Mar 22:24:44 - Client 2513725741300732 connected
30 Mar 22:25:07 - Client 2513725741300732 disconnected
30 Mar 22:25:07 - Couldnt find client with session id
"2513725741300732"
30 Mar 22:25:07 - Couldnt find client with session id
"2513725741300732"
30 Mar 22:25:14 - Initializing client with transport "xhr-multipart"
30 Mar 22:25:14 - Client 0039018818642944098 connected
30 Mar 22:26:20 - Initializing client with transport "xhr-multipart"
30 Mar 22:26:20 - Client 9878578402567655 connected
30 Mar 22:26:32 - Client 9878578402567655 disconnected
30 Mar 22:26:49 - Initializing client with transport "xhr-multipart"
30 Mar 22:26:49 - Client 976858209585771 connected
30 Mar 22:29:59 - Client 6694342836271971 disconnected
30 Mar 22:30:39 - Client 0039018818642944098 disconnected
30 Mar 22:30:54 - Initializing client with transport "xhr-multipart"
30 Mar 22:30:54 - Client 814253673190251 connected
30 Mar 22:31:46 - Client 976858209585771 disconnected
30 Mar 22:32:01 - Initializing client with transport "xhr-multipart"
30 Mar 22:32:01 - Client 17119933501817286 connected
30 Mar 22:32:39 - Client 814253673190251 disconnected
30 Mar 22:32:54 - Initializing client with transport "xhr-multipart"
30 Mar 22:32:54 - Client 12161057512275875 connected

I'm definitiely discouraged by the number of disconnects. It appears
that heartbeats are sent about every 10 seconds. I'm using the default
timeouts, which appear to be 25 seconds for xhr-polling.

Node 0.4.3 (Couldn't get 0.4.4 to compile)
Socket.IO 0.6.17

[The Yak]

Continuing post from above. I don't use dnode or any other modules
outside socket.io and modules that come with node.

[reda]

Hi,

I'm facing the same problem here with Chrome 11.0.696.57 beta and

After few seconds and 4 or 5 xhr long polling request the client get
disconnected.

Is there a bug report on this issue?

Thanks

[Xavi Ramirez]

I ran into the same problem. I ended up writing my own reconnection logic.

[Guillermo Rauch]

This should be fixed really soon. Sorry about this!

-- 
Guillermo Rauch
http://devthought.com

http://learnboost.com