ROMWORLD

Parsing Responses

When I mentioned earlier about the BOINC XML parser assuming a line-by-line parse what I meant by that the XML responses are relatively flat and is parsed in one pass. This has some interesting ramifications, for instance the relationship between XML elements is determined by what was parsed before it.

For an example of what I mean I’m going to use the uber GUI RPC which dumps the BOINC Daemons entire state and should be called at the beginning of any session. Most of the mini update RPC’s do not contain any relational information so you have to run a quick query against the results to map a workunit to a project for instance.

Here would be the request:

Here is a simplified version of the response:

So in this example you can see that there is no explicit reference to a project in any of the app, app_version, file_info, workunit, and result elements because it is assumed that they all belong to the same project until the next project element is parsed.

This example illustrates what I mean by a relatively flat XML structure. XPath and XQuery would have a hard time trying to return results that are not in a hierarchical in nature.

—– Rom

For all intents and purposes the BOINC Manager and BOINC Screensaver are the same type of application as far as the BOINC Daemon is concerned. They both use the BOINC GUI RPC protocol to direct the BOINC Daemon to perform certain tasks. For the purposes of this article I’m going to assume a valid TCP connection is established between the managing application and the BOINC Daemon.

While the protocol is based on XML, there are a few additional rules:

• No line shall exceed 256 characters in length.
• Line feeds shall separate all containers and tags.
• Unicode is not supported. Everything should be MBCS.
• Parsing of the XML is assumed to be line-by-line. XPath and XQuery queries are not very useful.

While this is valid XML, the BOINC XML parser will choke on it:

This is what it would have to look like for the BOINC XML parser to parse it correctly:

Another important piece of information about the protocol is that both requests and responses are terminated with a control character:

When sent via the managing application to the BOINC daemon it signifies that the request is complete and the daemon can process the request now. Likewise the managing application should wait for that control character before processing the response. For the remainder of this series of articles assume that all requests and responses to the requests are terminated with the control character.

Authentication

Authentication within BOINC is pretty basic. Like most other authentication systems it consists of a challenge and a response.

To initiate the authentication process send the following request:

The response will be the challenge to the request to authenticate:

The value of nonce is to be used as a value to salt the password hash with. It is randomly generated for each request. MD5 is our primary hashing algorithm. If you had the following password:

The resulting string to be hashed would look like this:

After MD5 gets done with hashing the challenge and password the result looks like this:

So now the last part of the authentication process is to tell the BOINC Daemon what the answer to its challenge is. We do this by sending the following request:

If successful you’ll see a response like this:

A failure will look like this:

Some interesting notes on authentication:

• All RPCs are protected if the request is coming from a managing application on a remote computer.
• All RPCs that can change the behavior of the BOINC Daemon are protected even if running on the same machine.
• RPCs that just query the state of the client are not protected when the managing application is running on the same machine.
• Currently is the only exception to the above rules.

More interesting tidbits will follow in future articles…

—– Rom

The 2nd Pan-Galactic BOINC Workshop.

Well I’m going to this year’s BOINC Workshop. 🙂

I haven’t been to Geneva, Switzerland before. This ought to be fun.

—– Rom