Many of you who have worked with the boinc code, and/or read my comments have seen me reference the ‘client_state.xml’ file can probably skim over most of this, if not skip it entirely.
For anyone wanting to understand what’s going on inside Boinc, here’s the scoop.
There is a ‘client_state.xml’ file is the boinc equivalent to a ‘Windows registry’ for Boinc. (you’ll find it in your boinc folder/directory right next to the boinc_gui.exe if you have windows)
It contains all the info about boinc that is needed to authenticate you (part of the new security/anti-cheating mechanism) to the servers as well as the work you have downloaded and are currently running… It literally is the ‘Client State’ (or ‘Client Status’).
At the very beginning, it shows the info about the host itself (your host id), performance benchmarks, and your client key. It also contains the critical authentication codes which BOINC must have to validate you wherever you go within the BOINC project system. Without all of this information authenticating together as a whole, BOINC will not operate.
After that, you will find each ‘project_section’ which corresponds to each project the PC is ‘attached’ to. Within the project section are more authentication keys, host info preferences (venue, etc), but most importantly, it contains the files (Work Units) you’ve been assigned and downloaded, processed, have waiting to upload, and ‘ready to report’. It contains the state (aka status) of each. It keeps track of every file uploaded or downloaded until the file is properly returned to the server and an ‘update’ is performed and ‘succeeds’. Once the ‘update’ is successfull… the info is removed… that is why ‘ready to report’ is used… it lets us know the server and our PC need to be syncronized.
The reason for the ‘update’ (and syncronize) becomes obvious with my next statement.
If I said ‘master file sync’ == ‘update’… it all starts becoming clear… sync between server and client.
The ‘Master File’ is (for lack of a better explanation and avoidance of a thesis) the project’s section of your ‘client_state’ file + your host_info copied up at the server and stored in the server’s database.
When you hit ‘update’ you are syncronizing the project_section and host_info with the server. Each BOINC project does this for its section and your host. The two have a mechanism for resolving differences about work assigned, completed, uploaded, preferences, and eventually ‘reported’.
There are security mechanisms in BOINC which prevent it from doing anything without first getting a copy of the ‘master file’ from the server and comparing specific info with what should be on your PC. This is also how you get your preferences changed… it is transferred via a master file - client state syncronization.
So… master file fetch failures basically tell you that your PC could not get the copy of client_state that it saved on the server (timeouts, corrupt communications, whatever). We all know that BOINC won’t go any further until the Master File is retrieved and validated.
Referencing specificially Seti…
We all know the servers are way behind in granting credits and handing out work. This is the first sign of system overload. The next level is when you cannot ‘update’ or ‘master file fetch’… nothing moves. We either run out of work, or preferences don’t update, etc etc. Eventually, this will all be worked out. The servers will smooth out and communication problems a thing of the past.
(anyone remember the problems with P@H and the notes that followed on the web page? If you think back, you’ll see the similarities).
The little note this morning about blocking the site by Seti is 100% credible, even if brief. The fact internet security is taken seriously in California is common. I am writing to you now from behind my personal firewall, and TWO ‘black hole’ firewalls plus one more firewall that I know of. The reason is : Eastern Asia (and all those hackers out there) come ashore in California. With the technology and unbelievable bandwidth available in the state alone, security has to be tight.
I, for example, work on a completely closed campus. period.
I hope I did not bore anyone and took some of the mysteries of BOINC and how it works internally away.
If anyone has any questions, or I’ve made errors/typos, please don’t hesitate to contact me.
Chuck
