No buttons should be necessary if the principle was implemented properly. I believe I have advocated the 'heartbeat' principle several times already. That would take care of everything. Make sure the clients can independently and unattended detect disconnect and automatically reconnect.
I second that.
This is what's implemented right now. When the client pings the server and it doesn't receive an answer it will show as disconnected. It will periodically attempt to reconnect. For sending solutions, there is no persistent connection, there are only connections made when the client tries to send solution data.
The problem is with some computers it seems like either the heartbeat or some other code is causing clients to crash when it gets disconnected. I haven't been able to reproduce the issue with any of the machines I have available to me here which is why the bug has been there for so long.
So you are implementing a change in DNS providers, at least that seems to be a viable attempt to rectify the issue and I for one prays that it works as I believe it may well do some good at a minimum.
"It will periodically attempt to reconnect." This is the problem: it will, but only a few times. It will stop trying after these few times and that's when the game will think it's connected while it's not. I'll have a guess here from what I've observed, either:
While the FoldIt client gets disconnected, my own IRC connection to the FoldIt server stays alive most of the time. My FoldIt client gets disconnected in an "ever" way even when I get disconnected from IRC only once, and I know IRC uses a mere ping.
You might consider checking whether all connections to the server in the client are either by IP or by dns. You may not experience local DNS issues. We occasionally will.
Today I was doing the Turkey Egg Lysozyme, on a second client. I finished the puzzle with an R71, but on my website is is recorded at R 231. This has never happened to me before. Recently switched over to Devprev, but am going to switch back to main.
That time was weird. Scores were not updated but I could see people talking in the chats from the client. Here's the logfile after I clicked on the green lamp
Error: Could not parse path/filename from: "puzzle_994167_time_1355821139.ir_solution" Error creating temporary file falling back to unsafe direct write of save data No object matching key 0. (~500 times) Autosaved puzzles/0000994167/0000261344/default/autosave.ir_solution. Autosaved puzzles/0000994167/0000261344/default/autosave-best.ir_solution. Autosaved puzzles/0000994167/0000261344/default/autosave-recentbest.ir_solution. Autosaved puzzles/0000994167/0000261344/default/autosave-creditbest.ir_solution.
Maybe I'm talking apples and oranges, in my case I can't get the clients to crash using Jean-Bob's technique. DNS change seems to have made no improvement, and my clients still stall when trying to refresh scores, forcing me to load a new client in which scores can be refreshed and closing out the old, stalled client which also often takes some work on my part. I can't say for certain that a recycle of the connection on the client would do any good, but I am certain that the stalled client is disconnected during the stalled event. Once the stalling occurs generally ( but not always ) when trying to update scores to ' shares ', the client becomes useless which might be considered a crash by some. To me it's just an event that the client isn't programmed to recover from properly, most likely due to the disconnection/stall.
Whether BP's heartbeat principle or my recycle connection button would do any good, I don't know, but I think I would try both just to be on the safe side with the hope that the heartbeat principle made the recycle connection button redundant. It seems to me at least, that we need some redundancy in the client.
My bad, it never crashes, it freezes ("No matching key 0" repeats ad lib, until I kill the process). I'll try and see if the error message in the log changes with different connection feats (which I doubt).