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