Re: Spoon-feeding NSURLConnection
Re: Spoon-feeding NSURLConnection
- Subject: Re: Spoon-feeding NSURLConnection
- From: John Pannell <email@hidden>
- Date: Tue, 26 Jun 2012 21:51:22 -0600
Hi Jens-
This sounds really wrong to me... you'd think that if any framework code has gotten serious exercise over the past decade, it is NSURLConnection.
I have used it in a network/resource intensive app and it has never let me down. After reading your email, I dug back into the source for it and can confirm that this app runs (or at least, requests) 14 simultaneous HTTP NSURLConnections at a given time with no issue.
I saw your email a few days ago as well... I peeked into your github code but couldn't really find my way around in the time I had. Where is the creation of the NSURLConnection(s) in your library, and what object is the delegate? I'm interested to look a little harder if you'll point me in the right direction...
John
On Jun 26, 2012, at 7:33 PM, Jens Alfke wrote:
> In theory, CFNetwork manages HTTP connections so app code doesn't have to. I should be able to open up any number of simultaneous NSURLConnections, and CFNetwork will decide whether to open multiple sockets or pipeline or queue connections or whatever. It should all Just Work™.
>
> Except it isn't. What I'm finding is that if I open large numbers (i.e. more than about 6) of simultaneous [HTTP] NSURLConnections, bad things will happen — some of the later connections will fail with spurious timeouts (-1001) or network-connection-lost errors (-1005) without sending/receiving any data at all; i.e. the remote server's HTTP log doesn't show any requests for those URLs. In some cases I have seen the connection just drop on the floor, with no delegate callbacks at all ever [see my email from a few days ago].
>
> I've started building my own queueing layer to ensure I don't open too many NSURLConnections at once, and that's helping, but this seems like something I shouldn't need to do. Right? Or are their known CFNetwork bugs, or caveats in the documentation that I overlooked?
>
> —Jens
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden