Ian suggested only keeping one reference per node in the routing table, and that was met with some strong reactions, the main objection being that is throws away a lot of information that could be useful.
Maybe we need a new routing algorithm. But I'd like to propose a very simple alternative way to deal with the feedback loop that leads to "ubernode election." Basically what happens is that the number of requests you route to a node is roughly proportional to the percentage of references in the routing table owned by that node. Plus, in the beginning when there are only a few refs, whichever ref is closest to either end of the keyspace-line will attract a disproportionately large number of routing hits. So you start to get a lot of refs to one node at one of the ends of that line, and it just takes off because the more refs that node has, the more it gets. Now, in the 0.4 routing table we have a hard limit on the number of refs and the number of nodes. Currently we're using default values of 1000 and 100 respectively. So when the maxNodes limit is exceeded, I am dropping the node with the lowest ref count. My proposal? I'd like to drop the node with the _highest_ ref count instead. This makes a lot of sense if you think about the equilibrium situation we want to achieve, where no node in the routing table is allowed to have a ridiculously large number of refs (i.e., be an ubernode). It's also an elegant way to address the "honest cancer" attack, where a node resets the DataSource to itself more than it should to attract refs. I've mentioned this to a couple people and the general reaction is that the approach is "too strong." Maybe so. One compromise would be to only drop the "top dog" if the number of refs owned by that node exceeds maxRefs/maxNodes. Thoughts? -- # tavin cole # # "Technology is a way of organizing the universe so that # man doesn't have to experience it." # # - Max Frisch _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
