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 :-(
participants (2)
-
ab411＠detroit.freenet.org -
Piete Brooks