[ntp:hackers] Asynch resolver

Danny Mayer mayer at ntp.isc.org
Sat May 6 02:49:46 UTC 2006

David L. Mills wrote:
> Guys,
> Sachin is about to tear up the resolver. We have talked about that for
> literally several years without a volunteer actually doing it. The goal
> is to be able to resolve a DNS name on-fly and update the syntax tree
> constructed by the parser, possibly at run time. The approach is to fork
> a process when a name pops up and terminate it when no names are left in
> the tree. The problem of course is how to communicate between the forker
> and forkee. Right now this is done using a temporary file, and that
> sucks. Various kinds of I/O pipes, etc., are also possible but equally
> sucks.

Oddly enough I just updated ntp_intres today to fix a couple of problems
so I have already been horrified about the way it works. That's why the
question of the true flag came up.

We have been discussing this and we concluded that what we want to do is
to add ISC's EventLib code into NTP and then using that makes it very
simple to do dns resolution directly. That way no forks would be
involved, there'd be no temporary files, usage of the mode 7 packets and
other black magic and I don't believe that it uses pipes at all. If your
student wants to implement it, Paul Vixie and PHK would, I'm sure, be
more than happy to provide advice and guidance. More than anything else
we need someone who has the time to spare to implement it and then
recode the resolution code to use it.

> There is precedent in using shared memory for this; at least one of the
> drivers does that. My question is whether this is a universal paradigm.
> Does it work in Windows? Is there plausible commonality over Solaris,
> Linux and FreeBSD? Lightwave threads have been proposed. Same questions.
For Unices EventLib will do everything that is needed for all
supportable platforms.

For Windows, once there is a function that can be used to do the
resolution, I would just create another thread (actually it already runs
ntp_intres in a separate thread rather than as a separate process) and
it would populate the appropriate memory structures and notify the main
code that there is data to be picked up. It's pretty straightforward.
The hard part would be making sure that the locking mechanism is worked out.


> Dave
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers

More information about the hackers mailing list