[RC5] Wheres the blocks?
Robert A. Rosenberg
Bob.Rosenberg at digitscorp.com
Sat Jan 9 22:45:41 EST 1999
At 15:21 -0500 on 01/09/99, John Campbell wrote about Re: [RC5]
Wheres the blocks?:
> The problem is that there's no real way to tell whether a block
> that's been assigned is lost or just waiting on a slow machine. The solution
> is to keep buffer sizes small and, for the slower machines, go after the
> smallest blocks you can get, to keep the latency times of your blocks as low
> as you can get it so the keyserver doesn't reassign the blocks you've
It would also help if there was an option to Flush (ie: Return for
recycling) buffers in the IN buffer. Once a block has been assigned,
it is "Lost" until you loop around and recycle it or the "owner"
sends it back marked "Checked." If someone wants to shut a machine
down, why not let him return the unchecked blocks and let others get
a crack at it (he can refresh the IN buffer when he next connects).
This also keys into a BUG/DESIGN Flaw that I've found. When I stop
the process, the current block gets returned to the IN Buffer marked
x% done and when I start up it gets selected and resumes where I left
off. If, OTOH, my Client crashes, there is no record that I was
working on the block and when I restart, the block is no longer in
the IN Buffer and the number of blocks is now reduced by 1. Thus the
Block in Process at the Crash is LOST and must wait to be reassigned.
I think the client should log the block back to the IN Buffer in
"Stopped" state with the % Done (just as it does when I REALLY shut
down) every time it updates the Status Display. Thus ALL restarts
after a crash will resume just as if there were a normal shutdown.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5