[rc5] More ideas for v3

James Mastros root at jennifer-unix.dyn.ml.org
Wed Oct 29 17:23:02 EST 1997


There seem to be several basic questions raging about v3 (directly, rather
then specific projects that might be implemented).

1)  How projects will be chosen.  (To be chugged on any specific machine)
2)  How projects will be added to the list of distibuted.net possible
problems.
3)  What architecture we will use to suport this.

First, the architecture.  I suguest that we have four types of data/programs:
1)  The base client (handles UI and 'Net).
2)  Distributed.net metadata (the list of projects, and their
requirements/stress ratios).
3)  The core modules (chugs the data).
4)  Project specific data (the data to chug).

A sample conversation for each would go somthing like this.
Client:  I'm an intel machine running linux 2.1.60 with a JVM and XWindows.
        What clients are avaible for me?
Base server:  The Java-bytecode-awt client 3/5/7, The linux-intel-cli 3/5/0, 
	The linux-intel-xwindows 3/5/3, The linux-c-cli 3/5/3...
	(Client names are os-processor-ui.  Java counts as a OS, source as a
	processor, and awt, xwindows, and cli are all UIs.  Versions are
	given as [protocol version]/[common codebase version]/[revision of
	this client].  If somthing isn't based on the common codebase, it's
	version is on the lines of a//b.  Precise chips shouldn't be
	important, since the base client isn't a critical path.)
Client:  I want linux-intel-cli 3/5/0.
Base server:  Here it is.
...
Client: What projects are there, and what are their requirements/relitive
	stresses?
Projects server: RC5-64 is running - it needs 248 bytes of disk (I think
	that's correct - 1 block in buff-in, and 1 in buff-out - this is the
	minimal necessary, not including the core), and 0 bytes of permanat 
	storage.  It's relitive stresses are 63 integer, 0 FPU, and 1
	network I/O.  It was submitted by "The Bovine Crew", and has been
	signed by "the bovine crew".  The project's home page is at
	http://www.distributed.net/rc5/  (Etc for all projects currently 
	running).

Client decides optimal project.  It should probably present it's choice, and
the credentials and other information on each.  Note that the submitter need
not be the bovine crew, the project need not be signed by them, and that a
signature simply means that they (where they is sombody influencial)
considers it an important project.  Allowing work on multipal projects might
be a good thing to ("I want to do 50% rc5 and 50% SETI.  Don't allow rc5 to
do random blocks unless SETI is out of data").

Client:  I'm an intel pentium running linux 2.1.60 with a JVM.
        I have 32MB of RAM, and 32MB of swap.  What cores are avaible for
	the rc5 project for me?

Core server: The pentium-ml core 0/0, submitted by foo, signed by baz, the
	pentium-asm core 0/0, the intel-c core 0/

versions are in [common-codebase version]/[core specific ver], names are in
chip-language (languages are ml, asm (neumonic ml), c, java, etc.).  Give
submitted-by names, and signed-bys.  Signing a core means that that person
thinks that that core won't do anything that it shouldn't do (reformat your
hdd...).  Cores should be run in a sandbox where possible anyway, but it's a
good thing if you know that your own personal demi-god has said that the
core is safe.

Client:  I need data for the HGttG project.  Gimme some!
Data server:  OK.  Solve based on key <serial number of the universe>.
Client: The keyserver told me: "OK.  Solve based on key <serial number of
	the universe>."
Core:  The answer is 42.
Client:  My core told me the answer is 42.
Data server:  <No responce, due to the destruction of the Earth for a
	inter-galitic highway.>

As to the creation of projects/cores/clients, I imagaine anyone being able
to submit them to d.n, upon which they will be put on the lists handed out
by the servers.  This is by its very design insicure, which is the reason
for signatures.  That way, users can look at who has signed the thinger, so
that they can make a decision based on agreeing with their peers.  Also,
the homepage for each should be passed out (which need not be on a d.n
server), so that they can look their for data.

	-=- 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 mailing list