Socket.io: unexplained disconnect 'transport end' after upgrading

0.9.1 could have introduced a bug with heartbeats triggering premature disconnects.
I'm looking into it and might have a 0.9.2 tomorrow

Ditto. Seeing repeated disconnects/reconnects in Chrome & FF on Mac, client & server on same machine.
Easily seen from socket.io examples in the readme, default settings untouched.

Having the same issue...I also noticed that immediately after the socket disconnected a new socket was instantiated.

Workaround for me was manually setting the close timeout:

io.configure( function() {
    io.set('close timeout', 60*60*24); // 24h time out
});

I was having this problem too. Thanks steffenwt for the workaround.

Yep, I have this error too. I started learning socket.io a few days ago and I first thought I was doing something wrong.

Downgrading to 0.9.0 works.

Not sure if relevant, but the socket gets closed on every other heartbeat. So it goes like this

heartbeat2 gets sent and recieved all fine
heartbeat3 gets sens but never gets recieved
disconnect

Log here:

   debug - emitting heartbeat for client 18615332192056708826
   debug - websocket writing 2::
   debug - set heartbeat timeout for client 18615332192056708826
   info  - transport end
   debug - set close timeout for client 18615332192056708826
   debug - cleared close timeout for client 18615332192056708826
   debug - cleared heartbeat timeout for client 18615332192056708826
   debug - discarding transport

I has the problem too.

I use 0.91-1 .

I try it ,but has this problem.

io.configure( function() {
io.set('close timeout', 60_60_24); // 24h time out
});

same problem here

Did you downgrade to 0.9.0 ? I now marked it as latest on NPM

same issue here for 0.9.1-1, juste downgraded to 0.9.0, and the problem is gone.

as a workaround you can send some keep-alives from client, for say 20 secs and immediately answer those from server:

client: setInterval(function() { socket.emit("keep-alive", null) },20*1000);
server: socket.on('keep-alive', function (data) { socket.emit('keep-alive', null); });

FWIW: If you are serving the client from a different server, and your client code is not downgraded to 0.9.0 then you'll still see the problem.

I downgraded 'socket.io' to 0.9.0 and I still saw the problem. Then I downgraded socket.io-client to 0.9.0 and I don't get the disconnect.

Also, the transports I've tried that fail are web sockets and xhr-polling.

This issue should get closed, right?

I have the same problem. But I noticed that it is because I have haproxy.

My problem is here:

frontend all 0.0.0.0:80
    default_backend www_backend
    acl is_websocket path_beg /socket.io
    acl is_websocket hdr(Upgrade) -i WebSocket
    acl is_websocket hdr_beg(Host) -i ws
    timeout client 1000

Right in the line "timeout client 1000" (I changed it to 1 second to see if it was the problem, and it was...).

So now I'm searching if there is a way to change it only for the websocket backends.

I hope this help someone :+1:

FYI, I'm still seeing this issue, too, with xhr-polling and 0.9.14. There's a forced disconnect every 25 seconds. Log is identical to above.

I can also verify that this is happening with 0.9.14 server and 0.9 client. Although it doesn't disconnect every 25 seconds, it does disconnect intermittently. I traced it to a call stream.emit('end'); in node.js' _stream_readable.js. I think it is a result of reading EOF in the buffer.

@citosid why would haproxy client timeout cause this?

Happening with 0.9.16. Same thing as for BoarK

Is socket.io support dead?

@joefaron There has to be support before it can die. So no, Socket.IO support isn't dead, it just never existed.

Same issue here with Socket.io 0.9.16 - Seeing connections drop every ~25 seconds and logs showing "discarding transport" at the same time.

Downgrading to 0.8.6 fixed basically everything for me.. and i'm using
jsonp-polling instead of xhr-polling as a back up to websocket.. seems far
more stable.

On Sun, Jan 26, 2014 at 10:16 AM, Aran Reeks [email protected]:

Same issue here with Socket.io 0.9.16 - Seeing connections drop every ~25
seconds and logs showing "discarding transport" at the same time.

—
Reply to this email directly or view it on GitHubhttps://github.com/LearnBoost/socket.io/issues/777#issuecomment-33325205
.

Hi @joefaron, cheers for your help.

I've been playing about a little with the different config options this evening and will look further into it tomorrow but I can confirm the issue is with the heartbeat checks failing. These checks are in place to ensure connections to a user are still required and they haven't left without sending a disconnect for any reason.

I've been able to replicate this bug in both Firefox & the current stable build of Chrome (32.0.1700.76 m).

Initially I attempted to completely disable heartbeats as for our application they weren't really going to be required, this can be done as follows (according to the current docs although when I tried this it seemed to remove all the transport methods and ended up constantly crashing and restarting).
io.set('heartbeats', false);

As this failed, my next attempt was to increase the timeout between heartbeat requests which can be done using the following within your app.js:
io.set('heartbeat timeout', 99999); // 99999 being the time between requests in seconds - Default is 25, please choose your value as applicable for your applications

This worked a treat for our application as we don't care about client disconnects, this may not be a viable option in your environment though.

For anyone else with this issue in case it helps, my environment is as follows:
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

I think this is a really urgent / critical issue. Why hasn't it been resolved yet? Two years have passed since the start of this issue thread.

I'm also experiencing this issue:

NodeJS: v0.10.24
Socket.io: v0.9.16

d-oliveros: I highly suggest downgrading to 0.8.6. I haven't had this
issue.. and I don't think the latest build will be fixed in the near future.

On Sat, Feb 15, 2014 at 8:55 PM, d-oliveros [email protected]:

I think this is a really urgent / critical issue. Why hasn't it been
resolved yet? Two years have passed since the start of this issue thread.

I'm also experiencing this issue:

NodeJS: v0.10.24
Socket.io: v0.9.16

Reply to this email directly or view it on GitHubhttps://github.com/LearnBoost/socket.io/issues/777#issuecomment-35177466
.

Please try the new master, this issue is gone.

Will there be a 0.9.17 release that includes a fix for this issue?

@fgnass can you reproduce it with 1.0.0-pre?

@guille looks good so far! I'll let you know if ever occurs again.

Hi @guille is there any way that this fix can be introduced into 0.9.16? Just that we use node.js / socket.io in a well established production environment and I'll have a hard time in justifying using pre-release versions of any aspect of our platform. If a patch could be done for 0.9.16 or, if 1.0.0 is due to be released in the (very) near future, this would be far preferable.

+1 for @eggysplat

@aran112000 thanks for the heartbeat timeout workaround. Works for me on v0.9.16.

Actually I found the reason why I had this problem. Very embarrassing, I thought I was using v0.9.16 when in reality I was using v0.9.0 which had that bug. It was fixed in v0.9.2 by https://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7 and https://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296ae952609dfbbc7be28c3

Please make sure you don't have heartbeat interval larger than heartbeat timeout as it was in v0.9.0.

editing post so others might be made aware:

wasted a few hours of bug tracking, until i decided to test the problem with my mac. seems like my anti-virus on windows 8 was also blocking the connections and causing things to drop. after uninstalling it, everything works fine.

relevant post is actually here but quite hard to find.
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

I'm kind of starter to socket.io and that took me more than two days. After sending/receiving data, client disconnects and reconnects so socket.id value changes

socket.io:client client close with reason transport close +39s
socket.io:socket closing socket - reason transport close +44s
.
.
.
socket.io:namespace adding socket to nsp / +4.1m
socket.io:socket socket connected - writing packet +1s

Finally, I found that there is an exception inside a callback so socket.io silently disconnects and reconnects from the system.

socket.on('someEvent', function(){
    var a = null;
    a.b; //You won't be aware of this error, this error is suppressed and won't be shown on console. 
         //Moreover, it disconnects and reconnects
})

Also see this comment

So, it silently catches error and doesn't show me anything on the console. Why does it suppress the error and disconnect/reconnects without even notifying me?

1.3.5 errors still there

Is it?

Yes, the problem still exists in 1.3.5...

Problem Still exist

Yes the problem still is occurring in 1.3.5 please fix

I think this is a haproxy client timeout issue as @citosid has pointed out. Increase the haproxy client timeout for the websocket backend and this issue should be fixed.

I have the same issue, but I'm not using haproxy. Does anyone know the last version where this was working?

Okay, I am also getting reports that the issue is not 100% fixed in our system. Funny thing is that I could reliably reproduce the problem by setting "timeout client 1" in haproxy to one second, and experience the bug in our frontend.

Prompted by this I increased "timeout client" to a larger number and thought the problem would go away, as the socket.io keepalive / heartbeat would have enough time to refresh the connection. This assumption is most probably wrong, and I'll keep you guys posted if I find out more things.

I posted this on a stackoverflow post and for some of you this may resolve it:
"It appears that HackTimer.js and ccapture.js both replace window.setTimeout with a custom function. HackTimer.js seems to work okay if it executes before any other JavaScript. For ccapture.js you may want to try to make sure it is run as the first script. So, SocketIO first uses your browser's native setTimeout that then gets blown away by the custom setTimeout which breaks any of the currently running timers."

Search your code for to see if one of your libraries is replacing it:

ag 'window.setTimeout\s*='

You can also test in your console to see if setTimeout has been modified at all:

/native/.test(window.setTimeout) // returns true for the native function and false for a custom one

Does this bug still exits? I upgraded to the master version and any mobile device disconnect in about 2 minutes with Transport close notice..

This was what it make stir away from socket.io 1 > and kept me on socket.io 0.9.17 . But now i am trying again, set a ping pong manually on the server to keep it alive and now disconnects after 19 minutes.. the interval is every 35 secs..

If i run socket.io 0.9.17 this issue is not present.. but I don't want to use it anymore since is being deprecated. Any help, this happens in browser in mobile devices.

@utan what are the reproduction steps?

Hi @rauchg ,

Thanks for your reply..

1) Install socket.io 1.4.0
2) set nginx config to proxy

                        proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_http_version 1.1;
                proxy_pass http://io_nodes;

3) Set you client using socket.io 1.4.0 / 2015-11-28
4) Connect in a Mobile device..
5) Leave the mobile browser connected to you app then leave your phone idle.

then logs ;

  engine:polling compressing +0ms
  engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +95ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YVUt6&sid=DJNvvkhmCQew_3vGAAAB" +0ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +6s
  engine:polling closing +2ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +0ms
  socket.io:socket closing socket - reason transport error +0ms

You get disconnected after 3 4 minutes..

If using polling you get this error log;

 engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +106ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YXgi6&sid=skadf3It4qBRi0S0AAAC" +1ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +3s
  engine:polling closing +0ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +1ms
  socket.io:socket closing socket - reason transport error +2ms
  engine intercepting request for path "/socket.io/" +373ms
  engine handling "POST" http request "/socket.io/?EIO=3&transport=polling&t=L8YXhdB&sid=skadf3It4qBRi0S0AAAC" +0ms

So @rauchg closed it?

Really don't think you should.

I didn't.

@rauchg,
So is this a normal behavior for socket.io now? did something change in the WS protocol that now disconnect users in mobile devices if their are not plugin in and they idle?

I am banging my head to the wall with this issue it won't let me complete an upgrade.. and refactor my code with new socket.io...
My server Ubuntu 10.10
Nginx version: Nginx/1.8.0
Node v0.10.31 // if I upgrade to 4.0 is the same thing..

using https and Nginx proxing socket.io..

Is anyone else having the same issues or is just me?

I think I might be as well.. very difficult to pinpoint my case though. I'm using sails.js with socket.io.

ubuntu 14.04
node v5.3.0
npm v 3.3.12
sails.[email protected]
socket.io@~1.4.3

My client is a mix of socket.io-client and sails.io.js:

var socketIOClient = require('socket.io-client');
var sailsIOClient = require('sails.io.js');
var io = sailsIOClient(socketIOClient);
io.socket.on('connect', function(data){....})

So the initial connection lasts forever...but then after an .emit() or .broadcast() to this client, the server dumps the client after ~25 seconds to 1min AND..the client doesn't get notified of the disconnect. It thinks it's still connected.

Very frustrating.

I'm having a similar issue, but only if I use a secure socket (wss instead of ws). With ws everything works fine but with wss the connection gets dropped sporadically at random times (~15 minutes). No firewalls, no proxies.

Thank you @andrin-n-dream I think mine is related to SSL as well. I have a windows machine as the client and my ubuntu vm (same machine) as the server. Bridged network adapter. Never have had any issues with the general network connection.

Happens on SSL regardless whether I use nginx SSL or sails.js SSL termination.

NAVER - http://www.naver.com/

[email protected] 님께 보내신 메일

받는 사람이 회원님의 메일을 수신차단 하였습니다.

I debugged forever and could not find another solution for SSL but to reconnect manually. Would be great if engine.io would do this for me and retry when the transport is closed.

is there a solution for this? i am having the exact same issue. after a few seconds, i get a heartbeat timeout in the debug log from server but the client still thinks it's connected.

Well due to other pressing issues I have upgraded my env and this is now on the backburner. Would be nice to see if node 6.5.0 makes any difference. Sails.js has updated some packages and changed its use of these low-level functions...

I just don't have time to dive into this again right now as I'm migrating a massive amount of legacy C++. Maybe later this year or January.

this is still happening on 2.0.3 ...
https://github.com/socketio/socket.io/issues/3025

without a workaround, socket.io is basically unusable because 25% of your clients are going to have this problem.

io.set('heartbeat timeout', 99999);

@Aaron1011 Is this meant to be server-side or client code? If its server side, does anything need to be changed on the client end?

Tried:
io.set('heartbeat timeout', 99999);
On the server side and did not fix the problem using socket.io v 2.0.3. Gonna try downgrading to 0.8.6 next.

Could not downgrade to 0.8.6 because it indeed up being a massive rabbit hole. All the syntax has changed and since there is no documentation i could find on 0.8.6, it's a lost cause. I really don't feel like rewriting my app to downgrade to an ancient version on the hope that it might fix this issue.

Does anyone have any ideas/fixes for v2.03? Things I've tried:

• set pingInterval to 9999999
• set pingTimeout to 99999999
• sending messages automatically as a keep-alive. I send a message every 1 second, but still get the random disconnects.
• Disabled firewall
• Tried with XHR polling on/off
• Changed port from something random to 80

I'm positive it's not a coding error but is PC-specific as it happens on some and not on others. It might have something to do with the network adaptar.

@forgeableSun you should write ur app based on Primus, I refactored my app with primus and currently using socketJs with it..

Support some other project no need to change code in other to use any other real time project..

Regards.

@utan I'd love to try it. but how exactly do i switch from socket.io with one line of code? There doesn't seem to be any examples on switching from other frameworks.

npm install browserchannel --save

var primus = new Primus(server, { transformer: 'browserchannel' });

https://github.com/primus/primus/blob/master/README.md#supported-real-time-frameworks

Hope helps.

what does browser channel have to do with socket.io?

That's just an example how to switch to a different framework..

As you asked for an example..

okay, but socket.io is not even listed as one of the supported realtime frameworks. it's never just 1 line of code to switch APIs, I don't see how the docs can advertise that without giving any examples.

Listen, socket.io is buggy after >= 1 it has weird disconnects, me suggesting to use primus is so u can switch to a different framework..

That's why I gave u an example, of course u will need to refactor code to use primus then after u are gonna be free to try different frameworks to see which one is best for u or if one breaks then u use a different one..

Regards

@utan I see, I was thinking it was a transformer for switching from 1 framework to another with the entire app written in that framework (like an adapter). But really, it's a transformer for seamlessly switching to frameworks with the entire app written in primus.

Indeed, u went up my head.. i am not as proficient to know the difference, thought we were talking about same thing..

Regards.

My server logs:
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"
client disconnect. Reason for disconnect: "transport close"

Switched to ws (https://github.com/websockets/ws) which involved massive rewrites, but i now use the native websocket browser object on the client side and everything works perfectly. I no longer have the problem. So long socket.io!

I was getting random disconnects after 10 to 30 minutes. I recalled that my hosting service runs NodeJS with Passenger on an Apache shared server. I don't really understand it but basically there are meant to be issues with websockets in this kind of integration. I am testing with setting transports: ['polling'] only, while on the localhost I an run with transports: ['websockets', 'polling'] without errors and dropouts. So far so good after 30min...