Re: UDPEcho example and socket creation - A.S. lib
Re: UDPEcho example and socket creation - A.S. lib
- Subject: Re: UDPEcho example and socket creation - A.S. lib
- From: Rick Mann <email@hidden>
- Date: Fri, 22 Oct 2010 15:13:50 -0700
On Oct 22, 2010, at 10:24:32, James Walker wrote:
> On 10/22/2010 10:11 AM, JP May wrote:
>> Rick, just a quick note,
>> we use and adore the totally awesome library
>> http://homepage.mac.com/d_j_v/FileSharing4.html
>> it may possibly have useful example code within it.
>>
>> (AsyncSocket was written by the mysterious and brilliant Dustin J. Voss, who is unreachable!)
>
> There is a more actively developed version of AsyncSocket here:
>
> <http://code.google.com/p/cocoaasyncsocket/>
I had found that after spending some time doing my own integration.
On Oct 22, 2010, at 02:47:54, Quinn The Eskimo! wrote:
> Both approaches are valid. I prefer to use BSD directly because:
>
> o I find the BSD calls easier to understand -- In my experience the documentation for calls like CFSocketSetAddress is rather poor.
Yes, it really is, especially for UDP. But, that alone isn't necessarily a reason to use BSD.
> o it gives you more direct control -- For example, CFSocketSetAddress is equivalent to bind() + listen(), which is a problem if you want to bind on /outgoing/ TCP socket (to force it to run over a particular interface) or you want to bind a UDP socket (where calling listen() makes no sense).
That sounds like a limitation of CFSocket (more below).
> o they give you better access to errors
Also seems like a limitation of CFSocket (more below).
> The value of CFSocket, IMO, is the run loop integration. Everything else is just noise.
Also seems like a limitation of CFSocket (more below).
> Despite all of the above, if the CFSocket calls work for you, there's nothing wrong with using them.
The thing I don't like about CFSocket is that I really do have to drop down to BSD to finish the work. Mostly in dealing with sockaddr and its variants. I find it to be an old style of C coding that rubs me the wrong way, and is fairly tedious (just look at UDPEcho's handling of IPv4 vs IPv6).
It seems that CFSocket could stand to be improved a little (I don't think it would take a lot of work), particularly around UDP (like the bind-vs-listen stuff you mention above), and error reporting (so that I don't have to look at errno).
It also needs additional classes to help with addressing. It's really unwieldy to get CFData objects back, unpack them into sockaddr structures, work with those cryptic structures, then re-pack into CFData to pass back to CFSocket.
AsyncUDPSocket will probably do everything I want, but I was working through the exercise of writing my own to learn CFSocket better. It would be nice if Apple provided an NSUDPConnection (or pick a better name) object to help us out.
Anyway, thanks for all the info!
--
Rick
_______________________________________________
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