[RC5] RE: LIFO in-buffers
dtaylor at nildram.co.uk
Wed Aug 19 20:10:36 EDT 1998
> In lieu of rewriting the clients to allow the buff-in.rc5 to be FIFO
> of LIFO, there is a fairly simple change that would accomplish the same
> Instead of fetching blocks onto the tail end of buff-in.rc5, as currently
> done - it wouldn't be that much harder to:
> 1) have the fetch process rename the current in buffer to buff-in.tmp
> 2) fetch the specified number of blocks.
> 3) copy the older blocks from the renamed buffer to the end of buff-in.rc5
> 4) delete the temp file.
Actually, what I (currently, right now) do, is this:
1) Use rc5.in rc5.out and rc5.new
2) The actual cracking client is totally offline and uses runbuffers with
3) The client is also run with a few extra command line options which make
use rc5.net and fetch blocks, it does this every time I connect to the
4) when the cracking client exits with a script file i move rc5.new and/or
over to rc5.in and des.in (checking to make sure the *.in files are 8
( 8 bytes = 0 blocks + header).
5) Then i rerun the client.
6) Also, if there are no *.new files and no *.in files (with blocks), then
run another file which checks I am online(to prevent autodial) then if
fetches more blocks, and returns to the check for buffer sizes in step
I can only do this in Linux just now, the Win9X version of my rather weird
is semi-broken, because I do not want a huge MS-DOS box sitting on my screen
day just to run a batch file...
> This always puts the newly fetched blocks at the bottom of the buffer, and
> allows old blocks to be processed before they become stale. This avoids
> necessity to decide between having big buffers in case of long offline
> periods which might result in blocks at the bottom of the buffer becoming
> stale, or having small buffers which won't go stale but have an increased
> risk of being forced to generate random blocks. The client could be set
> with a threshhold of 1000:100 without risk of making random blocks nor
> of having 900 stale blocks if the client is never offline when the
> out-threshhold is reached.
Actually, if it is a slow computer which took, say, 3 months to do 1000
well, ALL the blocks it done from then on would be stale.. but, as long as
people don't go totaly insane..
> At first glance, the only obstacle I see is that there are some
> circumstances where transferring blocks from one buffer to the other could
> result in running out of disk space. (Probably caused by someone who
> deleted their log file in a year...) There could be an .ini setting that
> lets you choose between fetching the old way, or fetching this way.
hmm, my way wouldnt even have that problem (you simply half the number of
blocks you currently have set and add a few on [ You will always have
between 1 and 2 times the number you set in the buffer, because you
have 2 buffers (but one is not refreshed until it is fully empty)])
>From David Taylor
David_Taylor at msn.com
P.S. Thanks to Davehart for providing the inspiration to spend 3
days fiddling around to get this to work properly :-)
P.P.S. It could be implemented much more easily, and better if it
was directly implemented into the client.. it wouldnt need
any scripts or command line options, just a few extra ini
file settings and a lot of code (prolly easier to write FIFO buffers
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5