[rc5] V3 Questions and Concerns

James Mastros root at jennifer-unix.dyn.ml.org
Sat Nov 1 11:47:44 EST 1997

On Tue, 28 Oct 1997, Marc Sissom wrote:
> Eric Gindrup wrote:
> I'm not going to bother cleaning this up this time...
But I shall...
(Note to Eric Gindrup: This is highly annoying.)

> >         Although true that Java cores are not as high-performance as
> > 	 native cores, the extra security is likely to draw in people who would
> >      not be comfortable downloading "strange" software to run unsupervised.
> >      This would increase the effectiveness of the Effort.
> <chop>
> >         There are a whole bunch of reasons that this is a good thing and
> >      the only reason I've really heard opposing it is that the Java
> >      performance isn't good enough.  I counter, though, that 0kps is
> >      infinitely worse than 1kps.
>  Nobody seems to want to combine the web page, java applets, easy
> download, and poor java performance into the obvious, a real,
> live, productive, DEMO!

Umm... I do.  Look for my post "Re: [rc5] Best setup for infrequent dial-up
connection".  If you can't find it, mail me, and I'll send you a copy.

>  Sure, look here! Load this URL and watch your PC crunch keys,
> perform signal analysis on radio telescope signals, workout chess
> moves, or whatever. Then if the indi is interested, they can chase
> down the high performance core and let it run as an app and not an
> applet.
> The object oriented forms of communication that the later JDK
> offers is also a plus. Download the 'object' which includes the
> data and the methods, execute the 'process' method and then send
> it back. For apps that are sensitive to easy sabotage, the object
> includes methods for authentication. If the app requires a 24/7
> connection, it drops itself out when the communications fail. If
> it requires a high performance platform, it drops out when the
> client fails to meet spec.

I was thinking of somthing like that with my recent "[rc5] An idea for the
v3 protocol" (Or somthing like that).

> The generic 'client' doesn't have to know about any of this. All
> it has to know is how to get objects from the servers, how to ID
> itself to the processing objects, how to run them, and how to
> return objects to the servers. Perhaps the objects can do this
> last part themselves.


> The user config can be simple or complex. The user can say:
>  "I want to run SETI, or anything else that is heavy on flops".
> or
>  "I've got lots of mips"
> or
>  "I want to do the chess database, primes, or the current RC5
>  in that order."


> Let the servers hold the intelligence to figure out what work
> is available and what to dispatch to which cpu. Let the objects
> decide for novices if they are running on an appropriate
> platform.

I was planning on letting the client decide that, based on a simple
discription of the stresses and requirements for that core. 

I love it when I see a "Me too" post that didn't know that it was a "Me too"

	-=- James Mastros

When the annals of distributed computing are written, and the name 'Bovine'
appears in there, I can say "Hey, I was a part of that, I checked .0012% of
the keyspace".
	-=- Brian Wilson <wilsonb at mindspring.net>
Go to www.distributed.net before I come make you!

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

More information about the rc5 mailing list