On Thursday 22 November 2007 11:03, Matthew Toseland wrote: > Looks like a combination of some variant on NGR (vivee has done research > suggesting something like NGR could work), and Bloom filters. Both ideas are > old, but they probably have some new variant on them. They claim a 30x > increase in hits ratio and 6x transfer rate. > > Bloom filters aren't that difficult, the problem is that we can't implement > them prior to premix routing and still have any realistic anonymity against > local attackers. Maybe the paper's "fuzzy" proposal helps. > > Anyway, I haven't actually bought/read the article yet. > > http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/ccgrid/2006/2585/02/2585toc.xml&DOI=10.1109/CCGRID.2006.136 >
Okay, details: It is based on 0.5. "File mesh" is a bitfield over the keyspace, indicating which parts of it the node has data for. Presumably their nodes route preferentially to nodes which have a 1 in the hole corresponding to the slice of keyspace the document they are searching for is in. Obviously determining how big this needs to be is a problem. Advantages over Bloom filters: 1) It also indicates nearby keys, 2) Anonymity is less compromised. "Preferential Partition Routing" is partitioning the network into groups by bandwidth limits, and routing only to nodes in a higher group, in order to avoid bottlenecks on the return path. Is there anything here we could use in 0.7? I don't see how we could directly use file mesh, unless the length of the bitfield is very large. Bloom filters might help for very popular documents and the last few hops, as Oskar has advocated for a long time now. However, they would make the local request security situation even worse, unless we implement premix routing first, and even if we do, we might have to premix out more hops than we have Bloom filters for? Would it be useful to use file mesh directly even? How would we determine an appropriate mesh size? Also, vivee has had some results suggesting that it is possible to usefully performance-bias 0.7 routing... Comments? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071122/9b43cddf/attachment.pgp>
