NSURLConnection Latency on iPhone
NSURLConnection Latency on iPhone
- Subject: NSURLConnection Latency on iPhone
- From: Matthew Rushton <email@hidden>
- Date: Sun, 28 Dec 2008 19:00:18 -0800 (PST)
After more time on this the issue is 100% latency on the wireless network. On the iPhone using NSURLConnection for any performance based networking is not going to work well at least not without accommodations (for example doing some snooping showed that the native maps app requests multiple tiles with each request and not one at a time sequentially). I've looked in to using CFHttpStream to try and get http pipelining to work (which would solve my problem) but the documentation was lacking and it's unclear what exactly the behavior is and/or if it can change between releases. I have no desire to handle http connections myself to get pipelining to work either. So unless anyone has any other ideas or has had success with http pipelining using a relatively simple solution I think I'm going back to my more light weight custom tcp proto that does pipelining rather than using http requests. That's it!
-Matt
--- On Sat, 12/27/08, Matthew Rushton <email@hidden> wrote:
> From: Matthew Rushton <email@hidden>
> Subject: NSURLConnection on iPhone
> To: "Jens Alfke" <email@hidden>
> Cc: email@hidden
> Date: Saturday, December 27, 2008, 11:24 PM
> A bunch of issues have come up when trying to implement
> NSURLConnection on the iPhone and they are all performance
> related. My basic setup is that I'm downloading images
> via http requests and I need to do it as fast as possible.
> For each image I'm sending a request via NSURLConnection
> and using the delegate callbacks, it is single threaded. I
> had been using a tcp connection and the low level socket api
> which was working well but had some other unrelated issues
> (also was single threaded). With NSURLConnection I'm
> getting about half the throughput. I would expect a slight
> decrease given the fact that tcp connections may need to be
> set up on occassion but I think it should be small and I am
> using keep-alive to mitigate this. There seems to be some
> latency issues that are causing tcp to misbehave. I'm
> seeing a good amount of TCP retransmissions. I'm trying
> to figure out why exactly this is so much slower than my old
> method, and what about NSURLConnection
> would cause the different TCP behavior I am seeing. I do
> know that the Maps app on the iPhone uses http requests and
> it is quite fast so I don't think it's because of
> that. Any insight or thoughts would be welcome! Thanks.
> -Matt
>
> --- On Mon, 12/22/08, Matthew Rushton
> <email@hidden> wrote:
> From: Matthew Rushton <email@hidden>
> Subject: Re: CFHttpMessage and keep-alive
> To: "Jens Alfke" <email@hidden>
> Cc: email@hidden
> Date: Monday, December 22, 2008, 10:49 AM
>
> Cool, that looks like what I wanted. Thanks!
> -Matt
>
>
> --- On Sun, 12/21/08, Jens Alfke <email@hidden>
> wrote:
>
> > From: Jens Alfke <email@hidden>
> > Subject: Re: CFHttpMessage and keep-alive
> > To: email@hidden
> > Cc: email@hidden
> > Date: Sunday, December 21, 2008, 1:31 AM
> > On Dec 20, 2008, at 8:43 AM, Matthew Rushton wrote:
> >
> > > I clearly could serialize the requests and open a
> > socket much like I am now but what I'm looking for
> is a
> > simpler approach that hid the details in the
> background. Is
> > there anyway doing something more along these lines
> could
> > work with keep-alive
> >
> > Use NSURLConnection; that's the high-level HTTP
> API. It
> > handles pretty much everything for you, including
> > keep-alive, and it's easier to use than CFStream.
> >
> > —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