I've been pondering this for a while, especially since the problems the systems have been having lately...

It would be interesting to investigate how peer-to-peer networking could be incorporated into the BOINC concept, so as to not only distribute the CPU load, but the networking and storage loads as well. Think of pure peer-to-peer clients such as Kazaa et al. The entire network is made up of the distributed nodes, having no central server, no central database, yet the network itself contains huge amounts of searchable data.

Of course, in the case of seti@home, the end reslts would need to all go back to the project database, but if a lot more of the intermediate processing was doen within and between the distributed clients, it would make the entire system a lot more resistant to outages.

The network could even be designed to contain enough work for all clients for several days of the main project's server being down without anyone ever noticing it.

That's my wish
I know it's not that easy ;-)

Michiel

I must say... An interesting concept... and a good idea.

How easy it would be is another matter. But as far as you explain it, it would go a long way toward "patching" server outages.

The only reservation would be security. In the current state of things we know and "trust" the BOINC/S@H software's source. If a Kazaa like p2p network was implemented, the following questions would arise...

Questions:-
========
1. How would we be assured that the number crunching plugins could be trusted to just crunch numbers?

2. How could the "scientists" running the projects be assured that the number crunching plugins hadn't been modded in some way that messed up the results?

3. If workunits were stored over several computers in a p2p network and the number crunching plugin's version changed. Would the workunits get crunched by the new cruncher without compatibility problems? (See past news for Predictor@Home for an example of workunits that broke the old cruncher.) If not, how would you assure continuity in the results and what method would would you use to convert the old format workunits to be compatible with the new cruncher?

4a. How do you implement a p2p system that takes static workunits downloaded from S@H with one machine in mind and tailors those workunits to the abilities of possibly lesser able systems, or for that matter systems with greater capabilities than those of the machine that downloaded the workunit/s?

4b. If you devised an answer for question 4a. How could result continuity be assured at the S@H end? After all this is meant to be a scientific experiment!

5. How would the central server manage and track credit for workunits completed if the machine used to download the workunit was different to the one that crunched it?

Answers:-
=======
Questions 1 & 2 could be answered by just having workunits on a p2p system and the crunchers/client software from a known "trusted" source.

Question 3 would probably be a simple one to answer by having the new cruncher recognise an old format WU and convert it to the new format before commencing crunching it. Though the continuity of results is still an issue.

Question 5 could probably be answered by sending extra account info from the client back to the central database server with the completed workunit. This would of course require modifications to the server side software. With the current system, as far as I can tell, the workunit is tracked from the time it's sent to your system by the server to the time the client uploads the result. Therefore the admin staff on the project can see exactly who's doing what at what time. If p2p was implemented, a system would need to be in place to do this same job. This would mean a lot more information being sent around or the need to possibly modify the workunit's header to make it plain who's actually crunched it. Of course this would have to be implemented in some way to tailor the static workunits on the p2p network for higher or lower powered systems (as described in question 4a) anyway.

This still leaves questions 4a & 4b un-answered...

Conclusion:-
========
I would expect that p2p hasn't been implemented for the same reason that proxys such as SETIQueue haven't been supported in BOINC. It would just be too much like hard work!!

I hope this gives you some food for thought!

> I must say... An interesting concept... and a good idea.
>
> How easy it would be is another matter. But as far as you explain it, it would
> go a long way toward "patching" server outages.
>
> The only reservation would be security. In the current state of things we know
> and "trust" the BOINC/S@H software's source. If a Kazaa like p2p network was
> implemented, the following questions would arise...
>
> Questions:-
> ========
> 1. How would we be assured that the number crunching plugins could be trusted
> to just crunch numbers?
>
> 2. How could the "scientists" running the projects be assured that the number
> crunching plugins hadn't been modded in some way that messed up the results?
>
> 3. If workunits were stored over several computers in a p2p network and the
> number crunching plugin's version changed. Would the workunits get crunched by
> the new cruncher without compatibility problems? (See past news for
> Predictor@Home for an example of workunits that broke the old cruncher.) If
> not, how would you assure continuity in the results and what method would
> would you use to convert the old format workunits to be compatible with the
> new cruncher?
>
> 4a. How do you implement a p2p system that takes static workunits downloaded
> from S@H with one machine in mind and tailors those workunits to the abilities
> of possibly lesser able systems, or for that matter systems with greater
> capabilities than those of the machine that downloaded the workunit/s?
>
> 4b. If you devised an answer for question 4a. How could result continuity be
> assured at the S@H end? After all this is meant to be a scientific
> experiment!
>
> 5. How would the central server manage and track credit for workunits
> completed if the machine used to download the workunit was different to the
> one that crunched it?
>
> Answers:-
> =======
> Questions 1 & 2 could be answered by just having workunits on a p2p system
> and the crunchers/client software from a known "trusted" source.
>
> Question 3 would probably be a simple one to answer by having the new cruncher
> recognise an old format WU and convert it to the new format before commencing
> crunching it. Though the continuity of results is still an issue.
>
> Question 5 could probably be answered by sending extra account info from the
> client back to the central database server with the completed workunit. This
> would of course require modifications to the server side software. With the
> current system, as far as I can tell, the workunit is tracked from the time
> it's sent to your system by the server to the time the client uploads the
> result. Therefore the admin staff on the project can see exactly who's doing
> what at what time. If p2p was implemented, a system would need to be in place
> to do this same job. This would mean a lot more information being sent around
> or the need to possibly modify the workunit's header to make it plain who's
> actually crunched it. Of course this would have to be implemented in some way
> to tailor the static workunits on the p2p network for higher or lower powered
> systems (as described in question 4a) anyway.
>
> This still leaves questions 4a & 4b un-answered...
>
> Conclusion:-
> ========
> I would expect that p2p hasn't been implemented for the same reason that
> proxys such as SETIQueue haven't been supported in BOINC. It would just be too
> much like hard work!!
>
> I hope this gives you some food for thought!
>
One point that you missed. For security of the scientific results, the WUs are issued to a specific computer, and only that computer is allowed to crunch and return the results. One of the cheats in S@H1 was to have a precomputed result uploaded by many clients. While a P2P network would get through server outages, it decreased both the security of the clients, and the security of the results. I wouldn't expect to see this ever.

John, I actually touched on this in question 4b...

"How could result continuity be assured at the S@H end?"

But thanks for confirming the details.