On 09/23/2013 08:36 PM, Joe Greco wrote: >> That's just the typical Bittorrent /client/, but the idea of using >> Bittorrent means the /protocol/. A special Bittorrent client could be >> written for ISPs with uploads disabled and Apple could also disable them >> on the update-downloading Bittorrent client for the phones. >> >> The clients (be it Bittorrent or not) would still download the MD5 hash >> after the download finishes to verify the integrity of the download, and >> Apple would still be able to measure the amount of downloaded images. > > So then all the networks that have done $things to BitTorrent to demote it > to second-rate traffic will suddenly have a bunch of very angry Apple fans > whose downloads are mysteriously having issues.
No, usually that traffic is demoted right before upstream (or in some way not very near to the provider-edge-to-customer device). Once the download is ready on the ISP, that would be a solved problem. And also, the phone could support two protocols as a transition. It's the easiest solution I've read so far. There are others but not as easy. > And then - assuming you intend for more things than just Apple to go this > route - all the CDN's would need to be redesigned to support BT too. Why can't it be implemented as an independent mean of delivering updates? > It seems like it'd be simpler for Apple to figure out how to validate a > partial download and then resume. It isn't like that would be cutting > edge technology. I think I might even have seen it happen before. Validate partial download? How would that help to reduce the overall load on the ISP? That is only limited to reducing the "redundant" traffic, where "redundant" means "twice per device", not "twice per content", which is the real problem. Cheers.
