On Tue, Sep 30, 2003 at 08:12:31AM -0400, Ed Tomlinson wrote: > 1. The NG weight calculation contains 4 terms, wSF, wTF, wDNF, wSuccess. > The last two are conditional on pSF (and pConn which is not used now). When > a node is busy its pSF quickly reaches .99 or larger. This tends to damp out > any wDNF/wSucess info so, in effect when we are routing to busy nodes, we > route randomly. If we remove the (1-SFp)*(1-pConn) factor from these terms > we would try the busy nodes in order of specialization.
But that term is there for a reason - namely to discourage routing to busy nodes in a manner that tries to balance the risk that the node will QR with the benefits of routing to that node. Getting rid of that term will eliminate NGR's load balancing. > 2. When estimating weights, if pDNF is zero, wDNF can be less than zero. I > suggest that, when the estimator for a node returns zero for pDNF (it has no > info a this time) we would be better to use pLegitDNF. i.e. add if(pDNF==0) > pDNF=pLegitDNF; Yes, I think there is a general argument to be made that we should use global averages when we don't have enough node-specific data for a given estimate. > 3. In the routing table, we currently keep lots of nodes that are maintaining > high pSF ratios. This implies that they are very busy. In the LRU logic used > for node replacement I suggest that nodes getting SFs not have their access > time updated. This would mean they would drop off the routing table more > quickly. This possibily could be applied to TFs too but not only if SF is not > sufficient. Absolutely, I would go one further and say that access times should only be updated with a node successfully returns data - this is a *major* issue and could be having a serious negative impact (it would explain the slow node-turnover in the RT causing it to fill up with overloaded nodes). > 4. When a node sees a reference for node not in its routing table it adds the node > to it - a reference hints to us that the referenced node wants traffic. Why not use > that info for nodes in the rt too? Probably makes sense, but remember that every time we add a new ref, and old one has to die. I would implement (3) and see if that addresses the node turnover problem before we implement (4). > What I propose is to peturb the rpSearchFail > average down when we see a reference for a node already in the rt. We probably > want to add code to limit this to one peturb until a request is processed. This > would prevent a bad node from attacking by sending reseting all references. > I have the code to implement most of this written. What do you mean by "peturb"? Peturb how? As described here it smells like alchemy, is it? Ian. -- Ian Clarke [EMAIL PROTECTED] Coordinator, The Freenet Project http://freenetproject.org/ Weblog http://slashdot.org/~sanity/journal _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
