2017-06-01 4 views
0

ユーザーの最後のウィンドウまたはタブが閉じられていることを検出する方法を見つけようとしています。私はそれが実際にユーザーのための最後の接続であることを検出する方法を見つけることができないようです。私は自分のチャンネルへの接続を追跡するモデルを持っており、他のアクティブなタブが接続で開いている場合に切断するときにユーザーの接続レコードを削除したくありません。最後のウィンドウの検出/ Tab ActionCableで閉じる

だから、それぞれの接続をチェックして、同じ識別子を持つ他のアクティブな接続であるかどうかを確認する必要があります。

私は、切断メソッドでRemoteConnectionsのチェックを設定しようとしました。しかし、それが呼び出されると、閉じている接続がRemoteConnectionsの下で返されているように思えます。

module ApplicationCable 
    class Connection < ActionCable::Connection::Base 
    identified_by :current_user 

    def connect 
     self.current_user = find_verified_user 
     logger.add_tags 'ActionCable', current_user.username 
     logger.debug self.current_user.username + " now connected." 
    end 

    def disconnect 
     self.close() 
     logger.debug ActionCable.server.remote_connections.where(current_user: current_user) 
     logger.debug ActionCable.server.remote_connections.where(current_user: current_user).identifiers 
     logger.debug ActionCable.server.remote_connections.where(current_user: current_user).identifiers.inspect() 
    end 
end 

このセットアップは、その識別子を使用して、最後の接続が閉じている場合でも、次の値を返します。

[ActionCable] [[email protected]] UserChannel stopped streaming from user:Z2lkOi8vYWxseWNoYXQvVXNlci80Nw 
[ActionCable] [[email protected]] #<ActionCable::RemoteConnections::RemoteConnection:0x00000007062690> 
[ActionCable] [[email protected]] #<Set:0x00000007791b78> 
[ActionCable] [[email protected]] #<Set: {:current_user}> 

私はちょうど彼らとの接続を追跡するためのモデルを設定することにより、これまでに対処してきました各チャンネルごとに開閉します。しかし、オーバーヘッドが増え、管理が面倒です。

誰でもこれを管理する方法を提案できますか?私はActionCableのAPIドキュメントを精査していて、空になっています。

答えて

0

誰にとってもうまくいかないかもしれない解決策を見つけましたが、これは答えがないために開いているいくつかの質問なので、私が結んだことを投稿したいと思っていました。

アクティブな接続をカウントするためにケーブルサーバーに問い合わせる考えを放棄しました。これが現在可能な場合、私は明らかに答えを見つけるほど賢明ではない。

アクティブなレコードを使用してアクティブな接続をカウントし、それらを識別するためにGIDSを格納し、最後の接続が閉じたときにクリーンアップを行うことも実験しました。それは機能しました...しかし、私はファンではありません、それは追加のクエリ、サブスクリプションを追跡するための新しいモデル、クリーンアップ作業のタイミングの周りの多くの感度を追加しました。可能ですが、醜いです。

代わりに、私は「マスター」と「スレーブ」の接続と、ユーザーの認証による追加のUserChannelという概念を採用しました。基本的に、最初のサブスクリプションを開始する接続は(私の場合はチャットルームへの)「マスター」接続になります。マスターが参加すると、UserChannelを介して同じユーザーとして認証された他のすべてのアクティブなウィンドウ/タブに通知をブロードキャストします。このブロードキャストを受信するものは、別々のペアのスレーブチャネルで接続を設定することによって、マスター接続に従います。 「マスター」接続は、それ自身の「スレーブ」接続も設定します。

は、したがって、各チャットルームのために私は2つのチャンネルを維持する:それはのためのすべてのセッションに利用可能であるため、#奴隷、ルーム #_master

room_チャットルームの活動のためのすべての放送は「スレーブ」チャンネル(上起こります1つのウィンドウ/タブのみがマスタにサブスクライブされます)。新しいメッセージ、ユーザー出口、入り口などがここで放送されます。

「マスター」チャンネルは、セットアップとティアダウンを処理するためにのみ存在します。ユーザが参加すると、マスタチャネルの「サブスクライブ」メソッドは、そのユーザのエントリを「スレーブ」チャネルを介して他のユーザにブロードキャストする。

マスター接続が終了すると、「アンサブスクライブ」メソッドは終了をブロードキャストし、アクティブなレコードクリーンアップを処理し、そのユーザーがサスペンド状態に入るためのすべてのスレーブ接続にメッセージをブロードキャストします。その後、スレーブは(ユーザーの操作で)新しいマスター接続になるようにオプトインできます。この場合、接続が復元されます。

これは私が見つけることができる最高のバランスでした。 ActiveRecordに関する限り、1つのウィンドウ/タブで接続数がカウントされます。そのウィンドウが閉じている場合、ユーザーは「left」を持っています。ただし、スレーブチャンネルでは、送信されたすべてのブロードキャストを監視するため、すべてのユーザーのブラウザウィンドウ/タブに共通の状態を維持できます。ユーザーが「マスター」接続を誤って閉じると、簡単に再結合することができます。

関連する問題