[RC5] Disappearing blocks...

John Campbell jcampbel at lynn.ci-n.com
Thu Mar 5 11:58:03 EST 1998


On Thu, 5 Mar 1998, David McNett wrote:

> 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.
> 
	Better than either of these would be for the block to be left in the
in buffer until it is successfully checked, then to be placed in the out
buffer and removed from the in buffer. That avoids both "losing" blocks to
power failures and the possibility of submitting unchecked blocks. It'd get
real messy if the buffers were being shared, though.
	Best of all, of course, is to just use the checkpoint files and
recover those lost blocks, work and all. :)

---
John Campbell
jcampbel at lynn.ci-n.com

QotD:  Those who expect to reap the blessings of freedom must, like men,
undergo the fatigue of supporting it.
--
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