iPhone 能够在多任务环境中自动暂停和恢复文件下载
最近我在 iPhone 上开发了一个简单的文件下载应用程序。我在 Iphone 3gs 上对此进行了测试，发现了一些有趣的东西。
当应用程序开始下载文件时，我关闭它。我在一段时间后（比如 6 秒）重新打开应用程序，下载实际上从它留下的位置开始。
软件如何能够暂停和恢复http下载。 （我的 tomcat 服务器没有任何流或恢复功能）
我的设置， Tomcat ，带有一个 Servlet，基本上从文件系统读取并发送出去。 Iphone 3gs，和简单的文件下载应用程序，我没有启用任何UIBackgroundModes。添加进度条来代表状态
Recently I developed a simple file download application in Iphone. I was testing this in the Iphone 3gs and found something interesting.
I close the application, when it begins downloading the file. I opened back the application after some time (say 6 seconds), the download actually starts from where it has left behind.
How can the software be capable of pausing and resuming the http download. (My tomcat server does not has any streaming or resuming capability )
My Setup,
Tomcat , with a Servlet which basically read from filesystem and send outs.
Iphone 3gs, and simple file download application ,I have not enabled any UIBackgroundModes. a progress bar added to represent the state
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您所看到的是在您的应用程序未处于活动状态期间连接超时未触发的问题。更详细地说：
当您打开连接并开始通过它传输数据时，操作系统会为该连接关联一个超时（即 90 秒、60 秒、300 秒，具体取决于您通常可以调整的一些设置） ，尽管并不总是那么容易）；
这个超时用于监控连接状态；如果超过超时时间没有数据传输，则认为连接已断开，或者认为已被对方关闭；
这是必要的，因为远程连接的质量差异很大，如果您检查传输，您会发现它们可以“轻松”停止几秒钟，甚至更长时间；
如果数据传输停止一段时间，但在连接超时触发之前恢复，则网络协议（所有客户端和服务器端）在设计上能够恢复数据传输，因为没有中断（网络协议具有处理此问题的特定功能，例如将数据分成较小的数据包并对每个数据包进行编号，以确保所有数据包都被传输，并且如果通信中出现任何问题，可以根据发送顺序重新排列它们） ;
因此，这应该可以解释这样一个事实：您的应用程序在停止 6 秒后确实恢复了连接，没有出现任何故障。
如果您让应用程序关闭较长时间，您会发现连接会中断。
What you are witnessing is a matter of connection timeout not firing during the time your app has not been active. In some more detail:
when you open a connection and start transferring data across it, the OS associate to the connection a timeout (which is say 90 sec, 60 sec, 300 sec, depending on some setting that you can generally tweak, although not always easily);
this timeout is used to monitor the connection state; if no data is transferred for a period longer than the timeout, then the connection is deemed broken, or it is assumed that it has been closed by the other party;
this is necessary because a remote connection is highly variable in quality and if you inspect your transfer you will notice that they can "easily" stop for a few seconds, or even more;
if data transmission stops for a while, but resumes before the connection time out fires, the network protocols (all of them, client-side and server-side) are able by design to resume data transfer as there had been no interruption (network protocols have specific features dealing with that, like chunking your data into smaller packets and numbering each packet to ensure that all of them are trasmitted and that it is possible to rearrange them according to the sending order if anything went astray in the communication);
So this should explain the fact that your app after a 6 seconds halt did resume the connection without a hitch.
If you let you app closed for a longer period of time, you will see that the connection will break.
将大数据分割成小部分是 HTTP 标准的基本功能。请参阅HTTP1.1 - 第 14.16 节 - 内容范围了解详情。 Cocoa 实现很可能默认处理所有这些。大的下载将在传输过程中被缓存，并根据请求自动恢复。
服务器和 iPhone 实际上不需要任何额外的软件来支持此功能。在 HTTP 通信环境中，每次下载只是从服务器发出的许多数据包，并且这些数据包中的任何一个都可能需要很长时间才能真正到达接收设备。恢复的下载实际上只是相同的下载，但数据包之间有异常长的延迟。
Slicing large data up into small portions is a basic feature of the HTTP standard. See HTTP1.1 - Section 14.16 - Content-Range for details. The Cocoa implementation more than likely handles all of this by default. A large download will be cached during transmission and automatically resumed on request.
The server and the iPhone don't really need any extra software to support this feature. In the context of HTTP communication, every download is just a number of data packets sent out from the server, and any of these packets can take a long time to actually reach the receiving device. A resumed download is really just the same download, with an unusually long delay between packets.