> On November 18, 2003 08:52 am, Martin Stone Davis wrote: > > We already back-off due to QR, so we already have a way of telling > > when every node is going to be ready. �The issue here is > adding that > > back-off time to the estimate() so that we can tell if the best > > strategy for a given query is to wait for the node to not be backed > > off or to go with an available node. > > Thinking about it, I can see a fairly simple change to out > acceptance logic that will might help. Let say we work like this. > > IF key is in the DS or Failure table \\ sames as now > respond with DNF or data > IF loadEstimate fails request \\ same as now > respond with QR > > \\ probalistic QR disabled for now > > generate the routing object > > if the probability of finding a route using the top X nodes > (where \\ we just look at pSF > backed off nodes have a pSF of 1.0) is less > than 0.xx \\ no messages are sent > respond with QR > > Reset the above object's getNextRoute to the top of the table > and proceed as we do now > > What this will do is allow us to accept requests that we > probably can route using a good > route. We want to recheck the backoff time when we actually > route, maybe the backoff > expired while we tried another node. > > Given that we have lots more queries that we can process and > we need to reject some, > this should let us reject those we would route using 'bad' > nodes or would RNF. > > Comments?
To me this is very similar to m0davis suggestion about the 'request bins'. The main difference is that your idea is to QR when the score is to low whilst m0davis idea is to prioritize the requests that we get high routing scores for over those which we get low scores for. I prefer m0davis method since it matches up better with NGR. NGR learns times needed.. Not the ugly QR binary on/off stuff. As I stated in another mail.. NGR indeed seems to be able to (as it is intendedc to) utilize time consumed for different tasks to do a better job while it is completely unable to cope with QR:s. /N _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
