This graphics is only slightly wrong. The central box should be BOINC or BOINC client rather than BOINC manager. There's another box missing right next to the box with boinc_cmd which is for BOINC manager and has the same interaction with the rest of boxes as boinc_cmd does.

The diagram also conflates projects with science applications. Many projects only have one app each, but some have two or more. (A couple of examples: SIMAP has “simap” and “hmmer”; Pirates@home has a whole fleet of them, so to speak, including “hello”, “yello”, & “cube”.) At some point in the future we may be running both Multibeam S@h Enhanced (now in late beta-testing) and Astropulse (now in alpha or early beta) apps here.

---

Hope this is better...

Hope this is better...

Very nice.

That follows my understanding of the system.

Just one gray area... How do the screensavers fit in there?...


Nice work,

Cheers,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Just one gray area... How do the screensavers fit in there?...
Nice work,

Thanks Martin.. you would have to complicate things! I guess they're hiding in and behind the science apps, waiting for a call!

Just one gray area... How do the screensavers fit in there?...
Nice work,

Thanks Martin.. you would have to complicate things! I guess they're hiding in and behind the science apps, waiting for a call!

or perhaps as a dotted-line dependancy to the client. after all they are simply a process that's called when required that then displays what the status is of the client/wu's.

(for certain values of "simply".)

---

Thanks Martin.. you would have to complicate things! I guess they're hiding in and behind the science apps, waiting for a call!

One more complication: the BOINC core client uses three different methods of communication: with the Manager (and the command-line?) via local TCP/IP, with the science apps in shared memory, and with the project servers over the network.

I like the way you’ve used colour to show the indirect connection between the project servers and their apps.

Thanks Martin.. you would have to complicate things! I guess they're hiding in and behind the science apps, waiting for a call!

My understanding (it might be wrong though) is that screen saver connects to BOINC client. Image (to be displayed by screen saver) is created by science app and is accessible by BOINC client through shared memory.

[edit]
Might be, that screen saver gets address of shared memory segment in GUI RPC response from BOINC client though.
[/edit]

One more complication: the BOINC core client uses three different methods of communication: with the Manager (and the command-line?) via local TCP/IP, with the science apps in shared memory, and with the project servers over the network.

Actually it uses two methods. One is indeed via shared memory used for communication between BOINC client and science application.

Communication with Manager, command line and any third party GUI RPC clients (such as BoincView) works over TCP/IP as does communication with project servers. The difference is only that communication between Manager and BOINC client gets routed through local loopback network device, but that's performed by underlying OS. The same functionality (management) can be done remotely (even by BOINC Manager), but that really doesn't make any difference for any of the applications involved.

---

Metod ...

Isn't there more than ONE connection/arrow between 'BOINC Client' and 'Project Servers'?
...requesting work
...handing out work (downloading)
...receiving work (uploading)
...reporting work completed
...etc

Hope this is better...

Very nice.

That follows my understanding of the system.

Just one gray area... How do the screensavers fit in there?...


Nice work,

Cheers,
Martin

---

SETI@home since 1999
"Set it, and Forget it!"

Isn't there more than ONE connection/arrow between 'BOINC Client' and 'Project Servers'?
...requesting work
...handing out work (downloading)
...receiving work (uploading)
...reporting work completed
...etc

No, you're confusing connections with sessions. One connection handles all sessions. Sessions/functions are different and may get routed to different machines at the project, but that's more detail than required or room for - this diagram is only to show beginners the relationship and connections between the client, manager, app(s) and project servers.

The functions are irrelevant in this context as they travel over only one distinct path from the client to each project.

What happens when they reach the project depends on the topology and implementation of the particular project, which could have 1 or hundred machines. To the user, it is just a virtual wire connecting to a black box!