IHttpHandlerクラスからデータをストリーミングしたい。DBから多数の行をロードし、それらをシリアル化して圧縮してから、ネットワークに送信します。一方、サーバーがすべてのオブジェクトのシリアル化を完了する前に、クライアントがデータを解凍し、逆シリアル化できるようにしたいのです。
データの書き込みに使用context.Response.OutputSteam.Writeしていますが、出力データがクライアントに送信される前にバッファーに入れられているようです。このバッファリングを回避する方法はありますか？
メソッドはそれResponse.Flushをネットワークに送信する必要があります。ただし、いくつかの例外があります。IIS が動的圧縮を使用している場合、つまり動的コンテンツを圧縮するように構成されている場合、IIS はストリームをフラッシュしません。次に、「チャンクされた」転送エンコーディング全体があります。指定しない場合Content-Length、受信側は応答本文がどのくらいの大きさになるかわかりません。これは、チャンク転送エンコーディングで実現されます。一部の HTTP サーバーでは、クライアントがAccept-Encodingチャンク キーワードを含む要求ヘッダーを使用する必要があります。他のものは、完全な長さが指定される前にバイトの書き込みを開始すると、デフォルトでチャンクになります。Transfer-Encodingただし、独自の応答ヘッダーを指定した場合、これは行われません。
IIS 7 で圧縮を無効にResponse.Flushすると、常にうまくいくはずですよね? あまり。IIS 7 には、要求と応答をインターセプトして対話する多くのモジュールを含めることができます。デフォルトでインストール/有効化されているものがあるかどうかはわかりませんが、目的の結果に影響を与える可能性があることに注意してください。
... DB から多数の行をロードし、シリアル化して圧縮し、ネットワークに送信しています...
このコンテンツを圧縮していることに興味があります。GZIP を使用している場合は、flush を呼び出してデータを送信するタイミングと量を制御できません。さらに、GZIP コンテンツを使用すると、受信側でもすぐにデータの読み取りを開始できない可能性があります。
レコードを 10、50、または 100 行の消化しやすい小さなチャンクに分割することをお勧めします。それを圧縮して送信し、次の行のセットで作業します。もちろん、圧縮された各行セットの大きさと、最後に達した時点をクライアントに知らせる必要があります。チャンク転送の仕組みの例については、http://en.wikipedia.org/wiki/Chunked_transfer_encodingを参照してください。
context.Response.Flush()またはを使用して、context.Response.OutputSteam.Flush()バッファリングされたコンテンツを強制的にすぐに書き込むことができます。