[RC5] DNet questions (repost)
Zorba the Hutt
zorbathut at uswest.net
Sun Oct 6 22:46:59 EDT 2002
I'd think most of what a distributed client does would actually be pretty
wrappable . . . in general, you've got a system that requests packets of
"work" from a server, processes them, and returns some data (in rc5's case
presumably the numbers of any "interesting" keys, in OGR the number of nodes
processed and the smallest ruler found, in the case of, say, folding at home,
the end state of the simulation). All you really need at that point is some
variety of progress meter, whether it be a ratio meter or a progress number
(the difference between "74% done" or "28/284 parts done" and just a simple
"1995 nodes done, total unknown") and, hey, you're done. Some projects might
allow queueing, some might not, some might have some sort of timeout on
stale packets or some way of continuing processing on a packet if the
network can't be reached, some might have a way of generating random
packets, but in general, there's only going to be a few different setups.
The actual binary data can vary dramatically based on implementation.
A generic distributed client should be pretty possible - the "efficient"
part is the core anyway, and that can be custombuilt.
----- Original Message -----
From: "Timothy Marsh" <Timothy.Marsh at usm.edu>
To: <rc5 at lists.distributed.net>
Sent: Sunday, October 06, 2002 2:30 PM
Subject: Re: [RC5] DNet questions (repost)
> It seems to me to be possible to create a parent/child application,
> question is whether or not it would actually be beneficial in our case.
> dnet client as it stands right now is very compact and efficient (thanks
> the hard work from dnet staff). Creating a parent/child form of the
> application would definitely create more overhead and the only benefit
> be...? When dnet begins a new project they typically recode a new client
> using some code from previous clients that doesn't need to change and
> writing new code to fit the project. Then they and others work
> to compact the code and make it more stable and efficient. It seems to me
> that creating the parent application would be of little help. As I see
> parent applications keep coders from having to recode from scratch every
> time they want to add something, but in dent's case, the application is so
> specialized that most of the code has to be rewritten anyway for optimum
> performance. I would think that the parent application would only
> overhead and reduce the ability to optimize the program.
> I do believe this type of application may be more useful for other
> of applications such as the ones that deal with medical applications, etc.
> But the parent application may not be as ideal as thought of below. A
> "medical experiment, a math experiment" could not just be inserted into
> parent application. Software would have to be developed that not only
> performed the experiment (preferably in a highly parallel fashion), but
> would also have to be tailored to use the "hooks" in the parent
> which may also require some understanding of the parent program and
> distributed computing in general.
> ----- Original Message -----
> From: "Marco Tedaldi" <marco at tedaldi.net>
> To: <rc5 at lists.distributed.net>
> Sent: Sunday, October 06, 2002 10:52 AM
> Subject: Re: [RC5] DNet questions (repost)
> > On Fri, 04 Oct 2002 19:57:03 -0400, blitz wrote:
> > >Not being a programmer myself, this might sound strange to you, but is
> > >there any way a generic client can be done that would allow someone
> > >insert their work payload?
> > >Then a medical experiment, a math experiment etc. could be inserted as
> > >task, (and be much easier to set up quickly), and the client would be
> > >amicable to any task that used its hooks.
> > >
> > qoopy was trying sometink like this... a java-client.
> > http://www.qoopy.net/
> > i think it's just a proof of concept, but looks interesting.
> > In the moment the project seems to be dead :-(
> > With such an approach of a parent-application which is done for
> > the networking stuff, and a child-application which is the
> > "cruncher" i think one can solve differente problems. Ok, one
> > can GEt problems with such an approach too :-)
> > Automatic update of the "child" to a new version could be a cool
> > feature, but also a security-breach...
> > bye
> > Marco
> > --
> > Dieses Mail ist zu 100% biologisch abbaubar
> > --
> > To unsubscribe, send 'unsubscribe rc5' to
majordomo at lists.distributed.net
> > rc5-digest subscribers replace rc5 with rc5-digest
> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5