Re: Name resolution limits
Re: Name resolution limits
- Subject: Re: Name resolution limits
- From: Becky Willrich <email@hidden>
- Date: Fri, 8 Feb 2002 10:25:01 -0800
I'm always surprised by the answers on this topic (and every time I'm
checking my code for the safety of my mind).
Name resolution with up to 10 Threads (pool of potential and reusable
Threads) using the Cocoa APIs is working fine.
No performance issue.
I don't want to be the bearer or bad news, but this is not true. The
Cocoa APIs go through gethostbyname, same as everyone else; this is the
API bottleneck for host resolution. It is possible that the Cocoa APIs
are sufficiently aggressive with caching that they can appear timely in
all but the most perverse cases; I don't know. It is also possible the
Cocoa APIs take care of the thread-safety issues by locking, but that
won't change the fact that host lookups are serialized, so the total
time is still going to be O(n), where n is the number of requests.
If you want to talk to lookupd to do your host resolution, and want to
do it in anything resembling a maintainable fashion, you must ultimately
call gethostbyname. gethostbyname on all public releases of MacOS X and
Darwin is not threadsafe, not re-entrant, and blocks for up to 75
seconds if a server is unresponsive.
Here are the workarounds I know of:
- Use OmniNetworking from Omnigroup. This is an open-source library
with a fairly generous licensing agreement (I believe; I'm not a
lawyer...). This fixes the thread-safety and blocking issues by running
its own server process and sending all requests there; the server takes
care of serializing the incoming requests. It will not speed up the
total time to get responses to all requests, though - it's calling
gethostbyname, same as everyone else. It is also a Cocoa framework, so
there will be some shim problems if you wish to use it without linking
in the Objective-C runtime and Foundation.framework.
- Get the Darwin sources, locate the code that does the mach messaging
to lookupd, and re-implement them in a thread-safe fashion, enabling
multiple simultaneous lookups. This is the utterly unmaintainable
approach I hinted to above; lookupd's messaging semantics are not
considered public API and may change with every release (and are less
stable than many other non-public pieces of the system). While I've
often heard this proposed as a theoretical solution, I don't know of
anyone who has successfully implemented it. If you try this, be
prepared to have to patch with every release of MacOS X.
- Choose not to use lookupd, and instead link in a good DNS library (one
which provides for multiple simultaneous lookups and thread-safety).
Consult the DNS library directly instead of using gethostbyname. This
has the penalty of failing to resolve those addresses that lookupd can
find from sources other than DNS (personally, I think this is a pretty
high penalty); it also defeats the caching performed by lookupd.
Essentially, you are taking responsibility for host resolution
yourself. One possible refinement is to call gethostbyname only if the
straight-up DNS lookup fails; now you are only losing information in the
rare case that DNS returns a wrong answer, but lookupd would have gotten
the right one. And you are paying the performance cost of defeating
lookupd's cache (which is probably more efficient than what you can do
from user space), and the cost of a double-lookup in the DNS failure
case.
Regardless of the approach you take, do make sure to lock around calls
to gethostbyname (and library calls that themselves call gethostbyname,
like the aforementioned Cocoa ones) if you are multi-threaded. I also
recommend very aggressive caching policies. Finally, if you find
yourself rolling your own resolution code, do remember that IPv6 is
coming; IPv4 assumptions can be easily avoided if you do it up-front,
but can be demonic to remove later.
I can also tell you that Apple is aware of this problem and is working
on it, though I cannot, of course, comment beyond that (so don't ask).
As an implementor of a networking library on X, I'm no happier than you
are.
REW
_______________________________________________
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.