[RC5] Suggestion for when we Recycle Keys
Robert A. Rosenberg
bob.rosenberg at digitscorp.com
Mon Jan 11 17:01:56 EST 1999
At 02:00 AM 1/11/99 -0600, you wrote:
>"Robert A. Rosenberg" wrote:
>> I do not know the format of the list of Keys to Check but I think (if
>> this is possible) that when we start to reissue Key Ranges, that we
>> supply them in reverse order in the list - IOW if I am given 10
>> Blocks starting from X (ie: X to X+9) then LIST them as X+9 to X so
>> that I start at the end of the range and work my way forward.
>I'm not sure what this would gain us...
Once you start to recycle, you start working on the reissued blocks in the
reverse order to that being used by the original owner. Thus you do not
duplicate his/her work until you overlap. As an example User A is issued
Blocks X to X+9 and when he is up to X+5, User B is issued X to X+9 (as a
recyle). If User B starts at X (in lieu of X+9), he is spinning his wheels
doing no productive work until he gets to X+5 (or where-ever A is now in
his checking). By starting at X+9 and working back to X, there will be some
productive checking before there is any overlap.
>> ALSO, I think that when I turn in Checked Keys (or ask for more) that
>> my CURRENT set of assigned keys be sent to the Server for checking
>> against the list of already checked keys. If I have been assigned
>> keys that have been checked (due to recycling), then MY IN-Box copy
>> should be pruned of those and my IN-box optionally updated with
>> replacements for the deleted blocks. This prevents useless checking
>> and focuses on new keys (ie: Those that have not yet been turned in
>> as checked). Yes I will still be working on keys that others are
>> checking but I insure that when I select such a key AFTER having
>> checked in, that it will be one that has NOT YET been reported as
>> checked as of my check-in time.
>For RC5, this would serve no purpose. Since we have subspaces in RC5, we can
>allow a subspace to lie dormant for a period of time before we recycle it, so
>we loose very little processing power. For DES, we don't have that luxury, so
>we loose work to duplication when we do a recycle. So, for DES, it is
>desireable not to have to recycle.
>Unfortunatly, it would take a large effort to enable our network to accept
>blocks back. The master, proxies, personal proxies, and clients would all
>require major changes.
This was more a suggestion for a new feature to be considered. It can be
implemented on a gradual basis. First the Servers (to support it). Then
Clients and Proxies can take advantage of the functionality. All that is
needed on the Server side is to accept a list of Blocks and return the list
marked "Checked" or "Not Checked" for each Block. The Client/Proxy then
checks the returned list and prunes (ie: Throws away) from the IN-Buffer
any that are marked "CHECKED". It can then do a Fetch to refresh its
buffer. No Blocks are being returned to the server for reissuing (that was
a different request) so all that is needed is the status support.
>The best solution is too minimize the amount of DES blocks that might be
>lost... in other words, keep your buffers as small as possible.
>> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
>> rc5-digest subscribers replace rc5 with rc5-digest
>Jim C. Nasby (aka Decibel!) /^\
>jim at nasby.net /___\
>Freelance lighting designer and database developer / | \
>Member: Triangle Fraternity, Sports Car Club of America /___|___\
>Give your computer some brain-candy! http://www.distributed.net Team #1828
>To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
>rc5-digest subscribers replace rc5 with rc5-digest
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5