-
Notifications
You must be signed in to change notification settings - Fork 14
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
Slow to reconnect after long local client disconnection. #214
Labels
bug
Something isn't working
Comments
Looks like node1.foldingathome.org is down, websocket connection is not able to establish. Error:
|
I know. Ideally we need this to be rock solid since it is the foundation of the client monitoring |
Yes, something was wrong. I restarted node1. I'm still investigating. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See original issue FoldingAtHome/fah-client-bastet#287.
If Web Control is open for some time and the local client is not running it will keep attempting to connect and keep failing. Each time the the connection fails it increases the error count in the browser for that connect. This causes the browser to delay the connections longer and longer. Then if the local client does restart, it can take a long time for Web Control to connect to it.
This can get much worse if the user is impatient and tries reloading Web Control, restarting the local client or even reinstalling. Leading to more and more user frustration. If left calmly alone Web Control and the local client will eventually start talking again.
This issue was noticed very early on. Web Control tries to mitigate this problem by canceling connection attempts early. The idea is that if the connection is cancelled then the browser may not consider it a failed connection and may not increase the delay. This seems to help somewhat but the browser's algorithm for backing of failed connection attempts is opaque and out of our control. Also, killing the connection too early might make things worse.
On possible solution to try is to have the client open multiple ports. Then Web Control could cycle through these ports one at a time.
The text was updated successfully, but these errors were encountered: