Re: NSStream, NSInputStream, NSOutputStream
Re: NSStream, NSInputStream, NSOutputStream
- Subject: Re: NSStream, NSInputStream, NSOutputStream
- From: Ken Thomases <email@hidden>
- Date: Sun, 18 May 2008 13:26:02 -0500
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden