Re: NSInputStream created from NSData - expected it to close at end of data, did not happen
Re: NSInputStream created from NSData - expected it to close at end of data, did not happen
- Subject: Re: NSInputStream created from NSData - expected it to close at end of data, did not happen
- From: email@hidden
- Date: Sat, 11 Jun 2011 02:35:34 +0200
Am 11.06.2011 um 02:13 schrieb Jens Alfke:
>
> On Jun 10, 2011, at 4:55 PM, email@hidden wrote:
>
>> 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:].
>
> That seems convoluted. Why not just use the input stream from the socket?
I might not have explained very well what I'm trying to do and how.
I want the TCPServer to return some data block to each client that connects. I basically just want to put the bytes of the NSData object one after another on the outputstream that is connected to the socket.
Problem: I would have to save the position in the data for each client to return the correct bytes to the client. At that point I thought that's what streams are for. To save your current position in a blob of bytes that should be read in order.
Solution: Create a new NSInputStream (independent from the input stream of the TCPServer. That's why I talked about the data input stream, the input stream that reads the bytes of the data object) for each incoming connection. Guessing that after the NSInputStream based on the data is open it won't have any problems reading the data I only wait for the output stream to have space available and whenever it has I read some bytes from the data input stream and write them on the server output stream. I completely ignore the server input stream (except for logging the received data, when searching for bugs).
Why do I need a TCPServer that returns just a block of data no matter what happens and who connects?
I'm implementing a custom protocol over TCP and want to be able to test my implementation. I implemented part of the parsing of the data sent over TCP in a state machine in stream:handleEvent:. Thus I thought the easiest (and most reliable because similar to real-world) way to test the behavior of my implementation would be to prepare some data blocks that represent a sample communication and just let that be sent to the client (=my implementation) over an actual TCP connection.
-- excursus--
The simplicity is already gone, so I would be happy to try another way to test the implementation as well. But I can't think of one, because the only way to hook into the client code is to provide a stream which returns the correct data, since the client reads the data from the stream. And the easiest way to provide the stream is to tell the client to connect to a specific server and get streams from that connection.
And I don't want to change the client implementation just to be able to test it. ^^
--excursus end--
> [Suggestion: You might want to take this to the macnetworkprog mailing list, as it’s more on-topic there and there will be more networking gurus to help out.]
Thanks for the suggestion. I think my problem is more related to streams in general (perhaps NSStream in particular, but probably not specifically related to networking). Do you still think it would be good to take it over because of the strong relationship of networking and streams?_______________________________________________
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