Is asychronous DNS lookup worth keeping at all?

[Mark Atwood]

Ok, I think our voices of wisdom are right.  Don't rip it out just yet, let
Chris weigh in, and then when the time is right, replace it.

On Tue, Dec 1, 2015 at 12:59 PM Joel Sherrill <joel at rtems.org> wrote:

> I agree with Hal for his reasons and another.
>
> If this is the worker threads, then we should wait for Chris to comment.
> He has a simpler replacement in the queue and just needs to debug
> it AFAIK.
>
> Plus this could be a feature plus over Classic.
>
> On Tue, Dec 1, 2015 at 2:45 PM, Hal Murray <hmurray at megapathdsl.net>
> wrote:
>
>>
>> esr at snark.thyrsus.com said:
>> > Is asychronous DNS lookup worth keeping at all?  It's costly in code
>> > complexity and dependencies.  I've been thinking about how it affects
>> > performance and I'm now doubting that it is effective  in modern
>> conditions.
>>
>> I think that is premature.
>>
>> I can't put my finger on a good example, but the use-case space is huge.
>> I
>> think there is too high a chance that we haven't considered an important
>> case
>> yet.
>>
>> There is a lot of interest in getting servers restarted quickly.  Telling
>> all
>> those users they can't use any non-local server names seems unwise.
>>
>> I'd like to be able to do things like have the pool code occasionally
>> verify
>> that the servers it is using are still in the pool.  The idea is to help
>> people remove their servers from the pool.  (The pool DNS side doesn't
>> support that check yet.)
>>
>> I think the code complexity will improve a lot when Joel rewrites that
>> area.
>> The wart that may not be obvious is the interaction with locking
>> everything
>> into memory.  In some environments, the end-of-thread code loads another
>> library module which may not fit.
>>
>> How evil are the dependencies?  How many environments don't have pthreads?
>>
>> I'd be happy to do the DNS lookups from the main thread if the environment
>> doesn't support pthreads.  Or at least do it that way until we discover an
>> interesting use case.
>>
>>
>> > Nowadays, 99.9% of all NTP installations are configured to do a single
>> pool
>> > name lookup.  ...
>>
>> That's incorrect on two counts.
>>
>> Most installations should be using the pool mechanism, but the distros
>> aren't
>> shipping that yet.  They are shipping an old version of ntp classic (with
>> locally applied security fixes) where the pool code didn't quite work.
>> They
>> use the pool via server directives in ntp.conf.  You see things like:
>>   server 0.fedora.pool.ntp.org iburst
>>   server 1.fedora.pool.ntp.org iburst
>>   server 2.fedora.pool.ntp.org iburst
>>   server 3.fedora.pool.ntp.org iburst
>>
>> The pool code is likely to do more than one DNS lookup.  It may take more
>> than one DNS lookup (with a TTL timeout in between) to get enough servers.
>> After startup, if a server stops responding, the pool code drops it and
>> uses
>> DNS to find a replacement.
>>
>>
>> --
>> These are my opinions.  I hate spam.
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at ntpsec.org
>> http://lists.ntpsec.org/mailman/listinfo/devel
>>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20151201/74a9c8cd/attachment.html>