[RC5] Block Returning
rc5 at xfiles.nildram.co.uk
rc5 at xfiles.nildram.co.uk
Mon Jan 11 18:10:25 EST 1999
This idea wasn't entirely mine, however I think it is a good
one, so I have thought about it abit (when I was supposed
to be working :) and decided to post this.
If there was a method for returning blocks to the master
server for reissuing, before the keyspace is reuissued,
it would reduce the amount of duplicate work done - especially
in contests like DES-III where the keyspace will probably
be reissued in under 24 hours.
My idea is: The keyserver has another settable option
like scheduledupdate, called, eg, maxblockage, or reissueperiod
or whatever (one per contest). When the proxies connect to the
master, the block contains the date the block was issued (which
could be added by the proxy to reduce load on the keyserver).
This is then passed down through the pproxies and down to the
clients (all of which also store the maxblockage values).
When the clients or pproxies (even full proxies) go to do an
update, they also check the age of all their blocks, to make
sure it is under maxblockage. If they are not, it will
return any stale blocks, and fetch new ones.
No stale blocks. No returns required.
In buffer full. No fetch required.
Flushing 4 blocks.
24 blocks stale! Returning...
Out buffer empty. No flush required.
Now maxblockage (RC5) could be set to, say, 2 months (or whatever -
I dunno how often keyspaces are reissued in RC5 with the
bigger master HD)
And maxblockage2 (DES) could be set to 6 hours, so any block over
6 hours old would be returned, to prevent redundant work.
(NOTE: The client would not connect by its self if it
discovered stale blocks during normal cracking, or it would
at least be configurable [autoreturn=0,1 ?])
Of course, this setting would have to be carefully considered..
Otherwise the clients could put an insane load on the proxies/master
by returning their blocks every few hours, before the master server
ever recycles the blocks...
As long as the time isn't too small, it doesn't really matter, but
with DES it should probably be about the same as the time between
recycles, so that clients only return blocks which would be given
to other clients.
I realise it would be a hard idea to implement, as the
entire network would have to be updated - but this was what
I thought about what is now the 'scheduledupdate' feature,
and, well, it has been implemented.
Also - it would be a useful feature for all contests, including
future ones. It would be most useful for timed contests (such
as DES), however it would be useful for ALL contests which
require recycling, how ever rarely. It could also be used
as a method to quit the contests - although you could just
delete the whole thing, if you returned the blocks, it would
reduce the need for recycling, and the possibility of
recycled work (albeit not by very much).
Please Note: This was very long, and probably pointless, so sorry :)
E-Mail: dtaylor at nildram.co.uk.spam
[Remove .spam from e-mail to reply]
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5