-
Notifications
You must be signed in to change notification settings - Fork 564
Websockets loop greatly slows down if a client WS lost due to Wifi dropout or change of SSID #922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I also encountered this problem. Didn't find a solution? |
The issue is still open, the developer has not commented. I have not spent any time on a solution myself, possibly one could use the heartbeat mechanisms to detect a lost WS client and then execute a close on the client link. |
That's what I did yesterday. I used enableHeartbeat(2000, 1000, 3) and the problem seemed to be solved. |
Hey good work. Can you post a code snippet showing the event handler you used along with enableHeartbeat. Thanks! |
I am writing a project for interaction via WI-FI between a device (ESP32) and a tablet (Android/Kotlin). ESP32 is responsible for the WebSocket server in STA WI-FI mode (communication occurs via a Mikrotik router) My problem was that the user with the tablet could move away to a long distance, due to which the connection to WI-Fi could be lost - this is how I came to the problem you described. Without using heartbeat, I noticed that disconnection detection could occur only after 1-3 minutes. Using heartbeat - disconnection detection occurs almost at the moment when the loss of connection to WI-FI began. It also turned out that the problem was more in the broadcastTXT function (because there were definitely attempts to send a message even to actually disconnected clients). Below is a piece of code that I use in my project to work with WebSocket. I hope this information will help you move forward in solving your specific problem. WebSocketsServer socket = WebSocketsServer(5555); socket.begin();
socket.enableHeartbeat(2000, 1000, 3);
socket.onEvent([&, this](uint8_t num, WStype_t type, uint8_t* payload, size_t length) {
if (type == WStype_DISCONNECTED) {
Serial.println("Client ID" + String(num) + " has been disconnected");
}
if (type == WStype_CONNECTED) {
if (this->syncReceiver) {
this->syncReceiver(num);
}
} else if (type == WStype_TEXT) {
String msg = this->parseMessage(payload, length);
msg.trim();
this->processMessage(msg, num);
}
}); |
I have a similar problem. When the client computer is suspended or put to sleep, the server websocket loop slows to a crawl for the remaining clients. I've tried wsMonCPU.enableHeartbeat(5000, 1000, 3); but that doesn't seem to make any difference. Each main loop takes about 45 seconds, where normally it would be 0.018 seconds. The heartbeat does not cause the disconnect of the client that drops off the network. The server still thinks that there are 2 clients attached although 1 has been shut down. After about 20-30 minutes of this crawling, it starts working normally again and is back to it's regular speed. |
Ref. #881 (comment) This is exactly the problem that I am experiencing. |
If I have 2 clients connected to the WSserver running on an ESP8266 and one of the clients turns off the computer or tablet, the server only is able to send out 1 ws message every five seconds. The server still thinks that there are 2 clients attached even thought one has gone without closing the browser properly. 5 seconds is the WEBSOCKETS_TCP_TIMEOUT = 5000. This is beyond my pay grade, so if anyone has suggestions ... |
One thing that I have found is that when a client device gets disconnected from the server and the server times out the heartbeat counters are not reset. When the client device tries to reconnect the server immediately disconnects the client because the old values still exist and the HB missed count increases each time the the device tries to reconnect. The debug output is below: (I have 2 websockets serving different parts of a webpage and I am broadcasting to all attached clients the information) My HeartBeat for both servers is: Each try at reconnecting the 21:16:09: [WS][0][sendFrame] pack to one TCP package... 21:20:37: [WS-Server][1][handleHeader] RX: Upgrade: websocket 21:20:58: handleFileList: / |
I forked this and made changes to get this problem solved. https://github.com/Gord1/arduinoWebSockets Pull request made. |
I have a websocket server running on an ESP8266. SSID = "something" Clients connect to something-WiFi, invoke a webpage and a websocket is established behind this. If the client closes the web page whilst still conneted to SSID-something, all is well. Multiple clients can connect/ disconnect like this.
BUT, if a client is on SSID-something with an open webpage (and so an open websocket) and then either the WiFi drops out or the client navigates to a different SSID-someOther then, after a few seconds, the whole websocket loop on the ESP greatly slows down permanently. The only recovery is a reboot.
Is there an error event I should handle? is there a way to detect 'lost clients' like this and terminate them on the ESP?
The text was updated successfully, but these errors were encountered: