Re: Name resolution limits
Re: Name resolution limits
- Subject: Re: Name resolution limits
- From: Jason Linhart <email@hidden>
- Date: Thu, 7 Feb 2002 22:50:27 -0500
On 2/7/02 8:08 PM jud spencer (email@hidden) wrote:
>
There was some discussion here a while back about the limits to the number
>
of name lookups that can take place at one time using OT.
>
>
Can I hear what the exact limits are? Is it one lookup at a time? What are
>
the limits running under OS9 using Carbon? Is it the same as an OS9
>
InterfaceLib version?
>
>
The OSX version of LetterRip is getting some horrible performance in the MX
>
lookup area. We currently don't cache MX lookup info, should I consider
>
doing that now or is the current limitation short-term?
I've done a fair bit of looking into this.
There are no thread safe interfaces to the lookup routines in OSX.
Because of this, the Carbon OT routines will block other threads from
doing lookups till the current one completes. When a DNS server is not
responding this can mean blocking for up to two minutes. Even when run
sequentially, the Carbon OT glue code imposes some large, and difficult
to explain, delays in the lookup process. This makes all possible OT
based approaches to multiple lookups hopelessly slow.
No one at Apple has been willing to speculate on when thread safe
resolver routines might appear. I have gotten indications that this is
not going to happen at all unless significant developer pressure is felt,
in the form of bug reports getting filed. However, because of the layer
of secrecy around everything at Apple, it is impossible to know anything
for sure.
If you are willing to have multiple processes, each one can be doing one
lookup at a time. Supporting multiple processes, and communicating
between them, cleanly is possible but can present some development time
consuming challenges, depending on what kind of application you are
writing and which APIs you are using. Once you go the multiple process
route, the total lookup speed can be very very fast, even though any
given lookup can still take a very long time. This can of course mean
having dozens, or even hundreds, of processes. That can present it's own
problems.
Under no circumstances can you abort a lookup in progress. Attempting to
do so will crash the process a small percentage of the time, and won't
actually abort the lookup the rest of the time. The resolver routines
were not completely stable in earlier versions of OSX, but appear to work
well in 10.1 and newer.
All of this can be avoided by directly linking in lookup routines from
other sources, and avoiding the ones Apple supplies. ARes,
<
ftp://athena-dist.mit.edu/pub/ATHENA/ares/>, is particularly nice, but
there are several other choices.
On 2/7/02 8:53 PM Josh Graessley (email@hidden) wrote:
>
While you can write resolver routines yourself, I would advise against it.
>
There are many things Mac OS Xs resolver will do that your resolver would
>
not. Mac OS Xs resolver APIs just make mach message calls to lookupd.
>
Lookupd is a complicated and elaborate beast. It does more than just DNS
>
lookups, it will use other directory services available on the system such
>
as netinfo and, I believe, LDAP. I'm not sure of the specifics. At any rate,
>
lookupd does a lot your resolver probably wouldn't. In the future, it may do
>
more. For the sake of consistent results, it is probably best to use the
>
APIs.
Several people at Apple have repeatedly said that avoiding the built-in
routines is not a good idea, but that is actually highly dependent on
your reason for doing lookups. Nothing Apple does will change the fabric
of the existing DNS standards overnight. The only credible worry is that
it will be impossible to lookup the names of machines on the local
network once Apple supports ad-hoc network construction and your user is
actually making use of it. In many situations that is an acceptable
tradeoff, and by that time there will probably be updates to ARes with
equivalent capabilities.
I am greatly saddened that Apple's response to our attempts to work
around their failure to provide thread safe resolver routines is to tell
us that we should not attempt to develop work arounds at all and instead
should live with their fatally flawed versions.
The solution is quite obvious, Apple should provide thread safe
interfaces to the resolver routines and OT should be updated to make use
of them. Every other modern operating system has provided this service
for years. If they are incapable of providing this basic functionality
they should at least have the respect to stop bad mouthing our efforts to
meet our customers needs by using libraries like ARes.
Jason
-----------------
email@hidden
-----------------
Dr. Seuss books . . . can be read and enjoyed on several levels. For
example, 'One Fish Two Fish, Red Fish Blue Fish' can be deconstructed
as a searing indictment of the narrow-minded binary counting system.
-- Peter van der Linden, Expert C Programming, Deep C Secrets
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.