Month: August 2006

BOINC, projects, account managers, and the community

What is up? It seems like there is some major disconnect between what David, I, GridRepublic, BAM, WCG, and the CPDN/BBC partnership have been up too and what the community believes is going on.

I don’t believe there are all that many people who actually believe that the current interface to BOINC is the best piece of software in the world and can be used by everybody on the planet. As a matter of fact, more often than not, we get feedback along the lines of “I wish it was as easy to use as S@H classic was.”

The biggest problem brought up at the First Pangalactic BOINC Workshop from the projects was the attach to project process.

For those who are relativity new out there BOINC used to require a project URL, and a authenticator in order to attach to a project. Authenticators are a string of 128 randomly generated characters. These were sent to you via email and had to be typed into the attach to project dialog which didn’t describe where that information came from or where to get it.

The authenticator turned out to be such a big problem that S@H didn’t want to complete the transition to BOINC until a better solution was in place.

There are two parts here:

  • S@H classic was a single executable with hard coded IP addresses, so the participants only needed to know their username to start processing data.
  • The user interface didn’t allow you to do anything, so you really couldn’t get into trouble.

In order to address these usability issues we first had to figure out what our goals ought to be. Here is a brief outline of our goals:

  • The stock BOINC software should not play favorites among the projects.
  • The stock BOINC software should not depend on any sever for normal operation.
  • The BOINC platform needs to be flexible enough for all research and business needs.
  • Find a way to simulate the simplicity of S@H classic’s attach process so the participant only needs to provide something easy to remember.
  • Find a way to simplify the interface.

One of the first proposals we talked about for Windows was a control panel applet that you could just check which projects you would want to participate in, which had several problems. Where was it going to get the list of projects? What happens if that server no longer exists? How do future projects get on the list?

Matt, of GridRepublic, approached us in late 2004 and wanted to see if he could help further BOINC’s adoption. He was especially interested in attracting the millions of users who might not otherwise join a distributed computing project because of ease of use problems. After a few sessions of brain storming Matt and David started to put together the concept of a web-based account management system.

At the time I was finishing up the last of the 4.x line of client software and helping E@H launch.

Support for the initial draft of the account management system began in early 2005 after the launch of E@H. By this time David and Matt started having regular phone conversations about feature sets and possible delivery times of features within the BOINC client software and the GridRepublic account manager. GridRepublic’s design goal became “provide an attractive, simple, and easy-to-use interface so that anybody could attach to any GridRepublic supported project with a click of a button.” an off-shoot of that was the need for a branded client so that the participant didn’t get confused about what they installed on their computer.

BOINC? What’s BOINC? I wanted to install this GridRepublic software to help fight cancer. Did I just get a piece of spyware? malware?

So the GridRepublic branded version of the BOINC client software was born to help reduce confusion for new participants. This had the added advantage that the GridRepublic client could be directly tied to the GridRepublic website without hurting the stock application. Usability studies, aren’t they grand?

WCG approached us early-2005 and asked if we would be willing to collaborate in allowing the BOINC client software run against the WCG servers. They were getting quite a bit of feedback from the distributed computing community that wanted to run WCG plus a few other BOINC projects. In turn they would help us come up with a simpler GUI and possibly other features that would be needed for corporate deployments. By mid-2005 IBM legal gave WCG the go ahead and work begun in earnest.

In November 2005, WCG launched the BOINC compatible interface to WCG. The amount of positive feedback they got was fantastic, the demand for a Windows based application was so high that they had to reschedule some other workitems to get the Windows version out the door.

In December 2005, we were approached by CPDN and the BBC to help put together a BBC branded BOINC client to run an experiment that the BBC was going to document. Working with the BBC was an experience, the visuals changed rather regularly but they did get better. We managed to complete the branded client by the deadline for the first part of the TV documentary in February 2006. The BBC did a few usability studies by pulling people off the street, a few things came from that including renaming “credit” to “work done” as some of the people polled were concerned that their credit card might be involved.

May 2006, Willy de Zutter of BOINCStats fame launched BAM.BAM largely flew under my radar as I don’t recall Willy asking for any client-side changes. I do recall a few bug reports being posted to boinc development though.

June 2006, WCG told us that they were ready to begin the simple GUI work, they had recently hired an internal developer who would do the work. Later that month we had mock-ups sent to us via email and were giving them feedback on what we thought. They started writing code at the beginning of this month.

Collaboration continues between BOINC, GridRepublic, BAM, WCG, and the community with tweaks to the UI to make things more easily understood by new participants. Account management systems continue to evolve as well, I believe the ultimate goal of the system is to provide a single remote interface to all of your BOINC based clients. Suspending/Resuming tasks, projects, and clients. Changing preferences for clients. Attaching and detaching to various projects for clients. In short anything you can do in the advanced GUI you could do via an account manager.

As far as the whole branding thing, I tend to look at the BOINC technology stack in a layered way. BOINC sits at the very bottom, projects sit on top of BOINC, and account managers sit on top of projects. Account manager’s need to be able to differentiate amongst themselves. Right now that consists of website design and client graphics. That doesn’t make them any less BOINC enabled than if they kept the stock graphics or website design.

Another analogy in the software world with branding is Linux. The Linux kernel sits at the bottom, applications sit in the middle, and distro’s at the top. Does Fedora get lambasted for changing the “start” button from the default KDE/Gnome button to a red hat? Would Red Hat get beat up if they said “use our software, x number of people can’t be wrong.” where x is the total number of Linux users worldwide when the target audience for the advertisement is Windows?

I think the hostility towards WCG and GridRepublic is unwarranted and harmful to BOINC overall. From where I’m standing, everybody is being a good citizen. I do not believe anybody is out to do BOINC or the community harm, so if you see a problem just drop them or me an email. Everything will get sorted out.

—– Rom

BOINC Workshop and Vacations

So I’m starting to get prepared for various trips in September.

For the first week in September I’ll be traveling to Anchorage, Alaska to meet my new niece. My sister gave birth to her first child a couple weeks ago, so this will be something of a new experience for me. On the 6th I’ll be leaving Alaska and head to Florida to check out my new diggs which I’ll be moving to at the end of November. On the 11th I’ll be returning home for a week. I bought some toys for my nieces and nephew, holy cow, toys are expensive.

September 18th I leave for Geneva, Switzerland to attend the The 2nd Pan-Galactic BOINC Workshop. I’m looking forward to meeting several of the scientists of the European BOINC based projects. I found out today that David Kim of R@H is going to go to the conference, so we are trying to sync up for the long flight over. My grandparents are going to meet me in Geneva and after the conference we are going to go tour around for a bit. Right now, I really don’t know where I’m going or where I’m going to stay, it is going to be something of a surprise. My grandparents are a lot of fun to travel with and I’m really looking forward to it.

On the 28th I head back state side and recoup. I’m sure the next couple of days after that will be spent relearning all the things I will have forgotten about BOINC. That is normally the sign of a really great vacation.

I have turned off various forms of article tracking for the blog that spammers like to try and abuse, so the favorites section won’t change while I’m away. Sorry about that, but I don’t know what my Internet connectivity situation will be like next month and I really don’t want to come back to a bunch of auto insurance, and poker advertisements to clean up.

—– Rom

BOINC and the gaming consoles

A very common request we have from the community is to be able to run BOINC and various projects on a gaming console, whether it be the PS3, XBOX360, or Wii.

As many have heard Folding@Home has announced that they have a client package for the PS3.

This is great news for all distributed computing projects, personally I think this will begin the domino effect of having all the console manufacturers want to be able to support this kind of development.

We had gotten some push back from one of the manufacturers about doing something like this at the begining of the year and since we had the stuff with the CPDN/BBC to do and then stuff with WCG we decided to put the console issue on hold. We are almost done the the WCG workitems and the CPDN/BBC stuff is already done.

When Microsoft announced XNA Game Studio Express I applied to participate in the Beta. Now I need to get ahold of the SDKs for the PS3 and Wii.

People should realize however, this is only half the battle. Once BOINC is ported, we’ll have to get a few projects running on a console.

This kind of adds another diminsion to the whole notion of console wars. I mean, can you imagine one of the administrative staff at a university getting a request to purchase 5,000 PS3s? I would really love to be in that office when that request hits their desk.

—– Rom

BOINC Client Communication Infrastructure, Part III

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 <get_state> 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 <get_state> results to map a workunit to a project for instance.

Here would be the request:


<boinc_gui_rpc_request>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>15</release>
<get_state/>
</boinc_gui_rpc_request>

Here is a simplified version of the response:


<boinc_gui_rpc_reply>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>13</release>
…
<project>
<name>Alpha Project</name>
…
</project>
<app>
<name>alphaapp</name>
<user_friendly_name>Alpha Application</user_friendly_name>
…
</app>
<file_info>
<name>aapp_5.24_windows_intelx86.exe</name>
…
</file_info>
<app_version>
<name>alphaapp</name>
<version_num>524</version_num>
<file_ref>
<file_name>aapp_5.24_windows_intelx86.exe</file_name>
<main_program/>
</file_ref>
…
</app_version>
<workunit>
<name>Test1</name>
<app_name>alphaapp</app_name>
<version_num>524</version_num>
…
</workunit>
<result>
<name>Test1_0</name>
<wu_name>Test1</wu_name>
</result>
<project>
<name>Beta Project</name>
…
</project>
<app>
<name>betaapp</name>
<user_friendly_name>Beta Application</user_friendly_name>
…
</app>
<file_info>
<name>bapp_5.24_windows_intelx86.exe</name>
…
</file_info>
<app_version>
<name>betaapp</name>
<version_num>524</version_num>
<file_ref>
<file_name>bapp_5.24_windows_intelx86.exe</file_name>
<main_program/>
</file_ref>
…
</app_version>
<workunit>
<name>Test1</name>
<app_name>betaapp</app_name>
<version_num>524</version_num>
…
</workunit>
<result>
<name>Test1_0</name>
<wu_name>Test1</wu_name>
</result>
</boinc_gui_rpc_reply>

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

BOINC Client Communication Infrastructure, Part II

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:


<Value1><Subvalue1>1</Subvalue1><Subvalue2>2</Subvalue2></Value1>

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


<Value1>
<Subvalue1>1</Subvalue1>
<Subvalue2>2</Subvalue2>
</Value1>

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


“03”

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:


<boinc_gui_rpc_request>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>15</release>
<auth1/>
</boinc_gui_rpc_request>

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


<boinc_gui_rpc_reply>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>13</release>
<nonce>1155697308.532692</nonce>
</boinc_gui_rpc_reply>

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:


password

The resulting string to be hashed would look like this:


1155697308.532692password

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


679f1ff0d1c7ed56321c6bc857cdcb43

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:


<boinc_gui_rpc_request>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>15</release>
<auth2>
<nonce_hash>679f1ff0d1c7ed56321c6bc857cdcb43</nonce_hash>
</auth2>
</boinc_gui_rpc_request>

If successful you’ll see a response like this:


<boinc_gui_rpc_reply>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>13</release>
<authorized/>
</boinc_gui_rpc_reply>

A failure will look like this:


<boinc_gui_rpc_reply>
<major_version>5</major_version>
<minor_version>5</minor_version>
<release>13</release>
<unauthorized/>
</boinc_gui_rpc_reply>

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 <set_screensaver_mode> is the only exception to the above rules.

More interesting tidbits will follow in future articles…

—– Rom

BOINC Client Communication Infrastructure




BOINC, like a lot of modern software, is broken up into several components. Each component has a designated purpose.



BOINC Daemon is the heart of the client software package. It handles management requests from any software that understands the BOINC GUI RPC protocol, it handles CPU scheduling for the various science applications, it downloads new tasks from the projects it is attached too, it uploads the results of the completed work back to the project servers.



BOINC Manager communicates with the BOINC daemon using the BOINC GUI RPC protocol to allow the participant to attach to another project or account manager, suspend and resume tasks, suspend and resume projects, suspend and resume BOINC daemon itself, and check out any messages the daemon has generated.



BOINC Screensaver handles the screensaver request from the operating system and notifies the daemon it needs to choose a graphics capable application to act as the screensaver. After the daemon and science application agree on who is supposed to display graphics the science application opens its graphics window and the daemon changes its internal data so that the next time the screensaver asks for an update it finds out that the screensaver window is open and needs to be brought into the foreground.



All communication is handled by polling at regular intervals. Communication between the daemon, manger, and screensaver is through TCP/IP.



Communication between the daemon and the science applications is handled through shared memory.



Shared memory is a limited resource on most systems, on Solaris it is disabled by default, and for Linux I believe it is setup by default as 2MB across all processes. I believe different distros customize this setting when they build their Linux kernel. The daemon allocates 4KB per science application that is running.



Using shared memory for a communication mechanism between the daemon and manager would have meant that the manager would not have been able to remotely connect up to a BOINC daemon on another machine.



Communication between the daemon and the project servers is handled by libCurl using the HTTP protocol. libCurl can handle the encryption layer of HTTP, SOCKS proxies, HTTP proxies, as well as multiple authentication types. Earlier versions of BOINC, before libCurl was being used, couldn’t handle all of those scenarios.




IP connections consist of an IP address and a port number for both the client and the server. So when BOINC Manager starts up it resolves a server name into an IP address using DNS. After the IP address has been resolved BOINC Manager tells the operating system to establish a connection to the target IP address using an operating system assigned source port and a well known target port.



If the manager and daemon are running on the same machine the connection could look like this:


127.0.0.1:10000 <—–> 127.0.0.1:31416



10000 would be the outbound port, and 31416 is the inbound or listening port.



Connections from the daemon to a project server look the same as the case of BOINC Manager but the computer goes through the Internet like this:







IP addresses that begin with 192.168.x.x are considered non-routable addresses and are used by routers that support NAT to increase the available pool of IP addresses on the Internet.



Tomorrow I’ll follow-up with some more detailed information about the BOINC GUI RPC protocol.



—– Rom