1

これは、特定のコードに関する質問というよりも、設計に関する質問です。明らかなことを見逃していると確信しています。別の目が必要なだけです。

私はWSAAsyncSelectに基づいてマルチクライアントサーバーを作成しています.各接続は、関連する設定やバッファなどを含む、作成した接続クラスのオブジェクトになります.

私の質問は FD_WRITE に関するものです。それがどのように動作するかは理解しています。接続が確立された直後に 1 つの FD_WRITE が送信されます。その後、WSAEWOULDBLOCK が受信されるまで送信する必要があります。受信した時点で、送信するために残っているものをバッファに格納し、再度送信してもよいというメッセージが表示されるのを待ちます。

これは私が問題を抱えているところです.各接続オブジェクト内でこの保持バッファをどのくらいの大きさにしますか? 新しい FD_WRITE が受信されるまでの時間は不明です。この期間中に大量のデータを送信しようとして、常に発信バッファーに追加されている可能性があります。バッファーを動的にすると、何らかの理由で send() を実行してバッファーを削減できない場合、メモリ使用量が制御不能になる可能性があります。

だから私の質問は、一般的にこの状況をどのように処理しますか? winsock が使用するネットワーク バッファ自体について話しているわけではありませんが、送信を「キューに入れる」ために使用された私自身の作成の 1 つに注意してください。

私はそれを十分に説明したいと思います、ありがとう!

4

1 に答える 1

0

当然、正しい設計はアプリケーションの性質によって異なります。

一部のプログラムは、何かを実行する前に生成できるデータの量を予測できるため、固定サイズのバッファーを使用できます。たとえば、私が設計した 1 つのプロトコルは、コマンド応答構造と 2 バイト長のプレフィックスを持っていたので、64K のバッファーを使用でき、決してオーバーフローしないことがわかっていました。バッファーがいっぱいの場合、プログラムは、そのバッファーからデータを送信できるようになる前に応答を待機する必要があるため、そのバッファーにそれ以上データが追加されることはありません。

固定サイズのバッファーのもう 1 つの適切な使用法は、データが別の I/O ソースから来る場合です。Web サーバーを考えてみましょう。最も基本的なものとして、ディスクからファイルを丸呑みし、ネットワーク上に吐き出します。したがって、一度にディスクから読み取っている量がわかるため、バッファがどれだけ大きくなければならないかがわかります。

動的バッファーを使用する正当な理由が思いつきません。

それらを必要としない主な理由は、TCP のスライディング ウィンドウです。接続ピアの 1 つがデータの受信を停止すると、リモート ピアのスタックは、TCP ウィンドウがいっぱいになるとデータの送信を停止します。読み取られていないデータは、送信先のプログラムが要求するまで、受信スタックのバッファーに残ります。これにより、レシーバーは受信データを処理できるレベルに調整することができます。私が知る限り、固定サイズのバッファはあらゆる条件下で実用的です。

于 2010-06-14T14:41:16.713 に答える