[RC5] Client checkpoint file bug
BARNETTE JEFFREY D
JEFFBARN at LPFPO.kelly.af.mil
Fri Jan 2 16:11:02 EST 1998
I've seen a similar problem with the DOS v2.6403.320 client. Portion of log
[12/20/97 17:56:09 GMT] Completed block 649C989D:B0000000 (268435456 keys)
00:19:41.51 - [227196.94 keys/sec]
[12/20/97 17:56:15 GMT] Block: 649C989D:C0000000 being processed
[12/20/97 17:56:15 GMT] 29 Blocks remain in file buff-in.rc5
[12/20/97 17:56:15 GMT] 46 Blocks are in file buff-out.rc5
[12/20/97 17:56:16 GMT] Total: 46 blocks 14:51:01.27 - [226088.92 keys/sec]
Copy buffer files to floppy, sneakernet to another machine, update, copy new
buffer files to floppy, sneakernet back to DOS machine.
RC5-64 Client v2.6403.320 started. Using JDBarnette at aol.com as email
Recovered 1 blocks from checkpoint file
[12/20/97 17:59:26 GMT] Block: 649C989D:B0000000 being processed
[12/20/97 17:59:26 GMT] 29 Blocks remain in file buff-in.rc5
[12/20/97 17:59:26 GMT] 0 Blocks are in file buff-out.rc5
[12/20/97 18:00:21 GMT] Completed block 649C989D:B0000000 (268435456 keys)
00:00:53.62 - [222478.02 keys/sec]
[12/20/97 18:00:25 GMT] Block: 649C989D:E0000000 being processed
[12/20/97 18:00:25 GMT] 28 Blocks remain in file buff-in.rc5
[12/20/97 18:00:25 GMT] 1 Blocks are in file buff-out.rc5
[12/20/97 18:00:25 GMT] Total: 1 blocks 00:01:01.42 - [194196.55 keys/sec]
Two things to notice.
(1) In this instance, I stopped the client very soon after it started
working on block 649C989D:C0000000 (i.e. inside the 5 minute ckpoint update
interval). I was up and running again 3 minutes later after the sneakernet
session. When I started the client back up, it started cranking again on
the just-completed block, taking only 53 seconds to finish it off.
(2) Prior to shutdown, the client was working on block 649C989D:C0000000.
After restarting, that block was gone. It got taken out of the buff-in
file, but obviously never made it into the checkpoint file. Yes, I know the
block will be re-issued at some future time, but I still feel like I've
"dropped the ball" on a block I checked out from the keyservers.
It looks like if you shutdown the DOS client immediately after it starts
work on a new block, the checkpoint file still contains info on the
just-completed block. The simple solution for the DOS client is to wait at
least 5 minutes (or whatever interval you've put in the .INI file) after
starting a new block before shutting down to fetch and flush. This gives
the client time to update the ckpoint.rc5 file with the new block info. I
can live with that.
Coders: would it be difficult to close this loophole?
> From: Mishari Muqbil[SMTP:mishari at thepentagon.com]
> Sent: Thursday, January 01, 1998 8:09 PM
> To: rc5 at llamas.net
> Subject: Re: [RC5] Client checkpoint file bug
> There seems to be something in the readme file about the latest build of
> client fixing the bug in which the blocks get pulled out more than
> or something like that. Is the client you're using the l8est version?
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5