1

I am re-asking this question under a new, specific hypothesis. If this is the answer I will update/collapse/merge both.

Could AT&T throttling the data usage of a subscriber explain an image that looked like this when loaded by our iOS app:

enter image description here

Originally I thought maybe there was a discrepancy between the content-length header and the actual content sent back. I have simulated the case where a server sends back a body shorter than the reported content length and my client does not behave in this fashion; instead the client waits for 60 seconds and then fails to load the image. That is a fine outcome.

The consequences of this issue here is that my client believes that it has successfully downloaded the image and is caching it, never to redownload again, causing all subsequent views of the image to have the incorrect gray area.

The user who saw this image was running on AT&T 4G, HSPA+, and was very near his max. AT&T sent him a text saying they are throttling him.

Note that the server that served up this image is amazon S3; the client had connected directly to S3 to fetch the image.

If anyone could discuss what happens when AT&T reports that they are throttling a data connection I would be most appreciative!

Community
  • 1
  • 1
esilver
  • 27,713
  • 23
  • 122
  • 168
  • What API are you using to get the image - I'm guessing its dataWithURL or similar - not using a NSURLConnection. If this is occurring on AT&T 3G to S3, you may be suffering from the same problem I am - see https://devforums.apple.com/message/739550 – David H Oct 05 '12 at 23:25
  • @DavidH thanks much -- I was just investigating changing to HTTPS from HTTP (I used HTTP because it was faster for the client esp at startup). In your case it was just timing out. If this is AT&T's fault then my case seems much more insidious -- actually manipulating content. Note I am using Three20 and they use NSURLConnection not dataWithURL. – esilver Oct 05 '12 at 23:49
  • I would not say manipulating content - possibly disconnecting the connection when its provided most of its data. If the image is a progressive then you might have what you show. This really sucks - try HTTPS and see if things change - make sure you update this Q too! – David H Oct 06 '12 at 01:34
  • I don't see how the image above is progressive, because if it was it would be "blurry" the whole way do the end. If ATT is disconnecting the connection, the client would register that as a connection error and not attempt to use/partially decompress the file. Regardless, I have prepared a build doing all image transfers over HTTPS and will report back. – esilver Oct 06 '12 at 05:22
  • The bottom line is that NSURLConnection returns a success or failure message (or indication). If it does not succeed then trash the data and don't show anything. This looks like a partially rendered image (which you can do with the right Quartz method), but once it fails then you need to report it somehow. Its not reflecting the final timeout (connectionFailed) message that seems in play here. The image sure looks blurry to me, thus the thought it was progressive. – David H Oct 06 '12 at 21:17
  • I blurred the image to protect the identity of the user in question, sorry for the confusion. We do not process an image unless we receive a success message. That's the basis of my suspicion that AT&T is tampering with the bits transferred. – esilver Oct 07 '12 at 00:24
  • What's confusing to me is the partial image. If you take a jpg file and set the last n bytes to say 0, my experience is that image will not decode. Unless you are sending instead a raw pixel stream... – David H Oct 07 '12 at 13:07
  • Yeah I thought so too, though I setup a dummy sinatra server, and basically if I set response.body = body[0..10000], so only giving back the first 10,000 bytes, my web browser decoded the top part of the image leaving the rest blank. – esilver Oct 07 '12 at 22:33
  • Well, the web browsers are using partial decoding - as I mentioned earlier one of the Quartz calls can do this too. The question is, what does '[UIImage imageWithData:...]' and friends do? This still does not answer the question of why a TCP connection can return only some of the data then provide a successful return code... – David H Oct 08 '12 at 11:35

0 Answers0