In writing my own WebSocket implementation earlier, I found that it needed a mechanism to pause reading from the input stream. Otherwise you can run into a situation where the remote peer is sending you messages at a high rate, but the messages are slow to be handled locally (maybe each one requires writing to disk) … the result is that memory fills up with queued-up messages. I have literally had this cause out-of-memory crashes in iOS apps.
What I did in that implementation was to add a readPaused property to the WebSocket object. I also added a boolean return value to the delegate receive-message callbacks, so they could return NO to pause the stream. (Here's the commit, if you're curious.)
In writing my own WebSocket implementation earlier, I found that it needed a mechanism to pause reading from the input stream. Otherwise you can run into a situation where the remote peer is sending you messages at a high rate, but the messages are slow to be handled locally (maybe each one requires writing to disk) … the result is that memory fills up with queued-up messages. I have literally had this cause out-of-memory crashes in iOS apps.
What I did in that implementation was to add a
readPausedproperty to the WebSocket object. I also added a boolean return value to the delegate receive-message callbacks, so they could return NO to pause the stream. (Here's the commit, if you're curious.)