Re: Implementing a TCP port listener in Cocoa
Re: Implementing a TCP port listener in Cocoa
- Subject: Re: Implementing a TCP port listener in Cocoa
- From: Jakob Olesen <email@hidden>
- Date: Thu, 29 Jun 2006 11:40:32 +0200
On 29/06/2006, at 5.34, Rick Hoge wrote:
Now my problem is to get file descriptors corresponding to the
input and output streams - the libraries I want to re-use for
parsing the streams are written assuming they'll be used in an app
launched by inetd with the input and output streams mapped to stdin
and stdout. CocoaHTTPServer sets up NSInputStream and
NSOutputStream objects - I need to figure out how to adapt usage of
functions that read from stdin and stdout to work with these
streams...
Rick,
When writing a TCP server you can choose from several architectures:
1. Handle connections in sequence (no concurrency)
2. Spawn a new process for each connection
3. Spawn a new thread for each connection
4. Use non-blocking IO
These are in order of increasing performance and increasing
difficulty :-) Inetd uses the second approach.
The Cocoa classes really shine for the non-blocking approach because
they integrate with the runloop and send you notifications/callbacks.
Usually you would have a big select() call somewhere to handle
multiple sockets, but Apple has already done that for you. For cases
1-3 the Cocoa classes don't buy you a lot - they are just Objective C
wrappers for file descriptors. You probably get less buffer
overflows, though.
I don't know how well your library is written, but a typical inetd
program will
1. Use lots of global variables.
2. Not clean up after itself.
This works well because the OS cleans up everything when the process
is terminated, and you get a new spanking clean process for each
connection. If your library is written in this style, you should look
into spawning a process for your connections. Otherwise you have a
lot of code cleaning to do.
If your library does use global variables but cleans up properly
after each connection, you can use 1. in a separate thread, but you
cannot handle simultaneous connections.
If your library doesn't use global variables and cleans up after
itself, you can use 3.
If you want to use non-blocking IO you are in for a rewrite, the
programming model is completely different. When using blocking IO,
your program flow follows the network protocol. A non-blocking IO
program is event-driven, just like a Cocoa program.
The CocoaHTTPServer uses non-blocking IO, and as you can see, such
code can get quite complicated.
Basically, you have more important decisions to make before you
decide between NSFileHandle and NSStream.
If I was in your situation, I would probably keep the inetd daemon,
and simply have it send a distributed notification to my app whenever
it has received an image.
Alternatively, set up the listening socket in your app, and use
NSTask to run your inetd daemon. NSTask lets you hook up stdin and
stdout before launching. It ought to work with a socket, I haven't
tried it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden