I still don't have my head around this fully yet, but I think the core flaw in your proposal is that it assumes that, for a given key, the pSuccess values of repeated requests to the same node are independent, but they are not. After the first failure, pSuccess for that node drops to 0.Hand-wavy explanation: When trying to ask "how long will it take this one node to give us a 1 unit of data?" we don't have to be concerned about how our opinions about pSuccess will change in the future. All that matters is the true value itself. Since we don't know the true value, the best we can do is use our current opinion of the true value.
Admission of guilt: As I wrote it, pSuccess is a bit ambiguous: is it the current (and changing) estimate of how likely future successes will be? or is it the "true" (and static) chance of success? If the former, then we'd write it with a little hat on top. If the latter, we'd probably use a greek symbol for it. Since I didn't do a very mathematically sound derivation, it would be problematic to discuss your concern here in detail.
Changing the subject: Let's hold off on that until I address the more troubling problem you raise below and I also come up with a more clear derivation.
Whatever the algorithm, it MUST consider the cost of re-requesting the key elsewhere in one way or another - since a lower global average re-request time is likely to make a sensible algorithm more willing to try an unreliable but fast node, but so far as I can understand - your algorithm does not consider this.
I see your point. The choice is not between the tortoise and the hare. There are many tortoises and many hares! Suppose there are only 2 nodes to choose from. Then, we have at least two choices: try node 1 first, and failing that, try node 2 OR try node 2 first, and failing that, try node 1. With 3 nodes there are at least 6 choices. With n nodes, there are at least n! choices. I say "at least" because there are even more strategies to choose from: e.g. try node 1, and failing that, try node 1 again, and failing that, try node 2.
So the trick is coming up with a strategy that minimizes the total expected time to achieve a successful result. I'll try to work that out on paper and get back to you when I have something.
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
