[RC5] Really useful feature request

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Fri Apr 3 14:48:15 EST 1998


     Idea 1 can be handled using a checkpoint file.  The format of a 
     checkpoint file appears to be the same as that of a buff-in.  So, a 
     workable procedure is:
     1) Stop the client.
     2) Rename the buff-in to the checkpoint file
     3) Move the newly imported buff-in in as the buff-in.
     
     The checkpoint file will be exhausted before the buff-in file will 
     be touched, this helps keep your average block turnaround time down.
     
     If you're having trouble with buff-outs, then modify the procedure 
     as follows:
     1.1) move the buff-out to safety.
     
     I've made batch files to do this for the pile of DOS clients I have 
     running.
            -- Eric Gindrup ! gindrup at okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: [RC5] Really useful feature request 
Author:  <rc5 at llamas.net> at SMTP
Date:    4/1/98 11:03 PM


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
     
     

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