On July 22, 2003 01:58 pm, Toad wrote: > On Tue, Jul 22, 2003 at 07:26:12AM -0400, Ed Tomlinson wrote: > > On July 21, 2003 04:22 pm, Ian Clarke wrote: > > > On Mon, Jul 21, 2003 at 08:50:33PM +0100, Toad wrote: > > > > Umm, no. Random first hop was introduced to avoid the network > > > > forking... anyway, how would this improve getting DBRs? > > > > > > Ah yes, I was trying to remember why that was introduced. Of course, > > > the whole "network forking" danger was purely theoretical, and I never > > > really thought that it was likely to happen in a real-world network. > > > It has certainly never been observed in practice or in simulation. > > > > When playing with the CP code before I started with NG I tried disabling > > this. The node ended up ignoring most of the nodes. Think this is > > needed until the node _really_ know the network; otherwise it will tend > > to ignore many nodes. IMHO it also help hide the id of the sender since > > the same key will not always go to the same node... > > > > I have used freenet/support/sort/QuickSelector.java to give the same sort > > of functionality in NG. Just how random that first node is can easily be > > controlled in this class. > > I don't get it. Why can't you just route to a random key? That should > take into account all routing data effectively.
My thoughts were that some nodes are really in trouble, routing to them should happen very very rarely. With QucikSelection we use the fact that quicksort is unstable to get a set of nodes that are the best n out of m nodes. Because of the instability of quicksort, normally the n nodes are in a random order. This let me simpify code and made the alg faster since we worked less to get the nodes. Ed _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
