Say you want to get a will made out and you also need to get dinner. Your lawyer is busy, but your chef is free. Your chef is not very good with making wills, so obviously, you'd decide to get dinner now, and then see if your lawyer is free afterwards.
As far as I understand it, that's not how routing works right now. Right now, we put the two items in a list:
1. will 2. dinner
We start at the top of the list, and see who is going to make our will the fastest. Since our lawyer is "backed off" at the moment, we go with our chef.
The solution is to look ahead in our list until we find a nice query/node combination. This could be done by sampling a certain number of queries from the ticker randomly. Then, for each one sampled, and for each node in the RT, calculate estimate(). Pick the *combination* with the smallest value.
Better: fix the number of query/node combinations that we plan to look at. Stop sampling queries when we surpass that number. E.g. we might pick that number to be, say, 300. Then, if 30 nodes are backed off and 20 are available, we would sample 300/20=15 queries.
This has nothing to do with load balancing, but should improve routing, while increasing CPU usage by some unknown amount. Thoughts?
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
