[RC5] Win32 Client Crash Side Effects
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,
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