[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
follows:

[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]

--shutdown here--
Copy buffer files to floppy, sneakernet to another machine, update, copy new
buffer files to floppy, sneakernet back to DOS machine.
--restart--

RC5-64 Client v2.6403.320 started.  Using JDBarnette at aol.com as email
address.

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?

Jeff

> ----------
> 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
> the
> client fixing the bug in which the blocks get pulled out more than
> once....
> 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 mailing list