[rc5] Future of Distributed Computing

Sebastian Kuzminsky kuzminsk at taussky.cs.colorado.edu
Thu Oct 23 18:11:45 EDT 1997


nataylor at nmt.edu (Nathan Taylor) wrote:
] I have chosen not to go on to the 64 challenge.  As far as I'm concerned,
] the encryption thing has been done.  Anything from here on out is acedemic.
] I won't be doing primes, either.  It's too abstract a concept for me to
] really enjoy.  SETI sounds fun, but the problem is that project has no
] definite end.  So, for now, my idle cycles will go unused.  I'm waiting for
] the NEXT BIG PROJECT(tm).


   The 64-bit RSA challenge is a worthwhile project to spend your cycles
o on, for a simple reason.  There's $10,000 at the end of it.  It is the
only proposed project that directly translates to more development
money...


   The Mersenne primes project is, as the distributed.net web pages
point out, a never-ending filler.  Please enlighten a poor
math-ignoramus:  what use are Mersenne primes?


   The SETI project is really cool.  The data is quite limited in scope,
but the sexiness factor is pretty high.




   Of these three, i would work on RC5-64.




]                                             What about distributed 3D
] picture rendering?



   Hmmm...


   The unit of work that the server requests of the clients (analogous
to the keyblocks handed out by the RC5 servers) would be some type of
scene description file, perhaps in Povray format.  A typical .pov file
is less than 5K compressed, and can generate many different pictures.  A
typical low-resolution raytraced image (320x240 gzip -9'ed .tga) is
about 125 or 150 KB.  A Pentium 133 can produce this result at a rate of
more than a kilobyte per second.  On the clients side, that saturates a
14.4 Kbps connection.  The distributed.net computer can produce this
data at almost 100 MB/s.  Only most well-connected servers on the
internet could accept data at that rate.


   With todays infrastructure, in this case, distributed.net would turn
a CPU bound problem into an I/O bound one.  On a limited scale, this is
useful.  However, i for one would be reluctant to donate that much of my
bandwidth.




]                                                                   What if
] I was just performing a complex calculation on a huge spreadsheet and parts
] of it got distributed?  How about a network where every computer was free to
] use the other computers' idle time.  


   Truly distributed processing has a practical problem that seems
nearly insurmountable:


   How do you protect against malicious participants?


   Say Alice sends Bob a decription of a computation she wants him to
perform.  Bob could either perform the computation and return the result
(great!), or ignore it and send nothing (no problem, Alice times out and
sends the job to Charlie instead), or ignore it and send a false result
(ouch).


   In some cases the fakery is easy to detect ("Hey, this key decrypts
the cyphertext to gibberish!"), but in some cases it cannot be done
without ACTUALLY performing the whole computation to verify the result
(the prime-finding problem has this property).


   There are means of alleviating this problem, but not of solving it in
the general case.  You could submit the same job to N different clients,
and use a voting system to decide the result.  You could use a
reputation system:  Alice detects Bobs fakery and adds him to a
more-or-less global black list.




]                                      I'm no computer scientist, and I'm sure
] many of you are laughing, but that's what I see when someone says 
] "distributed computing."


   What you are describing is without a doubt the next distinct phase of
computing as a whole.


   Andy Tannenbaum's Amoeba and (to some extent) the GNU Hurd are
distributed operating systems in which you issue jobs NOT to a specific
machine, but to the network.  Tools (such as PVM) which allow easy
access to networked computing resources from within existing, deployed
systems are becoming stable and usably fast.




   Some applications i'd like to see for distributed.net are:

   *  A distributed chess engine
	 The chess problem is quite different from the RC5 problem.  I
	 am eager to see how the v3 protocol will allow for two such
	 diverse algorithms.  The chess problem may be too
	 network-intensive for the distributed.net computer.  The sort
	 of CPU power that distributed.net has available should be able
	 to beat Deep Blue without too much trouble, given wide pipes.

   *  An on-demand SSL/Unix crypt() cracker
	 Like the RC5 crack, but let users submit what they want
	 cracked.  No better way to drive the point home...


   

Sebastian

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list