On May 12, 2009, at 11:57 AM, Robert Hailey wrote: > > On May 12, 2009, at 11:45 AM, Florent Daigniere wrote: > >> Huh. >> >> What are you suggesting here? That we re-invent the current protocol? > > Sort of... but a request which does not route; one which only checks > the datastore for the presence of a key. I believe that this idea was > rejected earlier since the request "does not propagate the requested > data," but appears to be much better security-wise than bloom filter > sharing. And we could convert a fraction of these probes into full > requests if we wanted to.
In case it is not clear, let me correct my sloppy semantics. "A request which only checks a peer's bloom filter for the presence of a key" >> The whole point of sharing bloom filters is to get rid of the >> network/node latency. We already have local bloom filters to avoid >> unnecessary datastore lookups. >> >> NextGen$ > > 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). "point of having bloom filter sharing was to..." > -- > Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090512/8466e5e3/attachment.html>
