[rc5] distributed.net: a Generalised Compute Resource?

Tom Guptill tgpt at kelp.pas.rochester.edu
Fri Jun 20 16:52:10 EDT 1997

> That is insane.  If (and only if) it were voluntary to add specific
> modules, I might participate.  However, what you are suggesting is a
> security nightmare.
> I have some thoughts on the techinical details of how to do a system like
> this, but the important thing is that the admin of the site _must_ have
> control over what modules can run on a box.

Since we do a lot of number crunching work, we've been putting some effort
into a system such as this.  Our specification has two levels of
"communicative trust" between machines:  machines are either "trusted"
(which means you accept "modules" as well as "work" from them) or
"untrusted" (which means you accept only "work", and only if you have a
module suitable for that sort of work or are willing to forward the work off
to someone who does.)  

We have not built the authentication layer into our specification at this
stage; we have not decided whether to do this eventually or to rely on an
extrnal product (ala 'ssh') to handle it.  (largely because nobody working
on the project has the technical knowledge to implement the authentication)

We assume that you could run in two "modes", one where all machines on a
"closed" network authenticate and trust each other and another where
machines on an "open" network (i.e. one that "outsiders" can join) where
machines do *not* trust each other and distribute only work, requiring the
admins of each machine to manually install the modules, either on each
machine individually or through their own, local "trusted" distribution

Our project may differ from other implementations in that it is *entirely*
decentralized: machines communicate only through each other, and the means
of reporting the results are included in the *module* rather than in the
protocol.  This has the advantage of not requiring a central server (or
round-robin of servers) to deal with the entire network, but it has the
disadvantage of your server relying on its connecting server's continued
connectivity or the ability to "ask" for a new server.  (We chose a
store-and-forward work distribution model for reasons I won't go into here.)

Of course all of this is purely theoretical at this point: we've not gone
beyond simulating the function of the network on one computer, and even that
is still spotty as we mess with how to balance the work.  It's the thought
that counts, no? :)

- Tom

Tom Guptill                     Department of Physics and Astronomy
UNIX SA                         University of Rochester  Rochester, NY USA
                                HEPNet:  tgpt at urhep
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list