Discuss mailing list

[Mike <mike AT pikeaero.com>]

Hi Niels,

Regarding latency as it is measured in this OpenNIC Wizard :
http://sourceforge.net/p/opennicwizard

The service bootstraps with a list of both ICANN and OpenNIC domain
names. In the current release those names are jumbled together, and in
the next release (0.3.rc2) they will be distinguished from one another,
as well as the ability to specify any arbitrary competing DNS services.

Okay so the service has a list of domain names to test with in any case
(the file is called 'bootstrap.domains" for those so inclined).

Upon bootstrap, the service will try to dig out as many T2s from it's
bootstrap list of T1s as it can. (The T1 bootstrap file is 'bootstrap.t1').

Each T2 (and T1's for that matter) is instantiated with it's own testing
context. That is to say that each one runs independent of the others. An
instance of a resolver will test itself at random intervals. When it
does so, it selects a random name from the pool (bootstrap.domains) and
initiates a name service query, taking note of the precise time that the
packet is transmitted. When a reply is received and it is flagged either
"OK" or "UNKNOWN" meaning it did in fact make a round trip and the
resolver has an answer, or it made the round trip but the resolver did
not have an answer, the latency is then calculated based on the time the
packet left to the time the reply was received. This is all in a class
called OpenNICDnsClient from which the class OpenNICResolverTest ir
derived, and from which OpenNICResolverPoolItem is finally derived, and
which are contained in collections of OpenNICResolverPool instances.

Each instance of a resolver (a OpenNICResolverPoolItem) maintains a
queue of historical events (in 0.3.rc1 it is only latency, in upcoming
0.2.rc2 it will be all data relating to each query) of a depth
configurable. Such that an average latency may be more firmly
established as time goes on.

So you will observe that shortly after bootstrap, the service will be
swapping out active resolvers fairly frequently as there is little data
initially to go on. So as more data is available the swapping of
resolvers becomes less frequent as the dominant ones become well
established.

So in 0.3.rc1 the "score" is heavily weighted by latency. In 0.3.rc2 I
will start to take into account recent up-time, and recent ability to
resolve opennic domains, as well as average latency. So that combination
of things will comprise what I am calling the "score".

In addition, I should probably add some sort of sanity tests once in a
while to evaluate the quality of the results to be sure that the
resolver's results are in agreement, taking change-propagation time into
account.

--Mike

On 03/01/2012 10:20 PM, Niels Dettenbach (Syndicat IT&Internet) wrote:
> 
> 
> Mike <mike AT pikeaero.com> schrieb:
> 
> 
>> So if you think you might have some input on the scoring system, or
>> anything relating to what I just talked about...I am coding it now, so
>> now is the time....
> 
> hi Mike, i did not read the sources yet and i'm not shure what do you mean 
> with "latencies" here, so just a short thing:
> 
> From my view "scoring" of a T2 (in relation to a IP available from) by 
> "latency" should mean DNS query "latencies" for different typical DNS 
> requests (with recursing etc.) without local caching etc. (i.e. by request 
> "random" domains or similiar - not just doing some ICMP or similiar on the 
> path between user and T2 as some discussed here in the past.
> 
> hth
> 
> thanx for your work.
> 
> 
> best regards,
> 
> Niels.
>