Another suggestion, from Toast: Estimate the latest requests rank as compared to the last n requests (100 for example). Compare the position in this list with the current load (using Ians method or the standard method). Decide on that. The number 100 is not alchemy as it affects precision of routing, not routing it's self.
We keep an LRU list of the last N (say 100) requests, and their estimates. This is kept as 2 doubly linked lists, one for the LRU, another kept in order of the estimates.
When we get a request: Calculate our own estimate. Synchronize on the lists' sync object Find the LRU request, and remove it from both lists Walk the list sorted by estimates, and insert ourself in the appropriate place. Remember our position numerically - the number of nodes before us in the list. Insert ourselves on the new end of the LRU. Let X = target fraction accepted. If our rank on the list was worse than X * N, reject the request, otherwise accept it.
Toast's idea is good. I have one adjustment. The values in the list we look through must be the best estimates *of the nodes which are currently not backed off*.
For example, say we have one "fast" node on our RT whose estimate() is very small for all keys, whereas the rest of the nodes yield much higher estimate()s. Suppose the last N requests were all sent to the fast node. We then find a QR from that node and consider it backed off. Now, another query comes in. Using the technique Toast and Toad described, we would almost certainly reject the request since its estimate() would be low. But that's only because the remaining nodes in our routing table are slow. We should instead re-evaluate the estimate()s of the last N requests based on the currently available nodes.
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
