Problems and proposed solution in multi-platform schem

[romw]

Version 5.9.5 of the BOINC client adds the ability for a host to run applications of more than one platform. For example, a Win64 machine can run Win64 or Win32. This is implemented as follows: a scheduler request contains a list of platforms, in order of decreasing preference. The scheduler (starting with SVN revision 12512) sends jobs along with the application version of the highest-ranking available platform.

However, there are problems stemming from the fact that the client was written with the assumption that it would only run apps of a single platform. Thus, it identifies app versions only by the pair (application, version number). If a scheduler sends it an app version with the same app and version number but a different platform, it will ignore it.

This leads to a number of problem scenarios. For example, suppose a project has only a Win32 version of a certain app, and a client running on Win64 has this app version. The project then adds a Win64 version of the app, with the same version number. The client will not get the Win64 version until a new version is released, which could be a long time.

To remedy this problem, I propose the following set of changes:

Scheduler RPC:

• Add <platform element to <app_version>
• Add <platform> and <version_num> elements to <result>

Scheduler:

• write the above

Client:

• parse the above
• have an array platforms[] of supported platforms;

platforms[0] is the "primary platform"

• add platform field to APP_VERSION
• add platform and version_num fields to RESULT
• add APP_VERSION* avp field to result
• remove avp from WORKUNIT (but keep version_num; see below)
• after state file parse (to handle old/new transition):
  • it an APP_VERSION has no platform,

set it to the primary platform

• if a RESULT has no platform,

set its platform to the primary platform, and set its version num and avp to the latest version of the app for that platform.

• set workunit.version_num to the version num

of any result linked to it

• move ACTIVE_TASK sanity checks out of parse()
• add platform arg to lookup_app_version
• handle_scheduler_reply():
  • defaults for APP_VERSION and RESULT as above
• write <alt_platform> elements to state file

(not used now, but may want them sometime)

Notes:

• Client transition from old to new:

will read old state file, fill in correct version numbers and platforms, and

• Client transition from new to old:

will ignore new elements in <result>; still have workunit.version_num, so it will be able to find (some) version to run. Note: this transition could cause a job to switch from 64-bit app to 32-bit app midstream.

• Old client talks to new scheduler:

no problem, ignores new XML fields

• New client talks to old scheduler:

no problem, missing version/platform fields are filled in with correct values