On May 12, 2009, at 5:24 PM, Matthew Toseland wrote: > On Tuesday 12 May 2009 17:57:04 Robert Hailey wrote: >> If the bloom filters are recovering already-failed requests, then >> surely latency is not the issue being addressed. >> >> I thought that the point of having bloom filters was to increase the >> effectiveness of fetches (a more reliable fallback). > > So your proposal is that we broadcast all our requests to all our > peers, and > then what, wait for all their responses before routing outwards?
It might sound laughable like that, but the same problems have to be overcome with sending a failed request to a peer with a bloom filter hit. This is all operating on the presumption that the bloom filter check is intended to recover a failing request (no htl / dnf / etc.), and not to fundamentally change routing. It is a given that the primary request mechanism has failed (be it from network topology, overloaded peer, etc). I propose adding a new network message "QueueLocalKey" A response to which is not expected, but that a node may then "OfferKey" to us at some time down the road. As you said, upon a conventional request failing (htl, dnf, etc) a node will broadcast this message to all peers (even backed off), or at least queue the message to be sent (later/low priority). Upon a node receiving this message, it can discard it (if too many offers are pending to the requestor). Otherwise it will check it's bloom filter for the key; discarding the message if not found, and adding the key to an "offer-queue" if it is found (to be transfered whenever). If the bloom filter check is too expensive to be done at request time, we can have a single thread process all these requests serially at a low priority. If an open net peer disconnects we can dump all their requests. The actual request has already failed, we do not hold up processing; and it is a step towards passive requests. I guess that the net effect of this message on data which does not exist amounts to a bunch of bloom filter checks, so it is equivalent. And to data which does exist (but somehow failed), it will simply move the data (at some rate) into caches along a valid request path. -- Robert Hailey _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
