[RC5] Win32 Client Crash Side Effects

Ryan Dumperth woodie at indy.net
Thu Nov 20 06:46:06 EST 1997

>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?

This would only work in situations where the in buffer is not shared.
Otherwise, every client would be working on the same block, since it would
sit there until one of them finished it. When the client starts up, it
pulls a block from the buff-in. If it is shut down normally, a partially
completed block is returned to the buff-in.

Using the checkpoint file to save the block in progress to disk is the way
to avoid losing a block due to an unexpected loss of your OS. When I run a
non-gui client, I use rc564 -cktime 1 so that it saves to disk every
minute. At most, I will lose 59 seconds of work, in case of a crash.

However, if your app is being run from a shared directory, you absolutely
cannot use a checkpoint file, as sharing it will result in lots of
unpleasantness. Now if the Win32 GUI and Mac client could actually use
checkpoint files, I might acutally be able to benefit from this feature.
It's only marginally ironic that the two most used clients lack this vital
feature, especially since their OS's are notoriously the most crash-prone.
Oh well. Participating in distributed.net is all about learning to do
without, eh.


Public Key: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x8D98E677
PGP Key Fingerprint: 4913 67E3 BCA8 6326 F404  6005 6C1B D2D8 8D98 E677
PGP, use it or lose it.

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