On Tue, Sep 30, 2003 at 09:43:53AM -0700, Ian Clarke wrote: > 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.
Maybe. How do we want to bias for new nodes, exactly? The mechanism I wrote was simply that new nodes have ludicrously good estimators as created, so they will quickly get routed to and learn that they aren't quite so good as they thought they were. > > > 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). No. We have two separate variables. In fact we have more. NGRoutingTable.MyDiscardValue.compareTo() We have successTime, and accessTime. successTime takes precedence and is only updated on transferSuccess. accessTime is updated whenever we get just about anything from the node. > > > 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 -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
