Tweet
Important Notice!!!
Found this @ "TLC" :
Hey, Folks. Despite being in the throes of SETI@home server issues at the moment, here's a brief note, strictly FYI, about an interesting client/server problem we're facing and our proposed solution. This missive exists as a piece of entertainment as well as a warning.
We are currently planning to enforce a mandatory upgrade to version 3.X for all platforms and running into a few problems in the process, the worst being the many thousands of Windows clients earlier than 1.06 which are still active and returning results on a regular basis.
We never enforced an upgrade to 1.06 (or 2.X for that matter), which is why these clients are still able to return acceptable results. Now we have version 3.X, with vastly improved security and increased science, and we would like all users to obtain and use this version.
Most of our Windows users are using clients that, when we decide to make the new version available, will obtain messages from our server about the new version. First there will be warning messages saying there is a new client on the web site. After this "grace period" (an arbitrary amount of time we feel is appropriate), a different message from our server will cause the client to complain to the user that their current version is superceded and will stop attempting to contact the server, rendering it useless.
This functionality would be enough to allow for a smooth and painless transition, but we have discovered it doesn't work for some versions earlier than 1.06. What happens with these clients, more or less, is that they get stuck in a loop trying to contact our server, forever unable to get through and submit their current result.
This wouldn't be too terrible, except there are thousands of these old clients currently running. Once we turn the version warnings on, they will all eventually try to return their result and get stuck in a mode where they are contacting the server every few seconds, thereby clobbering it with requests. In other words, they will be DOS'ing their own server.
We thought up several solutions to this problem. Our main problem is that we have one server at one IP address which all clients contact. If one client is flooding the server, then nothing can get through. So we have to move the point of contact elsewhere.
So all new clients will be contacting the same server via a different host name. The new name evaluates to the same IP as the old name. When we decide to strictly enforce the upgrade, we'll remove the old name from the DNS maps. To the old clients, the server will seem to have disappeared. None of the traffic from these clients will ever reach the server.
While this will greatly clean up the traffic hitting the server, users who have not made the upgrade will no longer be getting polite warning messages - they will be faced with ugly numerical error messages and quit. However impolite, this is still our best solution to the above problem.
Also some ver. 3.0 GUI info by Eric Korpela!
Hi Everyone,
I'll let you know what I know about the bug in the Windows 3.0 version. It seems to be one of those pesky thread contention things again. The obvious symptom appears to be that the colored FFT graphs stop being displayed. We're not yet sure what happens to the computation thread when this happens. We've also had a few reports of systems hanging which could be a manifestation of the same problem, but we haven't been able to recreate that problem. The solution might be to go back to synchronizing the display of the FFTs with the computation if the screen isn't being blanked.
If you aren't seeing any problems with 3.0 you can continue to run it. If you haven't yet upgraded, we hope to have 3.01 out soon.
Sorry it took me so long to get this message out.
Eric Korpela
------------------
Join the MURC SETI team! | SETI @ MURC
Don't get even — get odd!
Hey, Folks. Despite being in the throes of SETI@home server issues at the moment, here's a brief note, strictly FYI, about an interesting client/server problem we're facing and our proposed solution. This missive exists as a piece of entertainment as well as a warning.
We are currently planning to enforce a mandatory upgrade to version 3.X for all platforms and running into a few problems in the process, the worst being the many thousands of Windows clients earlier than 1.06 which are still active and returning results on a regular basis.
We never enforced an upgrade to 1.06 (or 2.X for that matter), which is why these clients are still able to return acceptable results. Now we have version 3.X, with vastly improved security and increased science, and we would like all users to obtain and use this version.
Most of our Windows users are using clients that, when we decide to make the new version available, will obtain messages from our server about the new version. First there will be warning messages saying there is a new client on the web site. After this "grace period" (an arbitrary amount of time we feel is appropriate), a different message from our server will cause the client to complain to the user that their current version is superceded and will stop attempting to contact the server, rendering it useless.
This functionality would be enough to allow for a smooth and painless transition, but we have discovered it doesn't work for some versions earlier than 1.06. What happens with these clients, more or less, is that they get stuck in a loop trying to contact our server, forever unable to get through and submit their current result.
This wouldn't be too terrible, except there are thousands of these old clients currently running. Once we turn the version warnings on, they will all eventually try to return their result and get stuck in a mode where they are contacting the server every few seconds, thereby clobbering it with requests. In other words, they will be DOS'ing their own server.
We thought up several solutions to this problem. Our main problem is that we have one server at one IP address which all clients contact. If one client is flooding the server, then nothing can get through. So we have to move the point of contact elsewhere.
So all new clients will be contacting the same server via a different host name. The new name evaluates to the same IP as the old name. When we decide to strictly enforce the upgrade, we'll remove the old name from the DNS maps. To the old clients, the server will seem to have disappeared. None of the traffic from these clients will ever reach the server.
While this will greatly clean up the traffic hitting the server, users who have not made the upgrade will no longer be getting polite warning messages - they will be faced with ugly numerical error messages and quit. However impolite, this is still our best solution to the above problem.
Also some ver. 3.0 GUI info by Eric Korpela!
Hi Everyone,
I'll let you know what I know about the bug in the Windows 3.0 version. It seems to be one of those pesky thread contention things again. The obvious symptom appears to be that the colored FFT graphs stop being displayed. We're not yet sure what happens to the computation thread when this happens. We've also had a few reports of systems hanging which could be a manifestation of the same problem, but we haven't been able to recreate that problem. The solution might be to go back to synchronizing the display of the FFTs with the computation if the screen isn't being blanked.
If you aren't seeing any problems with 3.0 you can continue to run it. If you haven't yet upgraded, we hope to have 3.01 out soon.
Sorry it took me so long to get this message out.
Eric Korpela
------------------
Join the MURC SETI team! | SETI @ MURC
Don't get even — get odd!
.
Comment