Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

sockaddr structs vs. address strings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

sockaddr structs vs. address strings

Subject: sockaddr structs vs. address strings
From: Dustin Voss <email@hidden>
Date: Sun, 25 Sep 2005 01:45:07 -0700

I am the author of AsyncSocket, a networking class. The class currently has an -acceptOnPort: method, which sets up an AsyncSocket instance to accept a socket connection on any address. But in my next version, I plan on adding -acceptOnAddress:port:, which will let the developer pick an address to listen on. I am doing this because a user might have a public network and a private network, and might want certain services open only on the private network.

In a situation like this, the developer will have offered the user some way of selecting a particular address or connection, and should have used the System Configuration Framework or an equivalent to know if the connection goes down or up. I have not built an app that does this stuff myself, so I don't know how he might have done these things. But y'all have, so maybe y'all can answer my question.

My new -acceptOnAddress:port: method will take an address, but that could be an NSString or a CFData-wrapped sockaddr. Which one should I use? Which would be easiest for the developer to work with?

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.

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. On the one hand, it seems to me that the wisest choices would be one of the first two, because they offer the friendlier interface to users, and allow for proper monitoring of connection status. On the other hand, the developer might have gone for CFHost or NSHost, because they are more accessible.

If the developer went for NSHost, I know that -acceptOnAddress:port: should take a NSString address, because that is all NSHost can provide. If he went for CFHost, he could have gotten a string or a sockaddr. But if he went for System Configuration or Open Transport, I don't know which he'd have gotten.

On my side of the fence, I only know two ways of turning an NSString into a sockaddr. One is inet_ntop and the other is CFHostCreateWithName followed by CFHostGetAddressing. If I use inet_ntop, I'll need to have the developer tell me whether the address is IPv4 or IPv6, and how will he know? But if I use CFHost, I do not know a way to avoid a DNS lookup if the developer should happen to pass a DNS name to the method.

So, what should I do? Should the method take an NSString, and if so, how shall I turn it into a sockaddr? Or should the method take a sockaddr, so that I put the burden on the developer? _______________________________________________ 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 Follow-Ups: Re: sockaddr structs vs. address strings From: Heath Raftery <email@hidden> Prev by Date: Re: Newbie: where to start Next by Date: choosing a network port Previous by thread: Re: Newbie: where to start Next by thread: Re: sockaddr structs vs. address strings Index(es): Date Thread