Changes between Version 1 and Version 2 of AutoUpdate
- Timestamp:
- Apr 25, 2007, 12:29:44 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AutoUpdate
v1 v2 1 1 = Auto-update design = 2 2 3 A design for auto-update of the BOINC client software. 4 === Auto-updates come from projects === 5 A project wishing to provide auto-updates should offer a web interface letting users opt in or out. The auto-update mechanism uses BOINC's existing code-signing mechanism; update files are signed with the project's code-signing key. 6 === Version directories === 7 A 'version' of BOINC includes the core client, the Manager, the screensaver, and possibly other files, such as graphics files and XML skin description files. It also contains an 'updater' program. A version is stored under the project directory in a 'version directory' named '''boinc_MAJ_MIN_REL'''. 8 === Scheduler RPC changes === 9 A scheduler reply may contain an instruction to download and switch to a new version: 3 A design for auto-update of the BOINC client software. 4 5 == Auto-updates come from projects == 6 7 A project wishing to provide auto-updates should offer a web interface letting users opt in or out. The auto-update mechanism uses BOINC's existing code-signing mechanism; update files are signed with the project's code-signing key. 8 9 == Version directories == 10 11 A 'version' of BOINC includes the core client, the Manager, the screensaver, and possibly other files, such as graphics files and XML skin description files. It also contains an 'updater' program. A version is stored under the project directory in a 'version directory' named '''boinc_MAJ_MIN_REL'''. 12 13 == Scheduler RPC changes == 14 15 A scheduler reply may contain an instruction to download and switch to a new version: 10 16 {{{ 11 17 <auto_update> … … 25 31 </auto_update> 26 32 }}} 27 33 A scheduler request (in addition to existing fields for the core client's major/minor/release) has a new optional field 28 34 {{{ 29 35 <update_in_progress> … … 36 42 }}} 37 43 38 === Scheduler changes === 39 The scheduler should send an update request only if 44 == Scheduler changes == 45 46 The scheduler should send an update request only if 40 47 * the client has a version earlier than current; 41 48 * the client's version is at least 5.10 (or whenever this feature is added); and 42 49 * an update to the current version is not in progress. 43 50 51 === Core client changes === 44 52 45 46 47 === Core client changes === 48 Add -launched_by_manager flag; tells the core client that it was launched the the Manager. 53 Add `-launched_by_manager` flag; tells the core client that it was launched the the Manager. 49 54 50 55 The core client maintains an 'update command' structure, which is stored in the client state file. This structure exists only if an update is in progress. … … 52 57 On startup: if an update command is present in the client state file, and it matches the core client's version (i.e. this is the first time the core client is running after an update) remove the update command, and delete the version directory. 53 58 54 When processing a scheduler reply: if an <auto_update>element is present, create an update command structure.59 When processing a scheduler reply: if an `<auto_update>` element is present, create an update command structure. 55 60 56 61 When an update command exists, the core client attempts to download all the files listed in the update command. It stores these files in a version directory. When all the files have been downloaded, and all the signatures match, the core client does: 57 62 58 59 * If there is a GUI RPC connection from a local Manager, send it a command to exit. 60 * If there is a GUI RPC connection from a screensaver, send it a command to exit. 63 * If there is a GUI RPC connection from a local Manager, send it a command to exit. 64 * If there is a GUI RPC connection from a screensaver, send it a command to exit. 61 65 * Launch the updater program (the file marked as 'main program' in the update command structure). Pass it command-line arguments: 62 * --run_managerif there is a GUI RPC connection from a local Manager.63 * --run_coreif the core client was not launched from the manager64 * --run_as_serviceif the core client was running as a service (Windows).66 * `--run_manager` if there is a GUI RPC connection from a local Manager. 67 * `--run_core` if the core client was not launched from the manager 68 * `--run_as_service` if the core client was running as a service (Windows). 65 69 * exit. 66 70 67 71 The updater program does the following: 68 72 * Copy files from the version directory to the main BOINC directory. 69 73 * If 'launched_from_manager' exists, launch the Manager (it will launch the core client). Exit. … … 72 76 * If 'run_manager' exists, launch the Manager. 73 77 78 == Manager changes == 74 79 75 === Manager changes === 76 The reply to the get_cc_status() RPC (which is done every second) includes an optional <quit> tag. If present, quit. The authorize() RPC request includes a flag saying whether the Manager launched this client. 80 The reply to the `get_cc_status()` RPC (which is done every second) includes an optional `<quit>` tag. If present, quit. The `authorize()` RPC request includes a flag saying whether the Manager launched this client. 77 81 78 82 79 === Screensaver changes === 80 The screensaver periodically does GUI RPCs to the core client. Each GUI RPC reply includes an optional flag telling it to quit (this exists already). 81 === Pathological cases === 82 A user can enable multiple projects for auto-update. If an update is in progress, update commands for the same version from other projects will be ignored. 83 == Screensaver changes == 84 The screensaver periodically does GUI RPCs to the core client. Each GUI RPC reply includes an optional flag telling it to quit (this exists already). 83 85 86 == Pathological cases == 87 88 A user can enable multiple projects for auto-update. If an update is in progress, update commands for the same version from other projects will be ignored.
