Ian Clarke wrote:

Martin Stone Davis wrote:

Okay, here's my problem with that: It's correct only if we are sure that we would actually get a successful result from some other node. But what if no other nodes return data, and we only get DNFs?


Well, this is where the concept of a "legitimate DNF" comes in. Let me refer you to the section on DNFs in:
http://freenetproject.org/index.php?page=ngrouting

Well, gee, why didn't I just that at the start? I see that when I've been talking about estimating time to get a success OR get a legit-DNF, I've *really* been talking about run-of-the-mill DNFs. However, DNFs aren't what we're after. As you said, we ultimately want the time to achieve a success. I finally understand that.


In addition, in the case of a truly "legit-DNF", it would mean (by definition) that the key doesn't exist on the network anyway, in which case it really doesn't matter what estimate() gives us. That's yet another reason for only trying to estimate the time it will take to actually reach a success.



Considering this possiblity, I would guess this formula would be better:
o>>
estimate=pSuccess+tSuccess
         +pFailure*(tFailure
                    +pGlobalSuccess*tGlobalSuccess
                    +pGlobalFailure*tGlobalFailure)


What exactly would that be an estimate *of*?
good question... But now moot.


Recall that in NGR we always estimate "how long will it take to get the data if the message is (initially) routed to this node". It is important that we know what the estimate *means*. I don't think that is the case with the equasion you give above.


To illustrate how we might be going wrong in the current scheme, consider a key which figures to take a short time to retrieve when actually found, but is also hard to find. Then, our current globalEstimator would be low (optimistic) and lead us to towards trying more hares (fast but unlikely to succeed) than tortoises (slow but likely to succeed).


If that key takes a long time to find then the globalEstimator for it will not be low, since the global estimator takes *both* the search time and the transfer time into account.

You are correct. In my example, "a key which figures to take a short time to retrieve when actually found, but is also hard to find" implies that both pSuccess and tSuccess are low for many nodes. That, in turn, makes globalEstimator high since search time will be high.



I still don't see why our current approach doesn't achieve exactly the effect we want it to.

I agree. Sorry for the confusion.


-Martin


_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to