[RC5] Really useful feature request

John Graves john.graves at nashville.com
Thu Apr 2 19:28:06 EST 1998

Great ideas Peter... I agree 100%.

A couple of the machines I'm running the client on are behind a firewall and
it would really be nice to see these ideas implemented. It sure would make
this type of situation more convenient to handle.

John A. Graves -- Amateur Telescope Maker, Founder & Moderator - Fidonet ATM
john.graves at nashville.com *or* starwanderer at geocities.com
Visit my WWW page or submit articles to the Electronic ATM Journal at:

-----Original Message-----
From: Peter Hugosson-Miller <pehu at im.se>
To: Rc5 Mailing list <rc5 at llamas.net>
Date: Thursday, April 02, 1998 6:58 PM
Subject: [RC5] Really useful feature request

>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
>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:
>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

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