この質問は、私が過去数日間に尋ねた他の2つの質問の結果です。
送信/受信のフローを制御する方法を理解する上での「次のステップ」に関連していると思うので、新しい質問を作成しています。これについては、まだ完全な答えは得られていません。
その他の関連する質問は次
のとおりです。IOCPドキュメントの解釈に関する質問-バッファの所有権のあいまいさ
非ブロッキングTCPバッファの問題
要約すると、私はWindows I/O完了ポートを使用しています。
完了ポートからの通知を処理するスレッドがいくつかあります。
質問はプラットフォームに依存せず、* nix、* BSD、Solarisシステムで同じことをするのと同じ答えになると思います。
ですから、私は自分のフロー制御システムを持っている必要があります。罰金。
だから私は送信と送信をたくさん送信します。受信側はX量に制限されているため、送信のキューイングをいつ開始するかをどのように知ることができますか？
例を見てみましょう（私の質問に最も近いもの）：FTPプロトコル。
私は2台のサーバーを持っています。1つは100Mbリンク上にあり、もう1つは10Mbリンク上にあります。
100Mbをもう一方（10Mbにリンクされたもの）に1GBのファイルを送信するように注文します。平均転送速度は1.25MB/秒で終了します。
送信者（100Mbにリンクされたもの）は、送信を保留するタイミングをどのように知っていたので、遅い送信者がフラッディングされませんでしたか？（この場合、「送信される」キューはハードディスク上の実際のファイルです）。
これを尋ねる別の方法：
リモート側から「送信保留」通知を受け取ることはできますか？TCPに組み込まれているのでしょうか、それともいわゆる「信頼性の高いネットワークプロトコル」である必要がありますか？
もちろん、送信を固定バイト数に制限することもできますが、それは私には正しく聞こえません。
繰り返しになりますが、リモートサーバーへの送信が多いループがあり、そのループ内のある時点で、その送信をキューに入れるか、トランスポート層（TCP）に渡すことができるかを判断する必要があります。
それ、どうやったら出来るの？あなたならどうしますか？もちろん、送信が完了したというIOCPからの完了通知を受け取ったら、他の保留中の送信を発行します。これは明らかです。
これに関連する別の設計上の質問：
送信キューでカスタムバッファを使用するため、「送信完了」通知が到着したときにこれらのバッファは解放されて再利用されます（したがって、「delete」キーワードは使用されません）。 、そのバッファプールで相互除外を使用する必要があります。
ミューテックスを使用すると処理が遅くなるので、私は考えていました。各スレッドに独自のバッファプールを持たせないのはなぜですか。したがって、少なくとも送信操作に必要なバッファを取得するときにアクセスする場合、スレッドのみに属するため、ミューテックスは必要ありません。
バッファープールは、スレッドローカルストレージ（TLS）レベルにあります。
相互プールがないということは、ロックが不要であることを意味し、操作が高速であることを意味しますが、一方のスレッドがすでに1000個のバッファーを割り当てている場合でも、現在送信中で、何かを送信するために1000個のバッファーが必要なもう一方のスレッドは、割り当てる必要があるため、アプリによって使用されるメモリも多くなります。これらを独自に。
別の問題：
「送信予定」キューにバッファA、B、Cがあるとします。
次に、受信者が15バイトのうち10バイトを取得したことを通知する完了通知を受け取ります。バッファの相対オフセットから再送信する必要がありますか、それともTCPがそれを処理しますか、つまり送信を完了しますか？また、必要に応じて、このバッファがキュー内の「次に送信される」バッファであると確信できますか、それともたとえばバッファBである可能性がありますか？
これは長い質問であり、誰もけがをしなかったことを願っています（：
誰かがここで答えるのに時間がかかるのを見てみたいです。私は彼に二重投票することを約束します！（：
ありがとうございました！