2

.Net TcpClient / Sockets を使用して HTTP クライアントを作成しています。

これまでのところ、クライアントは (TcpClient に GET 要求を書き込んだ後) NetworkStream 応答を反復処理し、ヘッダーを解析し、関連するメッセージ本文のバイト/チャンク バイトを取得することで、Content-Length とチャンクされた応答の両方を処理します。これを行うために、NetworkStream の ReadByte メソッドを使用します。

これはすべて正常に機能しますが、パフォーマンスはアプリケーションの重要な考慮事項であるため、できるだけ迅速かつ効率的にしたいと考えています。

最初にこれには、メッセージ本文の Read と ReadByte の交換 (Content-Length に基づく)、または適切なサイズのバッファーへのチャンクされたメッセージ本文バイトの取得、他のすべての領域 (ヘッダー、チャンク サイズなどの読み取りなど) での ReadByte の使用が含まれます。

最適なパフォーマンスを達成するためにこれを行うためのより良い/さまざまな方法についての考えを知りたいですか? 明らかに、HTTP の主な問題は、取得時に解析されない限り、応答ストリームの長さがわからないことです。

これには、より抽象的なクラス (HttpWebRequest など) を使用しない特定の理由があります (ソケット レベルでより適切に制御する必要があります)。

どうもありがとう、

クリス

4

1 に答える 1

1

中規模のバッファを持つプロセスを使用することをお勧めします。応答ストリームが終了するまで、バッファを繰り返し埋めます。バッファーがいっぱいになるか、ストリームが終了したら、そのバッファーの内容を文字列 (またはメッセージの保存に使用しているもの) にアタッチします。

ストリームの早い段階で重要な情報を読みたい場合は、ストリームを十分に読んでください。(つまり、必要がなければ、最初のパスでバッファを埋める必要はありません。)

また、イベント システムを使用して新しいデータの存在を通知することも検討する必要があります。このデータは、プロセスの主要部分がデータの取得元やバッファリング方法について何も知る必要がないように形成されています。 .

編集

コメントの質問への回答として、複数のリクエストで再利用しようとしている接続が 1 つある場合は、その接続から何度も読み取るスレッドを作成します。データが見つかると、イベントを使用して、プログラムの主要部分が処理できるようにデータをプッシュします。手元にサンプルはありませんが、いくつかの bing または google 検索でいくつかを見つけることができるはずです。

于 2009-12-01T18:28:17.193 に答える