On Jan 16, 2008, at 10:53 AM, Matthew Toseland wrote:
> On Friday 11 January 2008 18:24, Matthew Toseland wrote:
>> On Wednesday 09 January 2008 19:59, Robert Hailey wrote:
>>>
>>> On Jan 8, 2008, at 2:39 PM, Matthew Toseland wrote:
>>>
>>>>> In either case, resuming a request after we know that the upstream
>>>>> peer has forgotten about it could be very bad. Assuming 20 peers
>>>>> (ala
>>>>> opennet), the theoretical worst-case-per-node is that the last new
>>>>> request will leave the node about 40 minutes from when it
>>>>> entered the
>>>>> node.
>>>>
>>>> Not possible because of HTL. We will DNF (or timeout) before we've
>>>> visited all
>>>> 20 nodes. We don't allow RNFs to increase the HTL or change the
>>>> nearest-loc-found, but we do allow them to decrease the HTL. And we
>>>> decrement
>>>> the HTL unless nearestLoc improves (the HTL decrement/reset code
>>>> really needs
>>>> to be looked at, it's far from clear and may be wrong in places).
>>>> One caveat:
>>>> at HTL=10 or HTL=1, whether or not the node decrements is
>>>> determined
>>>> probabilistically (the decision is made once per source node).
>>>
>>> It looks like the htl is decremented with respect to the source of
>>> the
>>> node (not the node we are routing to), so at 10 or 1 if the request
>>> came from a node w/o the probabalitic decrement (or if prob.
>>> decrement
>>> is disabled!) then the standard request search will try all it's
>>> peers.
>>
>> Ah. Yes, you are right. On the other hand, each of the nodes we
>> route to and
>> get an RNF from should itself reduce the HTL, in almost all cases,
>> so I'm not
>> sure that this fully explains it.
>
> This hasn't been fixed yet. Comments on the proposed fix?
I thought it would be simply changing 'source' to 'next' in the
handlers, but your comment about RNFs and the code surrounding RNFs
has confused me more so I moved on to something else. :{
--
Robert Hailey
