How does the server know when the client suddenly dies/disconnects due to network/power failure in SocketIO. Since the client wont have any chance to emit a disconnect event to the server... is there any way to solve this issue?
Socket.io has an internal keep alive mechanism. If a client disconnects abruptly, the server doesn't know about it immediately. Instead, when the next keep alive mechanism event will fire and no response will arrive within the time limit, the server will fire disconnect event for that client. The time it takes for the server to detect a client disconnected is affected from the keep alive polling intervals and the timeout limit.
You can change those values using 'pingInterval' and 'pingTimeout', which will change the way engine.io is configured.
Related
TLDR: do unacknowledged messages reset the timeout handler or not in nodejs tcp socket?
so does socket.setTimeout(60 * 1000) gets reset if we send a message that is not received or does it invoke the timeout listener?
Long Version :
so let's say we created a tcp server and a client in Nodejs, and we want to detect when the one of the sockets has lost internet connction, and since tcp won't auto close, we implemented a ping pong (client sends a ping every minute to server, server replies with pong), now to handle the logic that checks if the connection has indeed died I used a method were on the server we store that last ping time coming from clients, and every 2 min we check if any of them is older that 2 min we declare the connection dead and destroy the socket. and on the client, we set a timeout of 10 seconds (socket.setTimeout(10000)) that is reset when receiving a pong, which invokes the timeout handler, which declares the connection to be disconnected,my question is: let's say has died, so it won't acknowledge the client's ping, would this cause a timeout if the timer for the timeout is longer than the ping intervals?
The socket API (no matter if nodejs, C, ...) has no knowledge if the sent data got actually received or if they got lost. Sending data on a socket only puts these into the write buffer and then the OS kernel cares about delivery. A send is considered successful by the application if the data got successfully written into the write buffer.
This also means that the idle timeout is not affected by success or failure at the TCP level. If some kind of acknowledgement is required at the application level it must be implemented inside the application protocol. If such an acknowledgement is implemented by a the recipient sending some kind of receipt back, then this means socket activity and will thus also cause the idle timeout to be reset.
... we want to detect when the one of the sockets has lost internet connection
As for just detecting a broken connection one might also use TCP keep-alive.
I am using Flask-socketio python as a server and Javascript Socket-io as a client.
During emit event from server side client gets disconnected and reconnects again.
Due to this disconnection emit is not happening correctly.
How to keep the session alive or to avoid the disconnection?
And one more info I have tried testing it on win 7 pc, and there was no issue. On win 10 pc however the issue appears every time.
Is that related to an OS?
I am assuming that your emit event takes some time after the event handler is called (probably processing some data etc.).
If that is the case, increasing the ping_interval parameter on socketio instantiation will solve this issue.
Server is expecting the client to send a ping every "ping_interval" (default=25 seconds) and assuming your frontend app is not sending these pings, flask socketio server assumes the client has left after 25 sec and disconnects the client. But processing time inside the event handler is more than 25 sec and when the it is time to emit the data you see disconnect message since there is not client to be emitted to.
You need to change this value to a higher value to make it work.
socketio = SocketIO(app, ping_interval=50)
I am trying to get a handle on the various connection/disconnection events and how to use these to make sure that my application will always terminate gracefully.
I understand that socket.io will automatically attempt to reconnect a specified number of times. It is my understanding that as the connection goes down and subsequently reconnects there will be a disconnection event fired server side. I do not care about the connection temporarily going down so long as it comes back up at some point.
However if there is a more permanent disconnect, I do care about this and would need to update data such as connected users. I understand that on the client side you can get a reconnect_failed error object but I do not believe you can listen for this on the server. Is there any way to get notification on the server side that the connection is down and reconnection has failed? If so how does socket.io implement this?
I could issue a timeout upon a disconnection event server side that removes users if there is no reconnection. I could also have the server ping all connected clients at certain intervals. Are these kinds of solutions the only way to completely deal with all kinds of possible disconnections?
In my ASP.NET MVC app, the user clicks a button on the UI to make a phone call. An ajax request goes to the MVC app, which calls a phone dialer -- a method in library that calls an external component to make a call.
If a dialed call is terminated by the recipient of the call, the phone dialer component raises an event by calling an event handler in its own class.
I want to propagate that event to the client side so that it may update its UI.
An Option I Can't Use
I've looked at JavaScript Server-sent events. However, they are different from my situation in the way that in a JavaScript Server-sent event, here's what happens:
1) The client initiates a connection on a new socket to the server. The key difference being, the client initiates the connection.
2) The connection is held live and active until the server or the client want to terminate it.
3) The server has to be alive all throughout the time from the time the connection is made until the client or the server want to terminate the connection and no longer exchange notifications. This means that a new socket connection and consequently a new worker thread to service the notification exchange is used per client.
If I use server-sent events, I will have to make a server that stays alive. That means I will have to have a new action on a controller and a corresponding view that gets called at the very beginning and stays alive until the notification about the call hang-up is received.
This can not only be expensive, it is also counter-intuitive to my design as I do not want to be redirected to a new View just to listen to events.
Anyone have any other alternative?
You have to either use a WebSocket or Long polling. These both require you to set up a connection from the client to the server, additional to the normal HTTP cycle. And what else would you expect? When the page is sent, the communication between client and server is done. The HTTP cycle is over, no more data can float through. The new connection needs to originate from the client because the client does not allow arbitrary incoming connections.
I do not think there are other alternatives in normal case.
SignalR, etc, all require connection to be alive or periodically restarted by client. I am not aware of anything that allows server to initiate connection with a browser (it does not even seem technically possible due to proxies/firewalls etc).
Here's the scenario, I have a client side application, served by PHP on a different server to the node.js + socket.io application. It can connect and receive broadcasts sent from the server. If the connection drops, the application falls back to polling a database (using setInterval()). It attempts to reconnect every 5 polls, and it can successfully reconnect and continue to receive messages.
My problem occurs when the user loads the page and the node server cannot be reached (I turned it off for testing), I then turn on the server and on the 5th poll, it successfully connects to the server, using socket.socket.reconnect();. However, whenever the server broadcasts messages, it doesn't fire the event. Note that this doesn't happen when testing on a phone (which falls back to a different socket method)
I have already seen the question found here Reconnection in socket.io problem in `socket.on('message',function(){})`, however, the socket has not previously been connected so I don't think it could be the session?
EDIT: I changed the socket.socket.reconnect() to socket.socket.connect() and it fixed the problem. If someone could explain the reasons of why this works I'd like to know. I know its because the server isn't actually reconnecting, but would like more info.
Thanks.
well you possibly know the reason for this. server is not reconnecting. it is actually connecting. when you tell socket.io to reconnect it searches for the previous connection handle and thats where the problem arises.