On Friday 12 November 2010 13:01:31 Volodya wrote: > On 12.11.2010 0:06, Gerard Krol wrote: > > Hello everyone, > > > > I've spent some nights trying to understand the way Freenet builds and > > maintains its opennet topology. The goal is to obtain a small world > > network (without hubs). The small average path (hop) length is good > > for performance, while the large degree of clustering makes it easy to > > find the node that has the exactly key we are looking for. > > > > The current system, as I understand it, has a chance to short circuit > > a path. This is called "path folding". When any data is sent a node > > will attach a noderef if it is interested in more peers. The data and > > noderef will be routed across the network to the same location as the > > data until it reaches a node that wants to have more peers and that > > rolls success on the "path folding dice". If so, the nodes will > > connect to each other and a shorter path is formed. > > > > I think this behavior will cause us to connect to *clusters* of peers. > > This is due to the path folding request traveling over already > > established routes. If those peers are close to us its not a problem, > > but we might end up with a few connections to a cluster of peers far > > away from our own location. Take a look at your "Peer Location > > Distribution" now and tell me if that is the case. > > > > My proposal is to change the way path folding works and make it less > > "path folding" and more "peer finding". If we need a connection we > > send our noderef to a random location chosen with chance proportional > > to 1/d, where d is the distance between us and the chosen location. If > > the final node on that location wants more peers we connect. This will > > force an 1/d distribution of our peers, which should be enough to > > obtain a small world network. > > > > The current peer disconnection algorithm looks OK to me. It will every > > once in a while drop the peer for who it is the longest ago that it > > was successful in fetching a key for us. > > > > Regards, > > > > Gerard > > How would you control an attacker who wants to dominate a specific area of the > keyspace then? Ok, you can have a die which decides whether or not to connect, > but an attacker can just keep flooding the particular space with requests and > wait for the eventual connection.
This argument holds to some degree against announcement... > > Note that you are not even giving an opportunity for the peers along the path > to > connect, you are talking about the final location. -------------- 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/20101112/da7c175e/attachment.pgp>
