[RC5] Win32 Client Crash Side Effects

James Byers jwb19 at cornell.edu
Thu Nov 20 06:08:21 EST 1997

	I have been noticing a discrepancy between the number of blocks my Win32
client puts in the out-buffer and the number it downloads.  Through trial
and error, I have found that this discrepancy is a result of the client
losing blocks after a crash.  This crash can be either a client crash (eg
the result of setting the Win32 client to lurk mode) or the result of
resetting the system with the client running.  

	For example, at normal startup [abridged]:

[11/20/97 10:37:26 GMT] 197 Blocks remain in file
[11/20/97 10:37:26 GMT] 196 Blocks remain in file

	Then, I immediately force the client to crash (in this case by setting the
client to "lurk" mode).  Starting the client again [abridged]:

[11/20/97 10:39:00 GMT] 195 Blocks remain in file
[11/20/97 10:39:00 GMT] 194 Blocks remain in file

	There are still zero blocks in the out-buffer, and two blocks have
vanished from the in-buffer!  What seems to be happening is that the client
loads blocks into memory from the in-buffer, then deletes them from the
in-buffer before it has started checking them.  While this is a reasonable
way to code the client-in-buffer interaction, isn't there a more robust
method?  Such as reading the keyblock from the in-buffer, processing it
entirely, then deleting the block from the in-buffer and reading another?  

	I understand the client is able to restart correctly on a block that is
unfinished as the program exits normally.  From the logs, I assume that the
client tacks the unfinished block back onto the head of the in-buffer with
some record of how far it has gotten.  This behavior could be maintained by
always overwriting the full block at the head of the in-buffer with its
partially finished copy.

	While there are probably relatively few block losses this way, a small
code change (unless I am misrepresenting / oversimplifying the client
architecture) should make the number lost zero.

	If this is miles off base, outrageous, grounds for me being shot, etc. I
apologize.  It is a series of strung-together conclusions based on
observation, rather than source code. :)

	I welcome your comments,
	James Byers
James Byers                                   
jwb19 at cornell.edu
Go Big Red - RC5-64!
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