Pre-allocating key segments

-----BEGIN PGP SIGNED MESSAGE-----

Christian Wettergren <cwe@Csli.Stanford.EDU> writes:
>If the client is unable to retrieve a block from the server, I suggest
>it just picks a random block and starts working on it. I may very
>well not be allocated to someone else, and then the client was able
>to do something good in the meantime even though it didn't get a
>proper key alloc. 

Not only that, but the client ought to allocate some keyspace before it
needs it, as I think one other cpunk suggested.  For instance, if it has
four segments allocated and it's done three of them, it should fork a
process to begin requesting four more segments *while* it is scanning
the last segment, rather than waiting until after it is done and leaving
the machine idle until it can alloc more keys.

David R. Conrad, ab411@detroit.freenet.org, http://www.grfn.org/~conrad
Finger conrad@grfn.org for PGP 2.6 public key; it's also on my home page
Key fingerprint =  33 12 BC 77 48 81 99 A5  D8 9C 43 16 3C 37 0B 50
Jerry Garcia, August 1, 1942 - August 9, 1995.  Requiescat in pace.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCUAwUBMEHCiREcrOJethBVAQHqfwP4xfVbdkyR19WA5k4oC0GjW80s3nNrLkXZ
mYspBE8e01waJ+6NYkeyvE4lPzW4OwkKTAtZV64GWovpjsyYh4bb7/mkpkdOktAZ
J9DkHXouQ5M23FImbIcfkVUqQdR5tmSdHQqOpUNYPVqT3JZR6IC9vzwYoqcnQWyY
WIIGs8DTUA==
=9Y8g
-----END PGP SIGNATURE-----

--
David R. Conrad, ab411@detroit.freenet.org, http://www.grfn.org/~conrad
Finger conrad@grfn.org for PGP 2.6 public key; it's also on my home page
Key fingerprint =  33 12 BC 77 48 81 99 A5  D8 9C 43 16 3C 37 0B 50
Jerry Garcia, August 1, 1942 - August 9, 1995.  Requiescat in pace.

>> If the client is unable to retrieve a block from the server, I suggest
>> it just picks a random block and starts working on it. I may very
>> well not be allocated to someone else, and then the client was able
>> to do something good in the meantime even though it didn't get a
>> proper key alloc. 
> Not only that, but the client ought to allocate some keyspace before it
> needs it, as I think one other cpunk suggested.

I'd prefer to keep the number of segments "lost" if a brloop ceases.

I have written a "local CPU farm" caching server which runs on a robust
machine and grabs chunks from the root server and farms them out to local
machines (running as the same "ID").
This logs all the client transactions so that you can work out if any keys were
allocated to machines which failed to ask for another segment -- you should
assume that that segment was not searched.

With the Big Boys using that, and better code, I hope that server congestion
will not be a problem.

> For instance, if it has
> four segments allocated and it's done three of them, it should fork a
> process to begin requesting four more segments *while* it is scanning
> the last segment, rather than waiting until after it is done and leaving
> the machine idle until it can alloc more keys.

That means that if it crashes, 8 segments are left unACKed :-(