Martin Stone Davis <[EMAIL PROTECTED]> writes:
>Ian Clarke wrote:
>> 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.

I think the basic problem is as follows.  In Martin's model, you
repeatedly query the same node again and again.  Sometimes it decides
to give you data (with probability pSuccess), sometimes it decides not
to (with probability pFailure).  The rate at which you can issue
queries depends on how long the node takes to get back to you
(tSuccess or tFailure, respectively).  Martin then picks the node that
gives the greatest throughput.

There are two difficulties here.  First, we are only interested in
getting the data once, not lots of times.  So we really want to
minimize the time to the first success, not maximize the number of
successes over time.

Second, once the node returns failure, that means it can't find the
data.  There's no point in asking again, because it will again say no.
Or will it?  Maybe we *should* admit the possibility of asking the
same node twice - downstream network conditions might change.  After
all, that's exactly what you do on your own node when requesting data.
If you don't find it, you try again.

theo


-- 
Theodore Hong         Dept. of Computing, Imperial College London
[EMAIL PROTECTED]   180 Queen's Gate, London SW7 2BZ
PGP key: http://www.doc.ic.ac.uk/~twh1/

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

Reply via email to