Socket.io: Continual “transport close” on client

Updated to socket.io v2.0.3. and still having the problem. It only seems to happen on one of my PCs. I also disabled the windows firewall, but the problem is still happening.

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!

Experiencing the same thing. I really don't want to have to go through a rewrite. Any one have any success with this issue?

I was really tired of this problem.
I think you guys should check the version of "socket.io" with "socket.io-client".
if server / client version is mismatch, the connection was very unstable.

I recommend simply using CDN like below for client.

@ref: https://cdnjs.com/libraries/socket.io

I hope it helps.

Feudal Wars dev?? It`s great.
I also have this problem too.
The user was disconnected randomly due to transport close and ping timeout.
I also tried changing many options (ping interval, ping timeout, transfer ...) but it does not work.
I checked the version of server and client's socket.io
Many people suffer from this issue, but I can't find any solution.

Any news on this problem, cuz i have the exact same problem!

I have the same issue as well when I deploy to k8ns but when I run locally it works fine.

I'm also suffering from this...

@talas9 @muhammadnasr @htamop the common questions to be able to debug / reproduce the issue:

• which version of the client / server are you using?
• which browser?
• is it reproducible with the fiddle?

Thanks!

I have tried it with 2.1.0 and 2.0.4 client and server. On chrome and safari (latest).
When I run locally it works fine (can be connected for over an hour without disconnect), but when I deploy to K8ns behind ingress loadbalancer, this issue happens...

FYI connection is closed exactly after 25 seconds every time, see screen shot

@talas9 @htamop @dnwldbs84 are you using a load balancer?

@darrachequesne Which load balancer(s) do you recommend using with socket.io ?

@muhammadnasr @darrachequesne
I used 2.1.0 sever and 1.0.0 client (android)
I need to keep connection stable for 8~9 hour but it unexpectedly disconnect.
I changed both version to 1.7.4 and 0.8.3? according other solution post. I will try test if it works well tomorrow

I had not used a load balancer. Both the client and server used the 2.0.3 version of Socket.io (I can't remember all version I used). I do not know which browser is causing the problem However, most users have used Chrome. In my case, the disconnect was randomely so it can't reproduce.
And I changed to ws. I am not sure if the problem is solved.

@muhammadnasr @darrachequesne @dnwldbs84
I think it is solved in my case.
I use 0.8.3 socket.io-client in android foreground service(api 26) and 1.3.5 version in nodejs server.
However, the problem might be not version.
I changed pingInterval in server to 10ms and it seems to work properly(ping timeout and transport close not occured)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

10 millseconds is too narrow, this way the network will be overwhelmed.

10 millseconds is to narrow, this way the network will be overwhelmed.

Correct!

@muhammadnasr any load-balancer should work. Please see the following examples:

• https://github.com/socketio/socket.io/tree/master/examples/cluster-haproxy
• https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx
• https://github.com/socketio/socket.io/tree/master/examples/cluster-httpd

Sticky-session is required though, if you enable polling (which is the default).

@darrachequesne I have the same issue, after like 8~9 hours the socket disconnects with the reason of "transport close"

I'm using:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

Had a same issue, was able to fix it using CDN from this comment https://github.com/socketio/socket.io/issues/3025#issuecomment-329024833 and setting timeout and interval like below:

io.set('heartbeat timeout', 60000);
io.set('heartbeat interval', 25000);

Hey,
We have the same issue with socket.io when it runs under Kubernetes and NGINX Ingress Controller.
When nginx configuration is reloaded, it recreates the process and all the existing communications are dropped, which caused the transport close, any other deployments that uses the ingress controller might cause the configuration reload

First of all really thanks for this awesome project.

Same issue here, maybe I'll bring your something new.

I have a ws server, and a ws client on node js.
This ws client is used from a node js app where is a service (micro service).

Other ws clients from web browsers (from client apps) are communicating through the ws server with this node js service.

Everything is working as expected.

On stress tests now (10 clients are asking intensively data), at the end of the tests, when all the jobs and transactions have been finished the connection of the service is closed with error "transport close". This is not happening always.

This is the config of the server:
pingTimeout: 15000,
pingInterval: 20000,
It looks like during the heavy load some ping(s) are lost...? or I don't know.
Is this something that I should expect?

Also, with the default config pingTimeout: 2000, I was getting this error in the middle of the stress test. This also was completely unexpected, but let's say that the server was overloaded and couldn't respond within 2secs(!) and we might get this error. But now with pingTimeout: 15000 it happens almost 50% and only after the end of the tests.

Hmho, I believe the micro-services should expected this kind of errors, even if they are running on the same lan, but the question is why is this happening?

I tried to create a small setup to reproduce this problem but I couldn't make it.

How to activate the logs? the DEBUG=socket.io* is not working. Although the variable is set, I don't get any output.

I strongly believe that this is related to #2924.
The reconnects on a client are caused by some browsers (safari and chrome) throttling timers for inactive tabs to save battery.
This results in delayed heartbeat messages from the client and the server closing the connection due to pingTimeout.
Increasing pingTimeout works to some extent but i still get reconnects in a production environment.

I have the same issue as well when I deploy to k8ns but when I run locally it works fine.

@muhammadnasr where you able to get past the deploy issue on K8s? I am experiencing similar issues.

@bheema01 just make sure you have stickysession enabled on your proxy/loadbalancer and it should work

Got same error

Same issue .....clients connect and disconnect repeatedly when server side socket endpoint is behind a load balancer. Even after configuring sticky sessions , issue still exists . @muhammadnasr were u able to resolve the issue.

I have seen this error, when the thread was blocked frequently for more than 200ms.
If this happens frequently this is bad for the socket.io _and for your app as well_.
The socket.io has a timeout to check the heartbeat of the connection.
If this timeout is exceeded then it shutdowns the connection and we get this error.

@varunSabnis after fixing sticky session, everything worked smoothly.

@dennisat I tried checking how long it took for my client to receive a pong packet. Every time it was beyond 200ms, which was tested both with socket server in the cloud and socket server on my localhost. The local setup doesn't disconnect the socket(everything works fine) , whereas in the cloud setup socket continually connects and disconnects. So , i don't think that's the issue.
@muhammadnasr okay , that's great. Have actually enabled it but still having some issues.

@muhammadnasr @darrachequesne @dnwldbs84
I think it is solved in my case.
I use 0.8.3 socket.io-client in android foreground service(api 26) and 1.3.5 version in nodejs server.
However, the problem might be not version.
I changed pingInterval in server to 10ms and it seems to work properly(ping timeout and transport close not occured)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

It works magically, thanks!!!!!!!

I find I got 'transport close' every ping interval.

I was really tired of this problem.
I think you guys should check the version of "socket.io" with "socket.io-client".
if server / client version is mismatch, the connection was very unstable.

I recommend simply using CDN like below for client.

@ref: https://cdnjs.com/libraries/socket.io

I hope it helps.

It works even more magically.
Seems that we can close this issue with your answer, haha

Finally, I figure out it's because of the version mismatching of client and server.
Everything works fine now when I make client and server share the same version of socket.io.

I think the ping pong logic might differ in different versions of socket.io, and the server didn't receive the ping event from the client side in ping interval, which gives the 'transport close' message.

I encountered the problem of socket.io disconnection every 30 seconds after deploying to Google Cloud Platform (GCP). It turned out to be a default http timeout used by the Global Load Balancer. The GCP documentation said you should change the value when using websockets. Instructions for changing the setting are here:
https://cloud.google.com/load-balancing/docs/backend-service#timeout-setting

still facing same issue on "socket.io": "2.2.0",
"socket.io-client": "2.2.0",

socket.io-client:socket close (ping timeout) +22s

Same here. The local server never gets a problem. But when deploying behind a load balancer, it has ping timeout randomly. Probably 1 in 50 times. I have tried to use the CDN version and adding the sticky session. The problem still exists.

Nothing worked for me besides some custom reconnect logic. If the client gets a socket open event with a different id than the previous one, send the server a reconnect event with the old & new id. Then on the server just update the socket id of the player and resend the game state.

@tmusaev could you post that custom reconnect logic for the client?

I have the same issue: 'transport close'

have the same problem. finally I resolve it. Nginx is my proxy server , but proxy_read_timeout of config is 60s , it indicates that if client or server doesnot emit any message in 60s , nginx will disconnect , so we can got that transport close errorMsg.

the solution:

1. increase the proxy_read_timeout to 600s or more
2. using setInterval to send some message at Front-end

"react": "16.8.3",
"react-native": "^0.59.9",
"socket.io": "^2.2.0"

I've used this library for chatting and to get some events. It works fine in ios but creates an issue in android. It lost socket connection anytime and re-connect. It continuously display same behavior. and also give this transport close or ping timeout error

"react": "16.8.3",
"react-native": "^0.59.9",
"socket.io": "^2.2.0"

I've used this library for chatting and to get some events. It works fine in ios but creates an issue in android. It lost socket connection anytime and re-connect. It continuously display same behavior. and also give this transport close or ping timeout error

+1

In our case, the issue is caused by CDN proxy. I solved this problem by connecting socket.io to the original site that was not CDN proxied.

We tackled this problem by updating the nginx ingress controller!

After reading several comments on different threads, I've tried pretty much all suggestions made in order to mitigate this transport close issue. Despite the versions I use on the client/server (currently 2.0.3), I get this behavior once I deploy my microservices using Kubernetes.
Currently, the server has the following configuration:

As others have mentioned, whenever I run the application locally there is no disconnection. I have read on a different thread that version 3 for socket.io will change the ping/pong so it's done for the server and this might help to fix this. Has anyone have any news or updates regarding this issue or a possible date for this new version?

I have seen this error, when the thread was blocked frequently for more than 200ms.
If this happens frequently this is bad for the socket.io _and for your app as well_.
The socket.io has a timeout to check the heartbeat of the connection.
If this timeout is exceeded then it shutdowns the connection and we get this error.

For those that are using Socket.IO to send large amounts of data, make sure to do it in a manner that doesn't block the thread. I encountered this today using the socket client on React Native and I'm using it to send files to the server. Because of how we wrote the sending of files through the socket, which is essentially all-in-one-go instead of sequentially, the JS thread gets choked and can't send a pong back to the server, disconnecting it, giving us this error.

I have same issue on my app, I don't think is ping pong issue. I doubt it should be issue cause by server side which closed the transport of socket.

The same problem. In an Angular browser.

This configuration has considerably reduced the number of reconnections :

I used forceJSONP because of cors

After my analysis, I found the below issue

ISSUE:
Sockets are working fine without any disconnects locally, but when deployed to environments sockets are disconnecting with "transport close" as disconnect reason.

I saw this issue only when running the node application using an upstart service or systemmd service, if we run the application like node app.js, I am NOT seeing this issue.

SIMPLE FIX/WORKAROUND:
On the client-side, on socket disconnect, socket emit add a user (angular 11)
self.socket.on('disconnect', (reason) => { if(currentUser){ self.socket.emit('add user', currentUser); } })

With the above scenario, all the users are always connected and online, will be disconnected when loggedout