unexplained disconnect 'transport end' after upgrading

[runvnc]

After adding a dependency to my package.json today I removed my node_modules and ran npm_install. I didn't specify any version number for socket.io so I guess it picked up the latest.

After I did that I noticed that within ? a minute or so of starting up my application, my socket would be disconnected and I see a 'transport end' info message in the node.js console output. I having socket.io set for websockets only. I am on Chrome 13 on Linux.

I went into package.json and set it at 0.8.7, ran npm install again, and now I am not seeing disconnects anymore.

Hopefully I wasn't just confused about something. I did go back and repeat the steps and had the same result. Sorry I don't have more specific information.

[rauchg]

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

[mokesmokes]

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.

[steffenwt]

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
});

[Josh1billion]

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

[matzipan]

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

[matzipan]

Downgrading to 0.9.0 works.

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

connect 
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

[untosil]

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
});

[asuth]

same problem here

[rauchg]

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

[gitawego]

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

[dervsh]

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); });

[rcadena]

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.

[konklone]

This issue should get closed, right?

[citosid]

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 👍

[jimwebb]

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.

[BoarK]

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.

[samsonradu]

@citosid why would haproxy client timeout cause this?

[lytespark]

Happening with 0.9.16. Same thing as for BoarK

[joefaron]

Is socket.io support dead?

[radicans]

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

[aran112000]

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

[joefaron]

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 notifications@github.comwrote:

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//issues/777#issuecomment-33325205
.

[aran112000]

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

[d-oliveros]

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

[joefaron]

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 notifications@github.comwrote:

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//issues/777#issuecomment-35177466
.

[rauchg]

Please try the new master, this issue is gone.

[rauchg]

I didn't.

[Neumann-Valle]

@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?

[odnarb]

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.js@v0.11.4
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.

[andrin-n-dream]

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.

[odnarb]

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.

[oniono]

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

oniono@naver.com 님께 보내신 메일 <Re: [socket.io] unexplained disconnect 'transport end' after upgrading (#777)> 이 다음과 같은 이유로 전송 실패했습니다.

---

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

---

[andrin-n-dream]

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.

[Pranoy1c]

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.

[odnarb]

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.

[ForgeableSum]

this is still happening on 2.0.3 ...
#3025

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

[ForgeableSum]

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?

[ForgeableSum]

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.

[ForgeableSum]

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.

[Neumann-Valle]

@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.

[ForgeableSum]

@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.

[Neumann-Valle]

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.

[ForgeableSum]

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

[Neumann-Valle]

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

As you asked for an example..

[ForgeableSum]

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.

[Neumann-Valle]

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

[ForgeableSum]

@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.

[Neumann-Valle]

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

Regards.

[ForgeableSum]

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"

[ForgeableSum]

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!

[MikeSB35]

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...

[darrachequesne]

Closed due to inactivity, please reopen if needed.

[namxam]

Well, I am seeing seeing the issue in 2021 when connecting from a 2.* client to a 3+ server. Quite annoying.

[darrachequesne]

@namxam did you enable the compatibity mode?

Reference:

• https://socket.io/docs/v4/troubleshooting-connection-issues/#The-client-is-not-compatible-with-the-version-of-the-server
• https://socket.io/docs/v4/migrating-from-2-x-to-3-0/