3

Chrome 送信者と ChromeCast の間で正常に接続されているため、両者の間でメッセージを適切に送受信できますが、送信者が接続するたびに、セッション変数であると推測されるものを増やしながら新しい接続を作成します: ws ://localhost:8008/session?x 、ここで x は増加する数値です。

私は2つのことを知りたいです:

  1. 接続ごとにセッション変数をインクリメントするのはなぜですか? 設計によるものですか?または、接続を適切に閉じることができませんか? 私が見ることができることから、接続はデフォルトでクローズイベントを送信しますが、間違っている可能性があります。

  2. セッションが意図的に更新された場合、以前のセッションを検出し、一方がまだアクティブな場合にそれらに接続する方法はありますか?

編集: Chrome 送信 API が Android TicTacToe デモ アプリケーションで説明されている複数の接続シナリオをサポートしていないことは理解していますが、質問の目的は、この「セッション」変数が特定のポイントまでインクリメントされると、YouTube などの他のアプリケーションになるためです。 Android アプリは、WebSocket 接続の遅延が原因と思われる不規則な実行を開始します。この接続が増加している理由を知りたいです。私のテストでは、これは純粋に設計によるものであり、各クライアントが ChromeCast への一意の接続を取得するようにする可能性があります (つまり、以下に示す複数のコントローラーのシナリオを防ぐため)。

4

1 に答える 1

1

現在の Chrome API は、既存の接続の再利用をサポートしていません (このようなシナリオをサポートしている Android API とは異なります)。これは既知の制限であり、将来的に対処される予定です。

HTH、アリ。

于 2013-10-01T14:33:25.843 に答える