On Feb 8, 2008, at 11:25 AM, Matthew Toseland wrote:
> On Friday 08 February 2008 16:43, Robert Hailey wrote:
>>>
>>> Now, this is dangerous. If to get to node A you have to go through
>>> node B, and
>>> you go through node B with a short path, then you won't be able to
>>> go through
>>> node B with a longer path later on because the UID will be rejected.
>>
>> No... because the uid will change for "later" ping attempts; unless
>> you are speaking to the same point as above, or I misunderstand your
>> poing (or general small world topologies).
>
> Ah, so you start with a high dawn htl and progressively reduce it?
We could do that, it is up to the requestor. Right now it is coded up
to start at 2 and increasing it only after many failures.
>> [...]
>>
>>>> +if (htl<=0) {
>>>> + //would be dnf if we were looking for data.
>>>> + source.sendAsync(DMT.createFNPRejectedLoop(uid), null, 0, null);
>>>> + break;
>>>> +}
>>>
>>> This is gonna visit an awful lot of nodes then ...
>>
>> Yes... but since it is never reset, the maximum theoretical is
>> (HTL^2)/
>> 2; ignoring probabilistic decrement.
>
> Eh? It will visit a lot of nodes because on each node it will visit
> each peer,
> no?
At each node it will visit at most 'htl' peers (where htl is from the
request). Do you think that 50 nodes is too many? Make the cap on
SecretPing-htl's lower than the search's 10?
In practice the maximum number of nodes searched would be *much* less
than 50, because so many links are short links, the peer will reject
it because it is/has already seen the request.
--
Robert Hailey
>
>> If there are any slow local
>> nodes, there is a much lower practical cap with the fatal timeout. I
>> was thinking that we will use a smaller htl than 10, although... if
>> this request is lightweight enough, even visiting 50/100 nodes would
>> not be terrible.
