Re: NSStream, NSInputStream, NSOutputStream

FROM : Ken Thomases
DATE : Sun May 18 20:26:02 2008

On May 18, 2008, at 10:50 AM, John MacMullin wrote:

> I modified slightly the Echo Server code sample from Apple with the 
> following results.


To which sample are you referring?  I assume you mean the sample 
called CocoaEcho at <http://developer.apple.com/samplecode/CocoaEcho/>.

>  One, I couldn't stream a large file from a polling routine.  More 
> than likely it would cancel because of a Sigterm 15.


SIGTERM, really?  I can't think of why or how a SIGTERM would be 
raised by the system or the frameworks.  I can see SIGPIPE, SIGTRAP, 
or SIGABRT.  And, of course, programming error can result in SIGBUS or 
SIGSEGV.

Hmm.  Perhaps launchd might terminate a service with SIGTERM if it 
determined that the service was misbehaving somehow.


> It appears from reading the docs that the user cannot detect the end 
> of a stream and that the NSStreamEventEndEncountered only detects a 
> close.


What is it that you would call the end of a stream other than it being 
closed?

> Two, when unarchiving a file in a client input stream delegate 
> method, if the stream terminated from the server because it was too 
> large, the client terminates on an unarchiver error because it 
> didn't get the whole stream.


That doesn't seem surprising.

>  Third, the output stream methods shown in Echo Server are polling 
> methods, not delegate methods.


Well, it does blocking output, true.  And it doesn't account for the 
possibility of partial writes.  If it were to account for that, I 
would expect that it would loop around the [ostream write:buffer 
maxLength:actuallyRead], advancing the buffer and decrementing the 
length each time.  And it would handle errors.

For it to properly perform asynchronous output using delegate methods, 
it would need to buffer the data it receives from clients.  But it 
would have to impose some limit on the amount of data it is willing to 
buffer before it can be written out.  When it hit that limit, it would 
have to stop reading from that client until it could send some of its 
output.

By writing synchronously, it's effectively doing that with some 
automatic, smallish buffer supplied by the underlying APIs.  However, 
a block on one client causes a block of the entire server.

A better approach might be to suspend processing of that one client's 
input stream by removing it from the runloop.  Then, when that 
client's buffer drained a bit, due to some 
NSStreamEventHasSpaceAvailable events, the input stream could be re-
added to the runloop.  If you just ignore 
NSStreamEventHasSpaceAvailable events rather than unscheduling the 
input stream, then I think you'll get them in a tight loop and your 
server will eat CPU like mad.


> 1. How do I stream a large file between connections or is NSStream 
> the wrong tool?  Can the stream size be modified?
>
> 2. What is the largest stream size?


There's no such thing as "stream size".  That's one of the defining 
characteristics of a stream.

> 3. Is it possible to detect a valid archive before I unarchive it, 
> or do I simply have to intercept the exception?


I think you just have to catch the exception.

> 4. How does one trigger and make available a file an output stream 
> so that the delegate methods can be used?


I don't understand what you're asking here.

-Ken