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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
