11

Websockets を使用して、Go で記述されたサーバーから HTML ページであるクライアントにビデオ画像を転送しています。以下で共有する私の経験は、Chrome を使用したものです。

websocket の onmessage ハンドラを介して画像を受け取ります。画像を受信したら、画像を表示する前に、いくつかのタスクを非同期で完了する必要がある場合があります。これらのタスクが完了していなくても、さらに別の onmessage() が起動する場合があります。この時点では、サーバーの処理速度ほど速く処理を進めることができず、古い画像を表示しても意味がないため、画像をキューに入れたくありません。また、これらの画像をドロップしたくありません。まったく受信したくありません。

クライアントが従来の TCP 接続を使用すると、接続からの読み取りが停止するだけです。これにより、受信バッファがいっぱいになり、受信ウィンドウが閉じられ、最終的にサーバーでの画像の送信が一時停止します。クライアントが読み取りを開始するとすぐに、受信バッファーが空になり、受信ウィンドウが開き、サーバーが送信を再開します。サーバーが画像の送信を開始するたびに、最新の画像が選択されます。この最新の動作は、TCP のフロー制御と相まって、多くの場合に妥当な動作を保証します。

Websocket のベースとなっている TCP のフロー制御機能を Websocket で使用することは可能ですか? 私は特に、TCP のフロー制御に依存し、アプリケーション レベルのフロー制御に依存しないソリューションに関心があります。

4

3 に答える 3

5

あなたが求めていることが可能であるとは思えません。WebSocket API 仕様には、その機能のインターフェースはありません。ただし、仕様で概説されているのは、スクリプトが WebSocket アクションによってブロックされないように、基になるソケット接続が WebSocket を使用しているスクリプトの外部のバックグラウンドで管理されるという要件です。ソケットが受信データを受信すると、データをメッセージ内にラップし、WebSocket スクリプトが処理できるようにキューに入れます。スクリプトがメッセージを処理するのを待っているメッセージがキューに残っている間、ソケットがそれ以上のデータを読み取ることをブロックするものは何もありません。

WebSocket で実装できる唯一の実際のフロー制御は、明示的なものです。メッセージが到着したら、メッセージを返信して確認します。次のメッセージを送信する前に、サーバーがその ack を受信するまで待機するようにします。

于 2013-10-16T22:20:28.283 に答える