[RC5] Really useful feature request

Peter Hugosson-Miller pehu at im.se
Wed Apr 1 23:03:56 EST 1998


Hi there!

After over 4 months and nearly 7,000 cracked blocks, most of them mailed
from work to home for flushing, I finally have what I think is a couple
of great ideas for future client versions.

For those of us who, for one reason or another, manually have to move
blocks to/from a machine that can't fetch or flush on its own (it's
sitting behind a firewall that doesn't let the client through, for
example), the actual process of moving the blocks in and out has been a
bit of a pain.

To move blocks out for flushing isn't so complicated, just move the
buff-out.rc5 file out of the client directory, and a new one will be
created next time the client wants to write to it. But to move blocks in
is a bit more complicated. One has to stop the client, move the
buff-in.rc5 file to another directory, move the new buff.in.rc5 file
into the client directory, and re-start the client.

This means that one needs at least two buff-in files: the one that's
running, and the one to which blocks are fetched on the home machine
(assuming one doesn't wait for the client to start generating random
blocks). As the buffers are LIFO, those blocks that remain in the two
buffer files have a lower chance of ever being checked, too (same
assumption).

So here comes idea #1:

For clients running in offline mode, give the option to specify a local
fetch directory. Let the client check for the existence of a buff-in.rc5
file in that directory each time the working buff-in.rc5 file is empty,
and if it exists, move it to the client directory, and start processing
those blocks. Otherwise, start generating random blocks as before.
Simple, easy to implement, and _very very_ useful.

And, as a logical spin-off from that idea, here comes idea #2:

When the buff-out.rc5 file is full, do a local flush to a buff-out.rc5
file in the directory mentioned in idea #1. I guess it would then be
called a local fetch/flush directory.

Now, if the developers wanted to be a bit more ambitious, and building
on idea #2, here comes idea #3:

Make an option to specify an e-mail address to which completed blocks
can be sent. After performing a local flush, that file could then be
sent as an attachment to an e-mail message and sent off for flushing.
The file could then be renamed to mailxxx.rc5 (where xxx is a serial
number, increasing for each already existing mailxxx.rc5 file), and one
would then delete it manually once it had arrived safely at its
destination. Not that I'm lazy or anything ;-).

But, seriously, Idea #1 is an absolute must. Idea #2 would be nice to
have, and idea #3 would be the icing on the cake. BTW this is _not_ an
april 1st joke, please take me seriously on this!

--
Best regards,

Peter Hugosson-Miller

Send some money to distributed.net today. Visit EyeGive:
http://www.eyegive.com/html/ssi.cfm?CID=1098&email=hugge@bigfoot.com
Just visiting does good and telling your friends makes it meaningful
"Windows: The choice of a gullible generation."

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list