[RC5] Client checkpoint file bug -- answers?

Tim Charron tcharron at interlog.com
Sat Jan 3 11:16:44 EST 1998

Some comments on checkpointing...
     -- All non-command line clients were writing checkpoint files,
        but never read them back in at startup.  This caused lost     
        work on shutdown.  This has been fixed in fracbuild 335.
     -- When the client finished a block, it didn't re-write the
        checkpoint file until the next scheduled interval.  If the
        client was shutdown cleanly, this didn't matter, since the
        checkpoint file would be deleted.  If it was shutdown, but 
        not cleanly, and this occurred before the next checkpoint 
        interval, then the checkpoint file had information that was   
        duplicate of completed blocks which were saved elsewhere.
        (output buffer, or keyserver).  This has been fixed 
        in fracbuild 340.
     -- Note that DOS clients will never delete their checkpoint      
        files at shutdown, since there's no way for the client to
        know its being shut down.  However, even they should avoid
        the duplicate information problem in 340.

These problems likely account for the bulk of duplicate blocks.  As 
well, this would explain some situations where the server's tally of 
your blocks doesn't match your proxy or client logs, since duplicates 
are purged at the server level (correct me if I'm wrong here, 

-- Tim
Tim Charron
tcharron at interlog.com
tcharron at ctfinance.com

An idle computer is a terrible thing!  http://www.distributed.net/

To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list