Am 10.06.2011 um 21:19 schrieb Jens Alfke: > On Jun 10, 2011, at 11:39 AM, jodischla...@gmx.de wrote: > >> 1. There an NSStream event "NSStreamEventEndEncountered". I would have >> expected to be sent this event when the Stream created from a piece of data >> reaches the end of that data. But okay, you said that one has to close the >> stream oneself. So I did that when the data input stream ![stream >> hasBytesAvailable] after having had bytes available. I then close the stream. > > Those two things are not the same. That may be causing your trouble. > The hasBytesAvailable property tells you whether there is data available to > read *right now*. It will return false if you’ve read all the bytes that have > arrived, and no more have arrived yet. Thank you for your patience, but I think I understand the difference. The thing is that I wanted to make a TCPServer that sends a piece of NSData to any client that connects. Thus my plan was to create an NSInputStream via [NSInputStream inputStreamWithData:].
> NSStreamEventEndEncountered is posted when the EOF is reached. Yes, that's what I thought should happen. I expected the stream created from the NSData object to be closed when the end of the data was reached (since that would be an EOF, wouldn't it?) and send me an NSStreamEventEndEncountered. But that did not happen, that's why I asked here. You then told me that the stream would not close itself: Am 2. juni 2011 um 20.40 schrieb Jens Alfke: > On Jun 2, 2011, at 2:10 AM, jodischla...@gmx.de wrote: >> But the inputDataStream seems to never get closed. I would have expected it >> to be closed when it reaches the end of the underlying data. > > No, that’s not how streams behave. They close when you close them, not > automatically. So I thought I would close the stream myself. To do so I waited for it to have bytes available and after that when it does not have bytes available any more I close it. I know that I should not rely on that and that probably won't work for an actual TCP connection but in that case I now that the underlying data of the stream is not coming from a TCP connection or similar but just some NSData object already in memory. Thus I thought I could use this heuristic to close the input data stream when appropriate. That seems to work as far as I can tell with the debugger. It always has bytes available until it reaches the end of the data. So I close it manually when it reaches the end of the data and that seems to work. But I still don't get any NSStreamEventEndEncountered events in the stream:handleEvent: delegate methods (none of them, neither the ones on the TCPServer nor the ones on the TCPClient side). And I wonder why that is. And to repeat the previous problem: > NSStreamEventEndEncountered is posted when the EOF is reached. For a socket, > that means that the other peer closed the connection. So when I close the output stream on the TCPServer I would expect the corresponding input stream on the other side of the TCP connection (on the client side) to close as well. And send an NSStreamEventEndEncountered. That does not seem to happen. > Have you looked at the CocoaEcho sample code? It demonstrates how to do a > simple TCP client and server. (Part of the MYNetwork code was originally > adapted from it.) If you mean that one: >> On Jun 2, 2011, at 2:10 AM, jodischla...@gmx.de wrote: >>> To do so I adapted the CocoaEcho example >>> (http://developer.apple.com/library/mac/samplecode/CocoaEcho/Introduction/Intro.html >>> ). Yes, I did, that's how I tried to create the TCPServer that serves a block of data. ;-) Best regards, Joachim _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
