On 8 Sep 2009, at 22:44, Brent Gulanowski wrote:
While I don't speak for Apple, we ran into this with Daylite Server,
and found out that you shouldn't be using those calls.
Basically, your computer is NOT the authority on your computer's
host name. The DNS system is the authority. So these calls tend to
trigger DNS lookups, at which point you're at the mercy of DNS,
especially badly configured DNS, or DNS servers that are down, or
what-have-you.
That's true. Perhaps the problem here lies in the interaction between
DNS and mDNS. I really just want my local mDNS name, nothing more.
Beyond that, I haven't worked out all the intricacies. But I believe
that gethostname() gets a cached host name that gets set at system
startup, and is in no way authoritative (it is I think the C API
which underlies the "hostname" command, and has a complementary
sethostname command). That old way of doing stuff is pretty much
obsolete.
That is my take on it too.
Mac OS X always tries to discover its name from DNS first, and falls
back to the mDNS if there is no good response from DNS. Or that
seems to be what's going on. The Apple engineers at WWDC were
appalled by the very idea of NSHost -currentHost and anything
related to it, and basically said that if you're using them, you've
got problems in your design.
I sent in a documentation request that some sort of caveat/danger sign
be attached to [NSHost currentHost].
Not making any judgements, just relating my (now somewhat fuzzy)
experience.
On Tue, Sep 8, 2009 at 4:15 PM, jonat...@mugginsoft.com <jonat...@mugginsoft.com
> wrote:
I am not sure if this is a problem unique to me or not but under
10.5 [[NSHost currentHost] name] or [[[NSProcessInfo] processInfo]
hostname] were quick and easy ways to get an mDNS friendly hostname
such as imac-2.local
On 10.6 I find that both these combinations block badly
(NSProcessInfo merely defers to NSHost I think).
The list has a few references to the possibility of these blocking
but I never encountered it until now.
According to a stack sample getnameinfo() seems to be the library
call that is blocking.
_mdns_query_mDNSResponder seems to be the actual blocking call.
Anyone else seeing this behaviour?
There seem to be two alternatives:
NSString *name = NSMakeCollectable(SCDynamicStoreCopyLocalHostName
(NULL));
This gives the correct mDNS friendly hostname but omits the local
pseudo domain.
Otherwise this seems suitable:
char hostname[_POSIX_HOST_NAME_MAX + 1];
gethostname(hostname, _POSIX_HOST_NAME_MAX);
name = [NSString stringWithCString:hostname
encoding:NSUTF8StringEncoding];
Jonathan Mitchell
Developer
http://www.mugginsoft.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/bgulanowski%40gmail.com
This email sent to bgulanow...@gmail.com
--
Brent Gulanowski
Jonathan Mitchell
Developer
http://www.mugginsoft.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
