socket.ioで常に１つのルームに参加させ続ける方法

Question

pc向けのweb、SP向けのアプリにそれぞれwebsocket接続するアプリを作っています。

環境

socket.io用サーバー(websocketで利用)
apiサーバー（redisを利用してsocket.ioサーバーと接続している）
フロント（socket.io-client）

やりたいこと

ログインユーザーにメッセージがあったときに、pc,sp双方に対してemitしたい

現状やっている方法

• 「自分一人しか参加していないroom」を作成
• そのユーザーに対してのメッセージがあったときに、上記roomに対してemit

といったことをしています

困ったこと

原因が特定できていないのですが、websocketのコネクションは繋がっているのに、roomから離脱してしまうということがあります。
そこで、

• 定期的にroomへの参加をチェック
• 参加していない場合は参加させる

という処理をしようかと考えています。
（独自のping-pongを作成し、client側でroomに対しての参加をチェックしようかと考えました）

上記のような実装方針で考えているのですが、リクエスト数も無駄に増えるだろうし、ping-pongを独自で実装するのもあまりイケていないように感じます。
実装方針でもなんでもよいのですが、どのようにするのがベストプラクティスなのでしょうか？？

Answer 1

原因が特定できていないのですが、websocketのコネクションは繋がっているのに、roomから離脱してしまうということがあります。

対象のクライアントと接続は確立された状態のままだけど、そのクライアントがroomから予期せぬタイミングで離脱してしまうことがあるという意味ですか？

勝手に離脱が起きる原因は不明ですけど、プライベートメッセージを送るのであれば、そのクライアントのソケットIDにメッセージをemitする方法もあるので、そちらを代わりに試してみてはいかがでしょうか？

emit-cheatsheet

// sending to individual socketid (private message)
  socket.to(<socketid>).emit('hey', 'I just met you');

https://socket.io/docs/emit-cheatsheet/

Comments

[h_daido]

ご回答ありがとうございます！

最初ご提示いただいた方法も考えたのですが、
・SP、PC両方でコネクションをはっていても（同一ユーザーであれば）両方に配信したい
・PCで別タブで開いていても全タブにたいして配信したい
などの理由でユーザー単位でのroomを作成し、そこに対してemitするよにしました。

たしかにいちいちroomを作らなくても対応できればベストなのですが...。上記ケースもさらう方法はあるのdしょうか？（例えばsocketに対してuserIdを付与して、特定userIdにemit。とかできればいいと思ったんですが方法がみつからず...）

[HayatoKamono]

あ、なるほど。SP、PC両方というのはそういうことですね。ログインユーザーに対してということであれば、そのユーザーのユーザーIDにクライアントデバイスごとのsocket idを紐付けて、メッセージをemitする時はそのユーザーIDに紐付けられた全てのsocket idにemitするとかはできそうですけど。

[h_daido]

なるほど。ありがとうございます！確かにその方法ならできそうですね。
現在は、socket.ioサーバー <-> redis <-> apiサーバー　といった形でつなげているので、面倒だったためroom実装にしていましたが、redisにsocket_idとuser_idのマッピングを保持すればいけそうな気がしてきました。
認証とかめんどくさそうですが...。

[HayatoKamono]

>例えばsocketに対してuserIdを付与して
https://socket.io/docs/server-api/#server-engine-generateid
この辺りがそれかもしれません。あまりちゃんと調べていないですが。

https://stackoverflow.com/questions/7702461/socket-io-custom-client-id
あと、上記の２番めのSalvadorさんの回答とか。

[h_daido]

参考になりそうです！ありがとうございます！

[h_daido]

結局、socket.ioサーバー側にuser_idとsocket_idのmappingを保持するかたちで対応できました！スケールアウトした複数サーバーでも問題なく稼働しています。ありがとうございました。

[HayatoKamono]

おー、良かったです！

Answer 2

socket.ioを繋ぎっぱなしにする設計に無理があるんじゃないですかね？
特にスマホなら画面OFFにしたり、ブラウザをバックにする頻度は高いでしょうし、
ノートPCも何かの表紙に蓋を閉じてスリープにする頻度は高いですからね。

WebSocketのconnect / disconnectをトリガーにするのではなく、
ネットの接続を休止して当然という作りにした方が良いと思います。
WebSocketベースの運用を辞めるという感じでなんか意味あるのかわからないですけどね…
まぁ、他人のメッセージが1秒以内で瞬時に反映されるだけでも十分なメリットだと思います。

100件までメモリ空間に所持しておいて、
接続する度に全メッセージをDLさせるという設計も良いかと思います。

Comments

[h_daido]

ご回答ありがとうございます！

websocketコネクション自体は切れていても問題ない作りにはなっていて、一定時間のインターバルによるチェックの後にreconnectするようになっています。（こちらはsocket.io-clientの機能でそうしているのですが）

なんでコネクションは"常に"というわけではないですが、ベストエフォートで繋がった状態になっています。あとオフライン対応なども別途施しています。

なんですが、アプリ起動中、かつオンラインでwebsocketコネクションが繋がっているにもかかわらず、roomから出されるということがあるんですよね。。。
アプリ側はむしろ画面Offなどの動作が頻繁にあるので、その度にwebsocketコネクションが作られるので問題になりづらいのですが、PC側のほうが問題となっています。。