Am I the only one that gets ticked off at the Apple iPhone update
procedure and the amount of bandwidth it needs?
Is there any secret I am missing to cut down on the required bandwidth
needed for it (caching the update somewhere etc)? I don't own an
iPhone (DroidX user here) and am unfamiliar with the update, all I
know is it uses tons of BW.
I set up an OS X server which hosts updates for the rest of the company, so the OS X client machines poll/pull updates from the internal machine as opposed to 100 of them pulling the same updates over the internet. saves bucket loads of bandwidth and you can "pre ok" individual packages, so the client just updates without prompting. I'm not sure but I suspect they might have something which allows their other devices to poll this same source. it would seem reasonable anyway..
probably not a very useful answer but there it is. 8)
-g
iOS (or iPhone OS, whatever) updates aren't simple deltas (i.e. here's the
stuff that changed) - each update is a complete copy of the device's whole
operating system. They always are a few hundred megabytes.
In theory, you could download the updates manually, extract the firmware,
and have your users pull it from your Web server, and then enter the secret
recipe into iTunes to let the customer's computer install an iOS update from
a "local" file instead of using the built-in update service. This of course
defeats the whole purpose of Apple gear, that being that it's simple and
Everything Just Works. iOS developers have to do this all the time, but most
residential folks aren't gonna.
They pay for bandwidth, and it's your job to deliver it.
David Smith
MVN.net
Interesting.
Do you have to configure the iPhone devices or just use its standard settings?
sorry Joe if i wasn't clear, what i was trying to say is I know there is a solution to address the bandwidth issue caused by updates for OS X machines, I am unsure if they have a similar solution for their hand held devices. I am assuming they do or soon will. I'm on the road right now, when I return to the office I'll take a look at the OS X update server and see if there is any provisions for the iPhones and friends.
perhaps a squid caching server in-between the device network and internet? back in the day this is how i mitigated other many to one client update issues.
-g
That would be my suggestion, as well. iTunes pulls the updates from appldnld.apple.com.edgesuite.net or appldnld.apple.com, so you'd only need to cache those two.
This is what I am doing for my home-lan. I have a few machines of the Mac variety and having a properly tuned transparent cache seems to solve the major issue.
This isn't #apple forum, but back in the 1.0.0 they did post binary 'patch' updates for the first few revisions but eventually moved to using the full 'restore' image. I suspect this was in direct response to the "jailbreak/unlocker" community, as well as just plain-ol bugs as it relates to the binary patch process. There seemed to be a large number of people who had trouble with that.
I'm sure if you approached the CDN that hosts the #apple updates they would be willing to put a copy of swcdn.apple.com on your network, as well as appldnld.apple.com
The squid user forums have lots of tips about how to do this for apple and microsoft sw updates.
- Jared
Apple is ultra protective of their mobile stuff. It¹s just going to get
worse in the attempts to circumvent the devices being ³Jailbroken². Quite a
bit of behind the scenes checksums and re-checks going on. They want to
make sure the device cleanly downloads, cleanly installs, and is not
tampered with. Itunes is responsible for doing all this in the background.
Justin
<snip>
I'm sure if you approached the CDN that hosts the #apple updates they would
be willing to put a copy of swcdn.apple.com on your network, as well as
appldnld.apple.comThe squid user forums have lots of tips about how to do this for apple and
microsoft sw updates.- Jared
If anyone does move forward with this, I'd be interested in what sort of
bandwidth savings are realized.
-brandon
Thank you. this is good info.