I have a web application where the user needs to be constantly connected. By default, socket.io will disconnect the connection after 60 seconds. I have 'reconnection' turned on though, so it is essentially closing and reopening the connection every minute. This can cause issues with feeds/notifications to my connected clients. Would it be safe to set this timeout to lets say, 10 minutes, or possibly higher? Is there a reason it is so low right now?
My guess is that you may be misinterpreting the 'close timeout' configuration. It does not cause the connection to be closed after 60 seconds. (Heartbeats would be pointless if clients constantly reconnected).
If a client disconnects, close timeout is the amount of time the server will wait before releasing resources associated with that connection. Essentially, this allows clients with intermittent connectivity issues to attempt to reconnect before the server has forgotten about them. Setting close timeout to ten minutes is probably a bad idea since it will tie up server resources.
If your clients are, in fact, disconnecting every 60 seconds, then, like samjm said, something else is wrong.
I don't believe your socket should disconnect after 60 seconds. I would investigate why that is actually happening. After handshaking correctly the socket should heartbeat and stay open indefinitely (barring network issues out of your control) until either the client or the server closes the connection, that is definitely my experience.
The fact that your connection is actually closing sounds like it may not be handshaking correctly, or heartbeats are not being received.
You might have already figured this out, but your socket might be disconnecting after 60 seconds because you're not sending a heartbeat ("2::") back to the server.
Here's some Python code that works with the websocket client module.
# on_message handles messages from the server
def on_message(ws, message):
if message[:3] == '2::':
ws.send('2::')
Related
I'm using node.js, websockets/ws.
In my site sometimes a random client loses connection without losing connection to other internet stuff. Less then a second later they connect back, with a new socket. (There is a code that calls socket.onClose, which tries to reconnect back to server)
On the server side I can't see or log anything wrong. Everything looks like a normal disconnect, same as closing the browser tab.
I am guessing the reason is either socket related or client related but I don't know where to begin to debug this problem.
I got ping/pong responses with 60 second timer, this isn't it. The user usually loses connection while active.
How can I debug this problem and find the reason?
I keep all the session info, data, within the socket and that is why I do not want people to lose their connection.
Thanks
In my express/socket app, (which is running behind HAproxy server), I am using sticky session(cookie based) to route requests to same worker. I have total 16 processes running (8 /machine- 2 machines). Socket session data is being stored in Redis adapter.
The problem I have is, when an event is fired from server, client can't receive it. Inspite, it will keep throwing disconnection errors, after every few seconds (4-5) :
Update : It will only fire event if transport was opened when event was fired, which is getting closed instantly, and than restarting.
Can someone please suggest something on this..
Finally, I found the solution. It was timeout client which was set to too low in HAproxy config. Increasing it, fixed the issue.
In Chrome, Socket IO seems to stop transmitting data. Is there an internal reason for this?
I've tried a very simple client and simple server side but consistently the server stops receiving any emits after 5 minute, will then reconnect and it's fine for another 5 minutes.
On top of the internal ping mechanism I have a polling mechanism which sends back session data every 20 seconds.
I don't use WebSocket with NodeJS or Socket.io but experienced the same behaviour with Jetty. It turns out that Jetty has an idle timeout default to 5 minutes (or 300 seconds) for all WebSocket's sessions. You could change the default idle timeout value to an appropriate value or ping/pong those connections before it timed out.
In my situation, I decided to use ping/pong as it also helps determine when the connection is no longer there. I observed that in some cases, connection was not closed even when the network is down.
According to engine.io (which is used by socket.io) docs, the server seems to have default pingInterval of 25 seconds. So unless you inadvertently disabled or changed default options, the ping/pong mechanism should be in place.
We have a client server application in use on our suse linux server.
Sometimes it happens, that on the client side the tcp socket somehow goes away and
on the server side the other end of the socket remains existent.
At the end of the day, when we stop the backend on the linux server, the backend tries to close all remaining tcp connections, also those "zombie" sockets.
(I watch this with strace).
When the backend tries to close a tcp connection, where there is nothing anymore on the client side, it sends a [FIN, ACK] packet to the target. And of course, nothing comes back.
The backend repeats to send this packet. The first time it waits only a few hundredths of a second to repeat it, then, it waits longer and longer. At the end it waits seconds to repeat it. But, after 15 seconds, there is a timeout, and it goes on to end another
tcp connection.
Now, I do not know where this 15 second timeout is coming from. I would like to change it.
Thank you very much in advance.
I think you may have two problems.
You should detect the client disconnecting and close the server's end of the socket so you free that resources ASAP. You may set a timeout yourself for connections with no activity in the application layer. Read this.
If you cannot handle that "zombie" sockets in the app layer you may change the timeout in the SO. Read this.
Socket.io allows you to use heartbeats to "check the health of Socket.IO connections." What exactly are heartbeats and why should or shouldn't I use them?
A heartbeat is a small message sent from a client to a server (or from a server to a client and back to the server) at periodic intervals to confirm that the client is still around and active.
For example, if you have a Node.js app serving a chat room, and a user doesn't say anything for many minutes, there's no way to tell if they're really still connected. By sending a hearbeat at a predetermined interval (say, every 15 seconds), the client informs the server that it's still there. If it's been e.g. 20 seconds since the server's gotten a heartbeat from a client, it's likely been disconnected.
This is necessary because you cannot be guaranteed a clean connection termination over TCP--if a client crashes, or something else happens, you won't receive the termination packets from the client, and the server won't know that the client has disconnected. Furthermore, Socket.IO supports various other mechanisms (other than TCP sockets) to transfer data, and in these cases the client won't (or can't) send a termination message to the server.
By default, a Socket.IO client will send a heartbeat to the server every 15 seconds (heartbeat interval), and if the server hasn't heard from the client in 20 seconds (heartbeat timeout) it will consider the client disconnected.
I can't think of many average use cases where you probably wouldn't want to use heartbeats.