[ntp:hackers] Asynch resolver

David L. Mills mills at udel.edu
Sat May 6 19:03:33 UTC 2006


Danny,

For my student this is an academic exercise. The first goal is to 
demonstrate dynamic server discovery methodology, second to use widely 
accessable tools, third to preserve portability. In that order, emphasis 
added. If the ISC library is well documented and has a moderate learning 
curve, that will be considered. So will competing methods. In short, as 
I have advised Sachim, the first goal above is the most important and 
the quickest way to achieve that is the best.

Dave

Danny Mayer wrote:

> 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.
>
> Danny
>
>> Dave
>> _______________________________________________
>> hackers mailing list
>> hackers at support.ntp.org
>> https://support.ntp.org/mailman/listinfo/hackers
>>



More information about the hackers mailing list