私の最愛のソケットについての別の質問。まず、私のケースが何であるかを説明します。その後、私が気になっていることをあなたに話します。
クライアントとサーバーがあります。両方のアプリケーションは、winsock2 実装を使用して C++ で記述されています。接続は TCP および WLAN を介して実行されます。WLan は非常に重要です。なぜなら、おそらく問題の原因であり、間違いなく通信チャネルになるからです。
サーバーに2つのソケットを接続しています。SendSocket と ReceiveSocket。私は常にsendocketを介してサーバーにビデオデータを送信しています。データが処理され、クライアントに送り返されて表示されます。各ソケットには独自のスレッドがあります。
Videodata はエンコードされているため、500kB/s 程度を達成しています。説明なしで、このレートを固定として見てみましょう。
クライアントから見た完璧なコミュニケーション:
Send Data
Recv Data
Send Data
Recv Data
...
これは、100 フレーム程度の場合です。
しかし、数フレームごとに、ストリームは 4 フレームほどフリーズし、その後も続きます。(4 フレームは 500ms のようなものです)
それが問題です、私は直面しています。
ストリームに何が起こるかは次のとおりです。
Send Data
Recv Data
Send Data
Send Data
Send Data1 -> blocked send
Recv Data
Recv Data
Send Data2 -> not blocked anymore.
データはサーバー側で適切に送信されます。
WLanは（私の知る限り）二重化されていないため、何らかの理由で送信呼び出しが優先されると思いました。その後、Receive 呼び出しが優先されるため、recv 呼び出しが完了するまで send 呼び出しはブロックされます。
問題を引き起こす可能性のある下位層で何が起こっているのか教えてください。ところで。それが単なる帯域幅の問題ではないかどうかははっきりとはわかりませんが、WLAN は 500kB/s を処理できるはずだと思いました。この 500kB/s はアップストリームとダウンストリームを合わせたものです。重要なお知らせ: フレームレートを 1/5 に設定しても問題は解決しません。
この洞察でこの問題を解決するのは難しいことを私は知っています。知識を共有していただければ幸いです。自分で修正できるかもしれません。
編集: クライアントの recv が少しハングアップする場合は、まったく問題ありません。ただし、送信をブロックしてはなりません。サーバーは継続的にデータを必要とします。