[ntp:hackers] nonblocking DNS code nearly complete

David Mills mills at udel.edu
Mon Jan 11 04:18:31 UTC 2010


The reason for the funky file is to save the configuration parameters 
until the DNS reply, then mobilize the association with this 
information. You code fragment implies the association is mobilized 
before the DNS query, so the only thing the callback routine has to do 
is plug in the DNS address. Can you confirm this? The original reason 
for this was to allow ntpdc to mobilize an association, but only with a 
limited set of options. Now, this can be done using ntpq with all the 
configuration options, but only those options supported by ntpdc are 

If so, I have no problem with this if some means are available to blind 
the system process during the lookup interval and to demobilized the 
association if no response is received after timeout. The kiss code 
could be lit LOOK during the interval. In addition, this would allow a 
full spectrum of additional options to be specified on the server/etc. line.


Dave Hart wrote:

>On Mon, Jun 1, 2009 Dave Hart wrote:
>>Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â getaddrinfo_sometime(curr_peer->addr->address, "ntp",
>>Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  &hints, 2, peer_name_resolved,
>>Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  (void *)curr_peer);
>>       int                     retcode,
>>       int                     gai_errno,
>>Â  Â  Â  Â void * Â  Â  Â  Â  Â  Â  Â  Â  Â context,
>>Â  Â  Â  Â const char * Â  Â  Â  Â  Â  Â name,
>>Â  Â  Â  Â const char * Â  Â  Â  Â  Â  Â service,
>>Â  Â  Â  Â const struct addrinfo * ai_in,
>>Â  Â  Â  Â const struct addrinfo * res
>>Â  Â  Â  Â )
>About 6 months ago I sidelined a prototype of a replacement for
>ntp_intres with its funky temporary file and mode 7 to
>interface, deeming it too disruptive for the looming 4.2.6 release.
>With 4.2.6 out and a bunch of the initial hiccups smoothed over, I
>spent some time merging the intervening changes.  I also added a
>previously-missing piece, forking off the child worker on demand and
>idling it out when there are no more DNS queries remaining.
>Aside from some cleanup and shuffling of code between files, the only
>other item I'd like to see is optional support for using pthreads and
>directly sharing pointers instead of fork() and serializing over a
>pipe on POSIXy systems.  That seems like an item that can wait, and it
>might be best to wait to flush out bugs in the fork-based code first.
>It would be most useful on systems that support pthreads but not
>fork(), including some embedded Linux solutions.
>As the quoted code above shows, the interface presented to DNS
>consumer code in ntpd is based on getaddrinfo() with a callback
>routine invoked later via the I/O loop when the query results are
>ready.  Unlike some options for achieving asynchronous DNS, this code
>simply uses the standard getaddrinfo() interface provided by the
>system, rather than attempt to replace it with UDP/TCP 53 queries.
>I believe the code works better than the current intres now, in that
>all DNS queries are performed without blocking the daemon, including
>the first queries which block the daemon in the current code.  I would
>appreciate testing and feedback.
>The code is in ~hart/ntp-dev-block on pogo and psp-deb1, and also in
>~hart/ntp-4.2.7p2-new-intres.tar.gz on both.  It can also be
>downloaded from:
>MD5 hash: 13ab2f7b760f287928a72486b63388a2
>Dave Hart

More information about the hackers mailing list