[rc5] An Idea of the V3 protocol

Sebastian Kuzminsky kuzminsk at taussky.cs.colorado.edu
Mon Oct 27 07:34:57 EST 1997

Chris Arguin <Chris.Arguin at unh.edu> wrote:
] Does anybody think it would be useful to provide a way for clients to
] communicate with each other.

   Yes, most useful.

]                              For example, each client tells the server
] that it has a constant connection to the Internet (assuming, of course,
] that this is true). Then a client might say, "Hey... I need this piece of
] information", or "I need somebody else to process this." Then the server
] can point out another machine. 

   Once you let the clients say "i need somebody to process this",
things change:  it's no longer a centralized system with distributed.net
at the top, proxy-servers in the middle, and us clients with our CPUs at
the bottom.  Instead you have a generalized computing resource, where
any machine may request more CPU from the network.  How much CPU is
actually made available to the requesting party depends on how many
people they can convince to part with their resources.

   Of course, if we're going to do that, then we might as well go all
the way and share all our resources (CPU, memory, disk, ...).

   Ideally the software developed would be usable and efficient in both
local distributed computers (a smallish cluster of trusted, cooperating
machines) and widely distributed computers (a huge network of mutually
untrusting, cooperating machines).

   This general resource-sharing system described above is significantly
more complicated than the current distributed.net effort.  In the Amoeba
model, hosts run process servers, with some degree of access restriction
and authentication.  These servers present an interface on the network,
and allow or deny, based on site-specific policy rules, remote users to
spawn processes.  Similar facilities exist for accessing other
resources, such as memory and disk.  Truly gigantic virtual computers
can be built effortlessly using these primitives.  (There is still the
problem of trust.)

] I think this may be useful for two reasons. First, for something like the
] chess engine, it gives you a method for propagating proposed moves so
] that you can try a depth first approach.

   Depth-first is not a viable search algorithm for chess.

]                                          Secondly, it seems that RSA-155
] takes a lot of resources. More than available on any one machine at
] points. What if we came up with a distributed memory net? Sure, it would
] be slow. But it allows the creation of a machine that COULD compute these
] values. 

   I think it would be a great reasearch exercise to implement a
network-shared memory scheme and using it for the low CPU, high memory
requirement factoring algorithm mentioned in an early RSA-155 post.
This may be so I/O intensive that using todays communications
infrastructure, the job would be prohibitively slow.  How many of the
people participating in the distributed.net computer connect to the
Internet at less than 100 kilobits per second? 

   The trick would be to make the resource sharing scheme efficient on
both fast and slow networks.


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

More information about the rc5 mailing list