My MSc Thesis in Informatics Engineering is about adding intercommunication to BOINC clients / nodes. The idea is to allow nodes to solve a task in parallel, communicating information among them along the way. We have studied the limitations of a distributed approach like this, and concluded that an adequate application for such an environment could be a parallel evolutionary algorithm, perhaps based on islands (summary: each population is in a node and, after some iterations, local individuals are sent to diversify the other nodes' populations). This has low bandwidth requirements overall and can theoretically handle node failures and restarts relatively well, with the addition of communication being asynchronous.

We are thinking about using a P2P library (libjingle is a strong possibility) to build a set of communication primitives (an API) for BOINC client nodes. Firstly, we'll restrict the environment to a local set of computers and test the evolutionary application. In this case, a master or super-peer should be able to handle communication to and from the BOINC server, and coordinate the local nodes if needed. Later, depending on the results, we think of expanding these primitives to work across networks, with this being where P2P communication through firewalls and such barriers becomes important.

My questions are:

1. Are there similar known projects or libraries for BOINC that enable this kind of group communication? I read this thread http://boinc.berkeley.edu/dev/forum_thread.php?id=7962 and know of VolpexMPI (which was the closest I could find), though I honestly couldn't understand if it allowed communication across networks or not, even after consulting some related papers (maybe I should directly ask them).

2. Are there any guidelines or recommendations for a research like this (BOINC and P2P) that we can use? We believe that libjingle should ease problems with peer discovery and other P2P-related issues, but the decision of which functions / primitives to include is very important, and there might be some obvious BOINC client limitations to address.

I apologize if the questions are too generic, but after all the research we did on state of the art, we found that there was a certain difficulty in finding similar projects in BOINC, so I decided to ask in these forums. I would appreciate any information or recommendation that can be given :)

In the Volpex project forums the Volpex admin recently stated participating hosts do not communicate directly with each other. Comms between hosts is achieved by the hosts sending data files to the project server.

Your thesis is interesting but any BOINC project that engages my host in comms with countless other hosts I have no way of identifying or evaluating will likely never get my support. The security concerns are so overwhelming I don't even want to think about it, don't even have time to think about it. No matter what safeguards you build into the system someone will find a crack and exploit it. It's not a matter of "if" it's a matter of "when".

Volpex's indirect method of host communications is as far as I will ever go in that direction. I realize it's not risk free but at least I can imagine the size of the risk. The risk your system presents is so humongous I can't even begin to imagine it. If I can't imagine it I cannot even begin to deal with it. If I cannot even begin to deal with it then I reject it.

Thank you for your reply and the Volpex details :)

I understand your concern; in fact, we still have that question of security open for discussion. We though about it before and superficially mentioned the possibility of users creating a group of trusted people with whom they could communicate. Of course, there are associated problems, so we'll focus on the system first.

Anyway, it's always good to know that the users care about their systems. I'll keep your opinion in mind if our work yields relevant enough results to be of actual use in the BOINC world.

Anyway, it's always good to know that the users care about their systems.

I only said *I* would not take the risk. The vast majority of BOINC users know nothing of risk nor do they care to know. If you start a new project they will prostrate themselves at your feet and tell you how privileged they are to have you doing whatever you please with their resources. And you can abuse them any way you please and they will thank you for it. Yes, I know, unbelievable but it's true!

A friend of mine is doing a masters thesis on the psychological/sociological conditions that give rise to such odd behavior. It's very puzzling.

we still have that question of security open for discussion. We though about it before and superficially mentioned the possibility of users creating a group of trusted people with whom they could communicate.

But none of us know anybody else in the BOINC universe. We are faceless names adrift on a sea of zeroes and ones. The "trusted partners" idea has been tried before in other endeavors, marriage and orgy covens are two such endeavors that spring to mind. Everybody starts out disease free but eventually one member knowingly or unknowingly breaks the contract, goes outside the group and returns with an infection that spreads to the rest of the group. That is the reason doctors recommend condoms no matter who your partner is.

There is a solution that can work, I think. Use a VirtualMachine (VM). Develop your application to run on Linux. Distribute a free VM built with Linux as the OS. Users install the hypervisor, Oracle VirtualBox for example, download your pre-built VM, run it under the hypervisor. Your VM comes with BOINC pre-installed and a very simple and easy desktop like XFCE. When the VM boots it autostarts BOINC manager and the client. Users are presented with BOINC manager which is familiar to them on any platform including Linux. All they have to do is attach the client to your project and they're off and running. VM overhead is very low and it offers you benefits like easy version control and one and only one application to maintain.

If the VM catches a virus and explodes it doesn't blowback onto the host OS. The user simply deletes the VM and clones another from the original he downloaded (or downloads another copy, same result), attaches the BOINC in the VM to the project and carries on carrying on.

Does it work? There is solid evidence it works very well. There is a BOINC project named Asteroids@home that came onstream sans Windows application. They had only a Linux app. Linux users attached the project and crunched. Windows users complained about being excluded from the fun so s.jujube (sockpuppets are given the s prefix much the same way robots in Asimov's stories are given names that begin with R for example the R. Daneel Olivaw rob) proposed the exact same scheme at Asteroids@home and provided a pre-built VM as described above, for download, on his nickel, which would lemmings to crunch Asteroids@home tasks too. The Windows crowd went berserk, as they are wont to do, and s.jujube was roundly roasted in the ensuing flamewar. However, a few of the more astute lemmings eventually realized that the only way they could play was to do as s.jujube proposed. Of course it worked for them. Well, you know the rest of the story... whither one lemming goes a hundred follow and soon there were many happy lemmings running the VM, crunching Asteroids tasks and basking in the Linux sunlight. Some of the braver ones even stuck their little lemming paws into the VM-werks and blew it up but of course that was not a problem, they just cloned another VM as mentioned above.

Eventually Asteroids@home ported their Linux app to Windows which made the VM unnecessary but it proved the concept... lemmings are bright enough to install the hypervisor, download the VM image, run it, attach the BOINC in the VM to a project and return valid results.

The Test4Theory@home project uses a somewhat similar approach but it has difficulties. Rather than ask users to locate and download the VM image they send it to BOINC running on the priamry OS as one of the files required for their tasks. Their science application is actually a wrapper application that runs the VM. The VM boots Linux. One of the daemons that starts during the boot sequence invokes their real science applications which communicate their results back to the project server via a non-BOINC platform called Co-pilot developed by CERN. It's thus a little different than s.jujube's scheme but the security concerns are sandboxed inside the VM all the same. What happens in the VM can affect only the VM.

My advisor actually had a student working on virtualization in BOINC a few years ago and I also know a bit about virtual machines; enough to recognize their usefulness :) My experience with them was mainly related to running a different OS in mine and not particularly because of security issues. I still hadn't thought about using virtualization, maybe because this project's area was directed towards a very different goal. Now that you mention it, it might actually be a good solution for that problem.

But again, we'll deal with that issue when the time comes. I will have to target the main aspect of the research first; that is, implementing the system. It might even yield not-so-good results, which is something I have to be prepared for.

Again, thank you very much for your replies :)