TCP/IP (FreeRTOS + LwiP を使用) を使用して 1k データを送信しています。ドキュメントから、TCP/IP プロトコルにはスタック自体の内部にフロー制御があることを理解しましたが、このフロー制御はネットワーク バッファに依存しています。以下で説明する私のシナリオでこれをどのように処理できるかわかりません。
WiFi から TCP/IP を使用して 1k サイズのデータを受信します (このデータ レートは 20Mb/s になります)
受信した Wifi データは 10k サイズのキューに入れられます。各ブロックのサイズは 1K です。
キューから各ブロックが取得され、1Mb/s の低レートで別のインターフェイスに送信されます
このシナリオでは、wifi <-> キューからのデータ間に手動でフロー制御を実装する必要がありますか? どうすればこれを達成できますか？
いいえ、フロー制御を自分で実装する必要はありません。TCP アルゴリズムが内部的に処理します。
基本的に何が起こるかというと、TCP セグメントが送信者から受信されると、LwIP はバッファに残っている利用可能なスペース (ウィンドウ サイズ) を含む ACK を送り返します。データが処理できるよりも速く到着するため、スタックは最終的にウィンドウ サイズがゼロの ACK を返します。これは送信者のスタックにバックオフして後で再試行するように指示します。これは自動的に行われます。ネットワーク バッファからより多くのデータを抽出しようとすると、スタックは最後に受信したセグメントに再度 ACK 応答する必要がありますが、今回だけウィンドウを開いて、より多くのデータを受信できることを示します。
回避したいのは、愚かなウィンドウ症候群と呼ばれるものです。これは、ネットワークの使用率とパフォーマンスに劇的な影響を与える可能性があるためです. 可能であれば、ネットワークから大きなチャンクでデータを読み取るようにしてください。一度に 1 バイトずつバッファを埋めるタイトなループは避けてください。