Mac Forum / Programming / Mac Programming / June 2005

Oh yeah, I know that :)

It's just that there are some protocols that start with NSURL, so
I thought they might be relevant...

"NSSocketPort can be used as an endpoint for distributed object
connections or raw messaging."  says the documentation.

At least I thought the mighty Cocoa would have some builtin socket
functions, so I guessed it would be that one.

Yes, I actually have some socket() wrappers written in C.  If
there are no socket functions in Cocoa, I'll use them and wrap
them in an NSFileHandle.

Thanks.

Of course, that's why I chose it.  Nicely readable text protocol ;)

I'll probably have an extra task running (written in C, portable
Unix code), so I'll just talk to it over a socket or pipe.  My
main problem is how to integrate the stream into the Cocoa event
model (because select() would block and so I wouldn't respond to
Cocoa events anymore).  Well, I hope the file handle or Stream
approach works; shouldn't be impossible... :)

I'm not sure what you mean by "raw socket" here.

If you can require Panther or later, I strongly recommend you take
another look at NSInputStream and NSOutputStream for TCP
communications.  It's very easy to use once you understand the way it
fits together.

Here's the 30-second summary, written off the top of my head:

(1) Use +[NSStream getStreamsToHost:port:inputStream:outputStream:] to
get an NSInputStream and an NSOutputStream to the server you want to
communicate with.  Be sure to retain them, since they're returned to
you autoreleased.  (After all, they come from a method that isn't an
alloc, copy, or retain method.)

(2) Set your controller object to be your input stream and output
stream's delegate.  This means that it will get callbacks for events
that occur on each of the streams via its -stream:handleEvent: method.

(3) Schedule each stream in the current runloop in the default mode.  
This means that your streams' operations will be asynchronous, and that
you don't need to worry much about them blocking execution of your
application as long as you handle the delegate callbacks appropriately.

(4) For your input stream, handle the following events in your
controller's -stream:handleEvent: method:
NSStreamEventHasBytesAvailable (only read when you get one of these,
and only read the number of bytes actually available - you can ask the
stream for this info), NSStreamEventEndEncountered (e.g. the other side
closed the connection), NSStreamEventErrorOccurred.

(5) For your output stream, handle the following events in your
controller's -stream:handleEvent: method: NSStreamEventOpenCompleted
(don't try to write before you get this),
NSStreamEventHasSpaceAvailable (write when you get one of these, and
don't write again until you get another one),
NSStreamEventErrorOccurred.

(6) Open your streams.

(6) When you're done, close your streams and release them.

There may be more you need to do, or I may have gotten the steps
slightly wrong; after all, this is off the top of my head.  So check
the documentation here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/Streams/index.html>

Fundamentally,

streams provide you with a callback-based system that you can use to
read and write network data asynchronously.  It might be a little more
work than you're expecting if you were planning on working
synchronously (e.g. write something, read something, write something,
read something) since you'll have to implement a basic queuing system
and deal with incomplete reads and writes, but once you build some
basic infrastructure around it, it'll be very powerful.  And it
integrates with Cocoa's run loop mechanism and uses the delegate
pattern, meaning you don't have to do learn a separate event-handing or
registration system.

 -- Chris

<http://developer.apple.com/samplecode/Cocoa/idxNetworking-date.html>
has some good resources for you. Take a look at:

CocoaSOAP - Demonstrates implementing a SOAP client and server in Cocoa.
at the tcp/ip level, even includes the source  code for a small http
server.

<http://developer.apple.com/documentation/Cocoa/Networking-date.html>
is also useful.

As you may have noticed, NSStream doesn't have any APIs to wait for a
connection, only to make a connection to somebody else who's waiting.

However, CFStream allows you to create a stream pair for an arbitrary
native socket, and CFStream and NSStream are bridged. This means that the
main issue is doing the whole listen-and-connect dance, because CFStream
expects you to have already done that. You could do that in a separate
thread using the standard POSIX APIs, or you could use CFSocket to handle
that phase, which has nice runloop integration.

So in summary, CFSocket to listen, CFStream once connected, and then cast
to NSStream and do what you have been doing.