BOINC Client Software Data Structures
From Unofficial BOINC Wiki
The central data types in the [{BOINC Client Software]] are:
PROJECT APP FILE_INFO APP_VERSION FILE_REF WORKUNIT RESULT
These correspond to the abstractions of the same name (see the section on Creating BOINC Projects). They contain some fields that aren't present on the server side; e.g., FILE_INFO has a field indicating whether the file is present on this Host.
Each of these classes has write and parse functions for converting an instance to or from XML. In some cases there are different variants depending on whether the repository of the XML is a scheduling server or the local client_state.xml file.
These structures are linked by pointers; for example, an APP_VERSION has a pointer to its APP.
PREFS
This class is a parsed version of the prefs.xml file; as such it doesn't contain any host-specific information. It contains a vector of partially-populated PROJECT objects, and parsed versions of user preferences.
CLIENT_STATE
This encapsulates the global variables of BOINC on this host. It is a parsed version of client_state.xml, represented as vectors of the basic types. It also includes some transient variables, such as sets of finite-state machines.
Contents |
[edit] Initialization
When the core client starts up (CLIENT_STATE::init()) it parses the prefs file, creating a PREFS object. (If there is no prefs file, it prompts the user for a project and account key, and creates one.) It then copies the vector of PROJECT objects to CLIENT_STATE.
Next, it parses the client_state.xml file. Any projects in this file but not in prefs.xml are ignored. As it parses objects that link to other objects, it looks up the referent (identified by name in XML) and installs a pointer.
[edit] Handling a Scheduler RPC Reply
A similar approach is used when handling the reply from a scheduling server RPC (CLIENT_STATE::handle_scheduler_reply). The RPC returns a interconnected set of basic objects, represented in a SCHEDULER_REPLY object. For each of these basic objects, we see (e.g. lookup_app()) if it's already present in the CLIENT_STATE structure. If not, we create and insert a new object, then link it (e.g., link_app()) to existing objects in CLIENT_STATE.
[edit] UCB Source
[edit] Copyright ©
- 2005 University of California
- 2005 Paul D. Buck
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
