[RC5] RE: LIFO in-buffers

David Taylor 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
instead
> of LIFO, there is a fairly simple change that would accomplish the same
thing.
 >
> 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
rc5.in
  3) The client is also run with a few extra command line options which make
it
     use rc5.net and fetch blocks, it does this every time I connect to the
net...
  4) when the cracking client exits with a script file i move rc5.new and/or
des.new
     over to rc5.in and des.in (checking to make sure the *.in files are 8
bytes
     ( 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
I
     run another file which checks I am online(to prevent autodial) then if
i am
     fetches more blocks, and returns to the check for buffer sizes in step
4.

I can only do this in Linux just now, the Win9X version of my rather weird
idea
is semi-broken, because I do not want a huge MS-DOS box sitting on my screen
all
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
the
> 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
risk
> 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
blocks...
well, ALL the blocks it done from then on would be stale.. but, as long as
the
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
hasn't
> 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 mailing list