From: Bill Stewart <stewarts@ix.netcom.com>
Date: Mon, 28 Aug 95 14:33:23 PDT
To: fc@all.net (Dr. Frederick B. Cohen)
Subject: Re: improving the distributed computation
Message-ID: <199508282130.OAA17520@ix5.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


At 07:43 AM 8/25/95 -0400, you wrote:
>1) Abandon the central command way of doing things.  Little if any
>communication is required for this computation, it should be
>self-distributing to and between volenteer sites.  That makes it ideal
>for implementation as a safe virus. 

Doling out keyspace _does_ require central coordination, though
the job can be delegated to _trusted_ volunteers, or delegated
with redundancy to semi-trusted ones.

As far as safe viruses go, I've had more free lunches than safe viruses,
though I've been offered both out of "charity".  Some of the lunches
were good, and charitable; the viruses have been, at best, mostly harmless.
Perhaps under Safe-Tele-Java-Script it will be possible to send
self-modifying self-reproducing scripts around a network to unsuspecting
machines, but I doubt it.

>2) Give these computations a defined and limited lifetime.  The problem
>you have with old versions is because they don't die automatically or
>even check to see if they are up-to-date and update themselves.

Yeah.  In this case, the lifetime of the versions was less than the
expected lifetime of some of the searches.  Automated version-checking would
help, but the version changes made it difficult to communicate even simple
requests like "Give me a number".  Perhaps it would make sense for version
upgrading to include changing the server's TCP port so the old versions
don't hose the servers for the new versions.

>3) Use randomness to break up the search space and redundantly perform
>the computation.  This should eliminate the problems with malicious
>key-space requests, etc.

Randomness doesn't help much, since it's hard to be sure you
sweep the whole keyspace.  Redundancy does help, but it's still tough
to protect against sufficiently malicious attackers.

>4) Use feedback in the form of selective survival/replication to
>optimize the search and allocate search space.  If a processor goes
>quickly, give it more to do - if it goes slowly, give it less.  This
>will produce an overall system that adapts with time to the cahges in
>network and system usage so as to optimize overall performance as a
>function of time.

You could do that.  But simply asking for more numbers after you've
finished the previous batch accomplishes much the same thing;
special tuning may be more useful for folks with MasPars than 486s,
where redundantly giving out unacked search space can do more.
#---
#                                Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---