The following is relevant to Robert's thread. It's close to what he was talking about. TheSeeker is the other big contributor.
On a node which does a lot of downloads, the peers approach a flat circle: They are more or less evenly distributed. On a node which just routes we get a very strong small world effect. This is LRU in action: It is adapting to the user's demands. Even though we limit the proportion of local requests to be similar to those from any of our peers, if the download is successful, it will rewire our connections to be more widely distributed to improve performance for the majority of *successful* requests. What effect does this have on the network as a whole? It is probably bad - the external requests, which are the majority, are then routed very badly. Should we only start path folding once HTL drops below the caching threshold? PRO: - Routing is no longer disproportionately optimised for local requests. Hopefully higher overall performance. - Prevents the trivial opennet path-folding-originator-sampling attack. CON: - No direct theoretical backing at present. We need to talk to a theoretician. - We should not deploy this while there are other big network things happening. A further thought: Since we don't cache until the HTL drops below the caching threshold anyway, tunneling would not necessarily be as expensive as thought? The cost is not the cost of relaying the data, *we have that anyway* by our policy of not caching until HTL falls below the threshold - the cost is the cost of relaying the data WITHOUT CHECKING THE LOCAL CACHES. On average we go 2 hops at HTL 18, then another hop at 17. And if we can have multiple tunnels divided by keyspace location, that might further improve performance? The catch would be how to create short tunnels securely. Security of a tunnel primarily means, in the first instance, that the peer that the tunnel goes through first cannot compromise the entire tunnel. Unfortunately this is hard, as I've explained before... random rendezvous tunnels might work at least as a first approximation ... But we'd need detailed work, probably including attack simulations, to know whether it would actually work, and how hard it would be to break ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110126/49497599/attachment.pgp>
