複数のwebsocket接続

Question

同じクライアントから同じサーバに2つのWebソケット接続を使用する利点はありますか？私にはこれは悪いデザインの選択肢だと思われますが、それがよりうまくいく理由は何ですか？

Answer 1

あなたははことをしたいかもしれないが、彼らはおそらく（少なくともまだ）あまり一般的ではない理由はいくつかあります。

• あなたが送信され、両方の暗号化と暗号化されていないデータを持っているが/ （例えば、データの一部はかさばりますが、敏感ではありません）。
• ストリーミングデータと待ち時間に敏感なデータの両方があります。インタラクティブなゲームで、ゲーム内でビデオをストリーミングすることがあります。大きなメディアストリームがレイテンシに敏感な通常のゲームメッセージの受信を遅らせることは望ましくありません。
• テキスト（JSONコントロールメッセージなど）とバイナリデータ（型付けされた配列またはBLOB）の両方があり、WebSocketsが既にこれを行っているため、独自のプロトコルレイヤーを追加して区別する必要はありません。
• サポートしている複数のWebSocketサブプロトコル（URIの後のオプション設定）があり、ページが複数のWebSocket接続にアクセスする必要があります（各WebSocket接続は1つのサブプロトコルに限定されています）。
• 同じWebサーバーとポートの背後にいくつかのWebSocketサービスがあります。クライアントが接続ごとに選択する方法は、URIパス、URIスキーム（wsまたはwss）、サブプロトコル、またはおそらくはクライアントからサーバーへの最初のメッセージにも依存します。

私には他の理由があると確信していますが、それは私が頭の上から考えることができるすべてです。

Answer 2

私は現在、同じwebsocketに2つの接続を持つソリューションを探しています。私の理由：

• 私はQUnitのテストケースを書いて、私は複数のクライアントをシミュレートし、私はそれはあなたがはるかに簡単なクライアントロジックを作ることができることを発見し、正しい応答

Answer 3

に別のクライアントを確認したいですサーバーによって管理されている特定のオブジェクトの更新にのみサブスクライブしています。単一チャネルのカスタムサブスクリプションプロトコルを考案する代わりに、各要素のソケットを開くだけで済みます。

のは、あなたがこのようなソケットのURLを使用して、単一の要素の更新情報を購読することができ

http://myserver/api/some-elements 

でREST APIを介して要素のコレクションを取得したとしましょう：コースの一つで

ws://myserver/api/some-elements/42/updates 

をこれは複雑なページのために拡大しないと主張することができます。しかし、小さく簡単なアプリケーションのために、あなたの人生をもっと楽にするかもしれません。