The BOINC scheduling server protocol

Protocol nucleus

The core client communicates with scheduling servers using HTTP. The following 'nucleus' of the protocol should be considered immutable. This will allow any version of the core client to talk to any version of the scheduling server, and for the server, if needed, to tell the core client that it's out of date. The form of the request is:

    ... other elements

The 'platform' and version number elements identify the version of the core client originating the request.

The form of the reply is:

    [ <message priority='low'> arbitrary text </message> ... ]
    [ <request_delay>3600</request_delay> ]
    [ <redirect>URL</redirect> ]
    ... other elements

Each message element is a message to the participant.

  • If the priority is 'high', the core client should try to ensure that the participant sees the message; for example, by displaying it in a popup window. It should not, however, wait for user input, as this could starve other projects. This should be reserved for situations where definitive action is required, e.g. the user must download a new version of the core client in order to continue participating in this project.
  • If the priority is 'low' (default) the core client should allow the participant to see the message, but should not require it. For example, it could write the message to a log file.

A reply message can contain multiple message elements.

A request_delay element instructs the client to not issue another request until the indicated number of seconds has elapsed.

A redirect element gives the URL for a scheduling server for this project. If present, the core client should replace its list of scheduling servers for this project. The reply may contain multiple redirect elements.

Extensible protocol

The remaining protocol may evolve over time. Request elements include

    The following fields are used to report errors to the server, They
    are not present if there is no error while downloading, computing
    or uploading files for this result.
    [ <message> some text describing the error </message>]   ]
    The state of the active_task assigned to compute this result at
    the time of the error
    [ <active_task_state>0</active_task_state> ]
    The exit_status of the application running the computation for the result
    [ <exit_status>0</exit_status> ]
    The signal raised by the application if any.
    [ <signal>0</signal> ]
    If the error corresponds to downloading input files for the
    work_unit for this result, then:
    If the error corresponds to uploading outfiles for this results
    the std_err output of the application, if any, goes here.

Reply elements include

<message priority='low'>no work available</message>
            <color-scheme>Tahiti Sunset</color-scheme>
Last modified 15 years ago Last modified on May 10, 2009, 4:17:20 PM