ServerSentEvents can take down IIS about signalr-objc HOT 2 CLOSED

Replication steps:

1. Start a client in both the web browser and on the ipad
2. open performance monitor on the server add "Requests Executing"
3. Direct each client to use the mouse tracking sample
4. Ensure that the objective c client is using server sent events for the transport (explicitly set it)
5. move the mouse to demonstrate a successful connection to the ipad
6. allow the ipads connection to timeout. (all clients should be idle) for roughly 2 minutes
7. notice how in perf mon a new executing request is added. not replaced as we would expect.
   • when debugging with the c# client the number of executing requests decreases by 1 before the new one is added, this does not happen when using the objective c client
8. Eventually, in iis if the hub is idle iis will prevent any new connection and require an iisreset

Notes:

• I have not been able to definitively determine if this issue is on the ios client side or resides in the server. All things point to the client since this is only an issue with the objective c clients and only with server sent events (long polling appears to work fine)
• My gut seems to point to the NSOutputStream object that is used in AsyncStreamReader in ServerSentEvents.h and created in [SRHttpHelper getAsync], this stream is closed when a timeout occurs but the timeout error occurs on the url connection and not the stream which might be part of the issue.
• Something worth noting is that if new data is received (move the mouse) after one or more timeouts occur then the dangling connections are correctly cleaned up. Which is what could suggest that this is a server bug and not a client bug.

from signalr-objc.

I have done a test that removes the need for NSOutputStream and instead just processes the data directly, and the issue still persists. I think it is safe to rule out NSOutputStream as the culprit which after thinking about it more makes sense since the output stream is only used internally to store the NSData that is being received by the NSURLConnection. These findings indicate that either the NSURLConnection is not being closed properly or something is wrong server side

from signalr-objc.