[RC5] Disappearing blocks...

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Thu Mar 5 13:46:46 EST 1998

     Both scenarios are dangerous, but omit a reasonable alternative.
     The buff-in and buff-out are coalesced into a buff file.  The buff 
     file is a collection of block records.  A record contains a block 
     and a checkpoint field.  Clients lock buff records, continuing to 
     work on a block until it is completed.  When a block is completed, 
     the client attempts to lock every block.  If it locks more than the 
     threshold setting for flushing, it flushes all the blocks it has 
     locked, otherwise it releases all its locks.
     When a client attempts to start a block, and fails, it locks a fetch 
     threshold sized collection of blocks at the end of the buffer file 
     (and a special semaphore record at location ... 0, say) and fills 
     them with fetched blocks.
     Clients that cannot communicate over the network short-circuit 
     through this by not attempting to fetch or flush.
     The semaphore is used to indicate that at least one client is 
     fetching (so no other client needs to do so.)  If the multithreading 
     is left intact, then the client that does the fetch has until the 
     next client to finish a block finishes another block to fetch.  In 
     fact, it could release its locks as blocks are fetched.
     Flushed blocks can be marked unused and reused on subsequent 
     Locking helps ensure that a given block is only attacked by one 
     client at a time.
     The flush locking shouldn't cause a race condition if locks are 
     attempted in sequential order through the file.  Since the only 
     blocks that will be locked are those that are completed, no working 
     client will block on the lock.
     This extends checkpointing to shared-file configurations.
     There may be a detail or two missing here, but I suspect that the 
     outline is sound.
            -- Eric Gindrup ! gindrup at Okway.okstate.edu

______________________________ Reply Separator _________________________________
Subject: Re: [RC5] Disappearing blocks... 
Author:  <rc5 at llamas.net > at SMTP
Date:    3/5/98 10:30 AM

On 04-Mar-1998, Charles Petras wrote:
> So, I suppose my question in regard to this feature is, is this a desirable 
> state of affairs?  Shouldn't there be a check to make sure that any given
> block has been processed into the out-buffer before it's deleted from the 
> in-buffer?
Which is the more dangerous scenario:
o checked blocks are lost due to power/machine failure and are never
  submitted to the keyservers as 'tested'.  As a result, these blocks 
  are ultimately re-assigned and the work is duplicated.
o The block containing the solution is placed in the out buffer as soon
  as the client removes it from the in buffer.  Due to power/machine 
  failure, this block is accidently submitted to the keyservers as having 
  been tested when in reality is was not.  As a result, we will reach 100% 
  keyspace searched without having ever received a success report
  on the winning block.  This block is marked as tested and is 
  indistinguishable for all other tested blocks.
Client operation should *always* be structured with the integrity of the 
project having priority over the individual's ranking in the statistics. 
Even if the odds are one in a million of a particular error occuring, 
then we can reasonably expect the error to occur almost 70,000 times 
over the course of RC5-64.  :)
|David McNett      |To ensure privacy and data integrity this message has| 
|nugget at slacker.com|been encrypted using dual rounds of ROT-13 encryption| 
|Birmingham, AL USA|Please encrypt all important correspondence with PGP!| 
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