Re: Larger blocks

Nelson Minar (nelson@media.mit.edu)
Sun, 20 Apr 1997 23:04:21 -0400


Having a host dial up every hour just to fetch another piece of
keyspace is a bad idea. People pay for dialup time. People use their
phone lines for other things.

One thing that would work reasonably well though is to have a client
go on "autopilot" mode if it can't talk to the server. It could pick
some other part of keyspace on its own and start cracking that, and
save up the results to report back to the server in one big chunk. If
the server can support this kind of reporting, it should work nicely.

What chunk of keyspace should the client pick in absence of a server
telling it what to do? Several options:

1 Completely randomly. I think this might be a good idea, since it gives
some redundancy in the checks. It's also very easy to do. But it kind
of goes against the philosophy of the server.

2 Just try the next chunk, lexicographically - the server should then
assign keys to different IP addresses with big skips to minimize the
chance of collision. This won't work well as the keyspace fills in.

3 Have the server actually suggest several chunks to the client each
time a connection is made. The client should just ignore all the
other chunks if it can connect after finishing the first one, but if
it can't connect then it should go ahead and work on the next block
with reasonable assurances it'd be useful. This is a modification of 2.
It gives some of the benefits of bigger chunks without the risks of not
reporting intermediate results.

All of these solutions require work. Is the seldom-connected-host a big issue?