On Wednesday 13 May 2009 17:07:39 Robert Hailey wrote: > > 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.
The difference is we send it to ONE node, not to all of them. And we only have to wait for one node. > 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. Bloom filters would be checked first. If we can get it in one hop, then great, it saves a lot of load, time, exposure, etc. > > It is a given that the primary request mechanism has failed (be it > from network topology, overloaded peer, etc). No, this is a short-cut, to save a few hops, as well as to consider more nodes' stores for unpopular keys. > > 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. So it's an extension to ULPRs? We do not in fact wait for a response, but if the data is found, we are offered it, and we forward it to those who have asked for it? The difference to ULPRs being that we ask all our peers for the key and not just one of them... > > 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. It is very similar to ULPRs but we broadcast requested keys to all peers rather than relying on the peer we had routed to. > > 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. First, it doesn't shortcut. Second, the bandwidth cost may be higher. Third, the negative security impact is at least comparable.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
