[ntp:hackers] nonblocking DNS code nearly complete
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 127.0.0.1
>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
>MD5 hash: 13ab2f7b760f287928a72486b63388a2
More information about the hackers