2

当社のシステムは、ネットワーク接続が不安定または不十分な地域に展開するように設計されています。私たちは、 BITSを使用するフォールト トレラントなデータ レプリケーション サービスを独自に構築しています。

セキュリティとメンテナンスの要件により、IIS にファイルを提供させるだけでなく、独自の ASP.NET ファイル ダウンロード サービスをサーバー側に実装しました。BITS クライアントが指定された範囲のファイルで HTTP ダウンロード要求を行うと、ASP.NET ページは要求されたファイル セグメントをメモリに取り込み、それを HTTP 応答として提供します。それが理論です。;) この理論は人工実験室のシナリオでは失敗しますが、それを克服できない限り、システムを実際のシナリオに展開することはできません.

ラボ シナリオ: BITS クライアントと IIS を同じ開発者用コンピューターに配置しているため、実際には膨大なネットワーク "帯域幅" があり、BITS はそれを検出するのに十分なほどインテリジェントです。BITS クライアントが無制限の帯域幅を発見すると、ますます「貪欲」になります。各 HTTP 要求で、BITS はますます大きなファイル範囲 (CD iso ファイル、ビデオのダウンロードについて話している) を把握しようとし、1 つの HTTP 要求内で 20 ～ 40MB を要求します。サーバー側はそのまま。私は要求されたよりも少ないものを与えるだけでそれを克服することができます. 大丈夫です。

ただし、BITS は、ダウンロード範囲を指定せずに、本当に「自信を持って」「傲慢に」要求の厳しいファイルを取得します。つまり、ファイル全体を 1 回の要求で要求します。600MBのファイルの場合、その応答の仕方がわかりません。ファイルの最初の 1 MB の範囲を指定しただけでは、BITS クライアントはダウンロード範囲なしで同じファイルの HTTP 要求を送信し続け、ファイル全体を一度に取得したいという点を強調します。ファイル全体を提供するのは気が進まないので、BITS は試行錯誤の末にあきらめ、エラーを報告します。

何かご意見は？

4

1 に答える 1

3

どうやら、問題を解決できたようです。いくつかのことがあります：

  • すべての着信要求を制御する必要があったため、IIS だけに要求を処理させることはできませんでした。ただし、ダウンロードを容易にするためだけにファイルをメモリにプルする必要はありません。 Request.TransferFile(...) は、ファイルをメモリにプルすることなく実際にすべての面倒な作業を行いますが、リクエストの処理に対する制御は引き続き維持されます。
  • BITS の実装は、さまざまなケースを処理する方法が非常にインテリジェントに見えます。BITS が範囲を指定せずに完全なファイルを要求する場合、たとえ数 GB であっても、それを取得できることを学びました。最初の HTTP パケットを受信し、これが飲み込めないほど大きいと判断するとすぐに、リクエストをキャンセルし、適切な範囲で再リクエストします。
  • BITS を使用すると、最大帯域幅を構成し、ネットワーク リソースの使用をいつ許可するかをスケジュールできます。この構成はクライアント側に適用できますが、この特定のケースでは問題ありません。
于 2010-03-10T08:26:41.057 に答える