When a phone browser has an open connection, and the user locks the screen, then at a certain point they will no longer have a WebSocket connection.
What events are fired when this happens? Is the WebSocket.onerror or WebSocket.onclose handler called, and if so, does this happen when the screen locks/the app is suspended, or when the app comes back up again?
(And bonus question: is this standardised, or do browsers behave differently, and if so, how?)
I've done some testing myself, and the answer seems to be: no events are fired. Although the connection does drop, no error or close events are fired, not even when the browser comes back up. Therefore, the main way to deal with this appears to be to periodically check the connection status, and reconnect if need be - with exponential back-off in case the connection drops server-side. (Or to have a library do this for you, though I haven't found a properly maintained client-side browser-based WebSocket library that does this yet.)
This seems corroborated by the author of this article:
Mobile devices introduce a new category of connection issues; if a mobile device is locked, goes to sleep or the application is moved to the background, an active WebSocket connection may become unresponsive and not close itself properly.
Related
I have implemented a chat service but it seems if a user keeps refreshing the page fast enough it can connect to itself. It is not exactly itself but the id of its previous session. Issue happens because on fast refreshes browser does not trigger io.disconnect. I have tried to solve it by attaching disconnect code to onbeforeunload event but it doesn't make much change. I don't want to fiddle with pingtimeout and pinginterval because those might interfere with reconnection abilities. Any ideas?
I believe you are mistaken. Those duplicate connections will be disconnected eventually. For connections that are established with the polling protocol it takes about a minute to detect a disconnected client.
I am setting up an MQTT/Websockets server, my client is an flutter app, which connects to the broker on main screen, and in other screens it sends and receive messages from the broker. My understanding of keepAlive is how often the client and server should share ping/pong, so they make sure the connection is still alive. being said, if my flutter app, connects to the broker in main screen, of 3600/1 hour keepAlive, and suppose to share and receive messages on other screens, if i disconnect the client from the internet for 2 minutes, and reconnect after that, it will not send/receive messages, maybe my understanding of keepAlive is not correct. Well, How would i structure my app/server to reconnect automatically to the internet as soon as internet connection is back and up again.
I have also tried On.Disconnect method, which i noticed it will never get called, and the app even though still thinks its connected to the broker.
I mentioned websockets, on the tags as i could do mqtt over websockets.
I see that no-one else has responded, so I'll try (however I'm new to this also).
Also, have you looked at the Flutter connectivity package?
From my reading of the Mqtt specification, it seems the Mqtt client ** should** disconnect the TCP/IP connection if it doesn't receive a PINGRESP to its PINGREQ in the keep alive period (ie it's not required to disconnect).
My Flutter + Mqtt app checks the connection state, and reconnects if needed, every time it sends a message. I haven't needed to check for internet dropouts, but I have noticed the connection is lost on some application state changes. The main app widget. is notified of these using didChangeAppLifecycleState() and sends a dummy message if needed.
So this doesn't answer exactly what you asked, but I hope it's useful anyway.
I am using socket.io 1.4 and I want to know that what happens in this scenario:
The client Emits like this:
Socket.emit('test',data);
The client does 3 emits to server but suddenly Internet speed drops and those emits may not get to server
But after a while the Internet speed rises again but what will happen to previous failed emits?
They will be emitted again automatically?
How should I handle that
Websockets use TCP, which is in general a reliable protocol. There is not exactly such a thing as "The internet speed dropped and I lost some messages." If some messages are lost they will be automatically retransmitted at the TCP level. If retransmission fails completely, the connection will be reset.
So what you really are asking is how socket.io handles this. And the answer is that it has some amount of reconnecting logic, and you may also want to monitor the connection in case it resets (hook up a listener for the disconnect event on the socket), if you want to take some extra action (like notify the user).
I would like to do some one way streaming of data and am experimenting with SSE vs Websockets.
Using SSE form a golang server I'm finding it confusing on how to notify the client when sessions are finished. (eg the server has finished sending the events or the server suddenly goes offline or client looses connectivity)
One thing I need is to reliably know when these disconnect situations. Without using timeouts etc.
My experiments so far , when I take the server offline the client gets EOF. But I'm having trouble trying to figure out how to signal from the server to the client that a connection is closed / finished and then how to handle / read it? Is EOF a reliable way to determine a closed / error / finished state?
Many of the examples with SSE fail to show client good client connection handling.
Would this be easier with Websockets?
Any experiences suggestions most appreciated.
Thanks
The SSE standard requires that the browser reconnect, automatically, after N seconds, if the connection is lost or if the server deliberately closes the socket. (N defaults to 5 in Firefox, 3 in Chrome and Safari, last time I checked.) So, if that is desirable, you don't need to do anything. (In WebSockets you would have to implement this kind of reconnect for yourself.)
If that kind of reconnect is not desirable, you should instead send a message back to the client, saying "the show is over, go away". E.g. if you are streaming financial data, you might send that on a Friday evening, when the markets shut. The client should then intercept this message and close the connection from its side. (The socket will then disappear, so the server process will automatically get closed.)
In JavaScript, and assuming you are using JSON to send data, that would look something like:
var es = EventSource("/datasource");
es.addEventListener("message", function(e){
var d = JSON.parse(e.data);
if(d.shutdownRequest){
es.close();
es=null;
//Tell user what just happened.
}
else{
//Normal processing here
}
},false);
UPDATE:
You can find out when the reconnects are happening, by listening for the "close" event, then looking at the e.target.readyState
es.addEventListener("error", handleError, false);
function handleError(e){
if(e.target.readyState == 0)console.log("Reconnecting...");
if(e.target.readyState == 2)console.log("Giving up.");
}
No other information is available, but more importantly it cannot tell the difference between your server process deliberately closing the connection, your web server crashing, or your client's internet connection going down.
One other thing you can customize is the retry time, by having the the server send a retry:NN message. So if you don't want quick reconnections, but instead want at least 60 seconds between any reconnect attempts do this have your server send retry:60.
This should work if multiple windows are open.
My application is in J2EE.
I already tried some javascript like on window.unloadn but this kind of solution is not solid.
If you mean on the server side, the best way is to implement a heartbeat. If none of the windows from this webapp are open, nothing sends a heartbeat, and a server after some time will know the app is disconnected.
If you mean on the client side, there's no 100% reliable way, since the browser might die from external causes (kill/crash/reboot), but a timed-out cookie that is updated regularly in a heartbeat-like fashion might work
HTTP is a stateless, meaning you can't tell when a browser is closed.
Your attempt to use window.onunload does not always work because the browser could exit before executing your event handler.
The technology used to find out if a user has closed their browser (or a best guess) is to use timeouts. Sessions will automatically timeout (this is configurable) - in asp.net the default is 20 minutes. If there is no activity, the timeout kicks in.