2

我们的系统旨在部署到网络连接不可靠和/或不足的区域。我们构建了我们自己的使用BITS的容错数据复制服务。

由于一些安全和维护需求，我们在服务器端实现了自己的 ASP.NET 文件下载服务，而不是仅仅让 IIS 提供文件。当 BITS 客户端使用指定的文件范围发出 HTTP 下载请求时，我们的 ASP.NET 页面将所需的文件段拉入内存并将其作为 HTTP 响应提供。这就是理论。;) 这个理论在人工实验室场景中失败了，但我不会让系统部署在现实生活场景中，除非我们能够克服这一点。

实验室场景：我在同一台开发机器上拥有 BITS 客户端和 IIS，因此实际上我拥有巨大的网络“带宽”，而 BITS 足够智能，可以检测到这一点。随着BITS客户端发现无限带宽，它变得越来越“贪婪”。在每个 HTTP 请求中，BITS 想要获取越来越大的文件范围（我们正在谈论下载 CD iso 文件、视频），在单个 HTTP 请求中要求 20-40MB，这个大小我不愿意在服务器端一气呵成。我可以通过给予少于要求的东西来克服这一点。没关系。

然而，BITS 在没有指定下载范围的情况下获得真正“自信”和“傲慢”的文件，即它希望在单个请求中获取整个文件，这就是问题所在。对于 600MB 的文件，我不知道如何回答该响应。如果我只提供文件的起始 1MB 范围，BITS 客户端会继续发送对同一文件的 HTTP 请求而没有下载范围以继续，它强调了它想要一次性完成整个文件的观点。由于我不愿意提供整个文件，BITS 在多次尝试后放弃并报告错误。

有什么想法吗？

4

1 回答 1

3

看来，我们可以解决这个问题。有几件事：

  • 我们需要控制每个传入的请求，所以我们不能让 IIS 单独处理请求。但是，仍然没有必要为了方便下载而将文件拉入内存：Request.TransferFile(...) 实际上无需将文件拉入内存即可完成所有繁重的工作，而我们仍然保持对处理请求的控制。
  • BITS 实现看起来非常智能，如何处理各种情况。我们了解到，如果 BITS 请求没有指定范围的完整文件，即使是几个 GB，我们也可以让它拥有它。一旦它接收到第一个 HTTP 数据包并发现它比它可以吞下的大，它立即取消请求并重新请求它以适当的范围。
  • BITS 允许配置最大带宽并安排何时允许使用网络资源。虽然此配置适用于客户端，但在我们的特定情况下是可以的。
于 2010-03-10T08:26:41.057 回答