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 #---