Its shameful that still after all this time, numerous reports to apple and media publications it is only getting traction now. The iOs6 datagate. It is not the case of apple mistake or not knowing about the issue. I as a developer of apps on ios personally reported the issue to Apple well over a month ago right on the release of the Latest iOs 6.0 release. No one has ever returned my emails. Many have laughed at us stating that perhaps we should get a better servers. The answer is we have state of the art servers, one of the best sysadmins that we could ever have and the support team of testers that reach thousands.
The headache that we had to endure durring the investigation of the problem is best described by Our System administrator the IT architect of the NoAgenda stream, podcast archives and related services. Mark van Dijk.
I have been dealing with the iOS 6 issue since IOS6 developer edition
(and later iOS6 “stable”) came out. I’m not Apple savvy myself but due
to the mess this iOS version has brought us I had to deal with a lot of
Apple clients and users. Apple was able to turn my hairs gray. And I’m
still barely under 30!
At first no one expected the issues to be on the receiver side. The
argument I heard the most was “your server sucks! Must be your server
because I am able to download e.g. TWiT very fast!”
I don’t know whether that’s true or not but it could be the case. A
while ago I was on the phone with a CDN provider. They told me that they
put machines in front of their webservers, these machines ignore the
webserver’s TCP settings by reassembling the webserver’s packets and
then using their own settings to push the data over the internet as fast
Still, this doesn’t mean that our servers are doing anything wrong. As I
wrote as a response under a pseudonym in the article:
“With our podcasts we used to be able to handle our clients’
requests with a simple 32 bit webserver. Once IOS 6 (first the
developer beta, then public stable) started to hit our server it
choked. Too many requests from these clients, effectively ddossing
At that time I found out that the clients were connecting and then, even
after transmitting a few bytes, they disconnected and reconnecting. This
occurs RAPIDLY, sometimes multiple times per second. At first I thought
we just had a few jokers that didn’t like the podcast but as time
progressed connections from broken clients increased.
“So I tested many different webservers. I don’t know why Apache
logs 88MB, I think it is because Apache logs the _requested_
accumulated byte range rather than the actually _transferred_
bytecount. When you try nginx, varnish, thttpd, lighttpd and so on
they all log different requests. Also, there is a difference with
Linux and FreeBSD where the latter logs the minimum used buffer,
which I think normally is 8 kbyte.
So while investigating I became none the wiser on how to mitigate
the issue for IOS6 devices. I’ve even come to believe that there is
no way at all, at the sending side, to resolve it.
Luckily I did test so many servers that I am at least able to say
that lighttpd performed much better than all other webservers.
Especially with fam/gamin, which tells lighttpd whether a file has
been changed or not. Disk IO went way down while throughput went
way up. For all devices except IOS6. ”
At the same time several other publications and podcasters have seen them self affected with this issue and the most important is the general public that is being neglected. The Apple’s Office Support Community had this on they radar as of Sep 24, 2012 11:13 AM and have not had any official response.
As per my personal usage I have Clocked over 16 Gb on my iPhone 4s with iOs6.0 running and after update to 6.0.1 to 1 Gb over 5 days. Leaving that a question is there a Conspiracy to A. destroy apple Inc from within B. to cash in on data bills C. just simple neglect on development site and further cover up?
Share your iOs experience with us.