[rc5] Future of Distributed Computing
root at jennifer-unix.dyn.ml.org
Thu Oct 23 21:40:13 EDT 1997
On Thu, 23 Oct 1997, Sebastian Kuzminsky wrote:
> 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 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?
A prime number of the form 2^n-1.
> The SETI project is really cool. The data is quite limited in scope,
> but the sexiness factor is pretty high.
Exactly. *REAL HIGH*!
> Of these three, i would work on RC5-64.
I wouldn't; I would work on SETI.
> ] What about distributed 3D
> ] picture rendering?
> 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.
> ] 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?
Yep... BIG problem. Can you say bunda at buceta.caralho.org? (I can't).
> 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).
As does distributed chess. I submit a move that results in easy checkmate
(for Deep Blue, not Deep Cow).
> 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.
But that means n times the work, and still a n*(% of fake positives) chance
of getting a fake positive. Also, this won't help at all for a honest false
positive (assuming that both groups are running the same client).
> You could use a reputation system: Alice detects Bobs fakery and adds him
> to a more-or-less global black list.
This is the best (most elegant/general) thing I see, but still has a big
problem: how Alice detects Bob's despicable behivor.
> 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...
I like, definitly. Although there are many different crypt() alogrithims.
Also, doing a pure-brute-force method crypt crack is, in general, not a Good
Thing, since humans tend to use passwords from a certian subset of the
Also, I just thought of a fairly cool one: a distributed web-search engine.
Each client would get a starting URL from the master server (via a network of
proxies, naturally), and get that page. Then extract its vital statics, and
send it back up to the master servers. (As a slight optmisation, get all
the URLs that you want to buffer from that page, and send the rest up to d.n
(better: send all of them, but mark some as taken by you.).) IO bound, yes,
but a good choice for those with tons of IO to burn.
It seems to me, however, that the chess and rendering ideas are going to be
data-bound. That is to say, for chess what do we do while we are waiting
for Deep Blue to take his turn, and how many images do you want rendered per
-=- James Mastros
Current Bovine Rate: ~5894.11 mkeys/sec
If Keys were dollars, we could pay off the U.S.
National Debt in 14.70 minutes.
-=- http://rc5stats.distributed.net/statbar.html (Tue Oct 21 1997)
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5