Re: sockaddr structs vs. address strings
Re: sockaddr structs vs. address strings
- Subject: Re: sockaddr structs vs. address strings
- From: Quinn <email@hidden>
- Date: Tue, 27 Sep 2005 10:35:34 +0100
At 9:52 +1000 27/9/05, Heath Raftery wrote:
My vote goes to the NSString.
I'd probably vote for this as well. It's not the best approach in
the specific case you mention (-acceptOnAddress:port:), but it's the
best solution in general.
At 1:45 -0700 25/9/05, Dustin Voss wrote:
To my knowledge, there are four high-level APIs the developer might
have used to get a particular address: System Configuration, Open
Transport, CFHost, and NSHost.
Why not provide your own API to get the list of local addresses?
That way you can return the address in a format that's compatible
with your -acceptOnAddress:port: input.
At 1:45 -0700 25/9/05, Dustin Voss wrote:
Whichever I choose, I want to support both IPv4 and IPv6 addresses.
I don't care about DNS names. But I will need to be able to verify
that the developer did not pass a DNS name or an address of another
computer to the method. And I need to end up with a sockaddr struct.
You can just let bind do this for you. If you try to bind to an
address that's not local, you'll get an error (AFAICT EADDRNOTAVAIL).
At 9:52 +1000 27/9/05, Heath Raftery wrote:
I haven't had to deal with the extra difficulties you'll face, and
you've probably already got this far, but here's what I use to go
from NSString to sockaddr:
struct sockaddr_in socketAddress;
socketAddress.sin_family = AF_INET;
socketAddress.sin_port = htons(fRemoteHostPort);
inet_aton([fRemoteHostIPAddress cString], &(socketAddress.sin_addr));
memset(&(socketAddress.sin_zero), '\0', 8); // zero the rest
of the struct
If you want to work at the BSD level, I think that getaddrinfo
<x-man-page://3/getaddrinfo> is the best choice. It supports both v4
and v6. By passing AI_NUMERICHOST, you can get it to just support
the textual representation of numerical IP addresses, and never hit
the wire.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden