Websockets を使用して、Go で記述されたサーバーから HTML ページであるクライアントにビデオ画像を転送しています。以下で共有する私の経験は、Chrome を使用したものです。
websocket の onmessage ハンドラを介して画像を受け取ります。画像を受信したら、画像を表示する前に、いくつかのタスクを非同期で完了する必要がある場合があります。これらのタスクが完了していなくても、さらに別の onmessage() が起動する場合があります。この時点では、サーバーの処理速度ほど速く処理を進めることができず、古い画像を表示しても意味がないため、画像をキューに入れたくありません。また、これらの画像をドロップしたくありません。まったく受信したくありません。
クライアントが従来の TCP 接続を使用すると、接続からの読み取りが停止するだけです。これにより、受信バッファがいっぱいになり、受信ウィンドウが閉じられ、最終的にサーバーでの画像の送信が一時停止します。クライアントが読み取りを開始するとすぐに、受信バッファーが空になり、受信ウィンドウが開き、サーバーが送信を再開します。サーバーが画像の送信を開始するたびに、最新の画像が選択されます。この最新の動作は、TCP のフロー制御と相まって、多くの場合に妥当な動作を保証します。
Websocket のベースとなっている TCP のフロー制御機能を Websocket で使用することは可能ですか? 私は特に、TCP のフロー制御に依存し、アプリケーション レベルのフロー制御に依存しないソリューションに関心があります。