[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
done/are doing.

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 mailing list