On July 1, 2003 10:44 pm, Ian Clarke wrote: > On Tue, Jul 01, 2003 at 10:36:17PM -0400, Ed Tomlinson wrote: > > A present for everyone. I have updated experimental with a version of NG > > routing. This is very much a work in progress. So it uses the formula > > below for its routing weight. I strongly suspect we need to add some > > terms to this. For instance, this is not affected by connectFail(s) or > > queryReject(s) both of which are important. If we do not account for > > them we end up trying to route to a node that is always failing... And > > yes this can happen now. > > > > So that brings up the question, what terms do we need to add? and why? > > A connectFailed and/or queryReject should add a penalty as follows: > > rt_estimate += prob_connectFailed * > (time_connectFailed(node) + time_globalRequest) + > prob_queryReject * > (time_queryReject(node) + time_globalRequest) > > This is because the cost of either of these is the cost of waiting for > the connectFailed or queryReject to occur, plus the time required to get > the data from someone else.
What is time_globalRequest? I assume its the estiminated time for a successfull get of the key in question (not 100% sure about this assumption though). OK. After comments on irc, I will convert much of the fixed point stuff to floats. While doing so I will also convert most of the counters for message success rate, connectFailed and queryReject to decaying averages and add the above terms to the NGweight method. To start with I will probably ignore the time_connectFailed(node) and time_queryReject(node) terms (I'll setup methods they will not do much yet). This should not affect the results much as these times are going to be much less than time_globalRequest(key) - node the key on that. How much do we want for favor open connections? Its easy to ask the OpenConnectionManager (ocm) if there are idle connections to a node. If there are idle connections we do not have to route so prob_connectFailed can be set near zero (there is a small, measureable, chance some other message can steal the idle connection). Do we want to do this? Ed _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
