はじめに
Engine.IOのGoalsにWebSocketとロングポーリングの切り替え方式をSocket.IO 0.9から変更するという話が書いてあって、興味深かったのでメモしておきます。
その前に前提知識のメモ。
- Engine.IOはSocket.IOと同じ作者が作っている。githubアカウントは https://github.com/LearnBoost
- 今後リリース予定のSocket.IO 1.0はEngine.IOを利用するようになる。
- Engine.IOは基本機能を提供して、Socket.IOはエラー時に再接続したり、multiplexingしたり実際にアプリケーションに必要な基本的な機能が含まれている。Can I use engine without Socket.IO ?参照。
WebSocketとロングポーリングの切り替え方式がSocket.IO 1.0では変わる
- Socket.IO 0.9はダウングレード方式。まずWebSocketかFlash Socketを試して、だめならロングポーリングに切り替える。
- Engine.IOとSocket.IO 1.0はアップグレード方式。まずロングポーリングで接続して、その後WebSocketかFlash Socketが使えるなら切り替える。
現状では、多くの企業のファイアウォールでWebSocketがブロックされていたり、アンチウィルスソフトでブロックされたりとWebSocketが使えないケースが多々あるとのことです。ダウングレード方式だと最初にWebScoketを試して、使えないと判定するまでに10秒程度かかってしまうのでユーザ体験として良くないと。
それよりはまず確実に接続できるロングポーリングで一旦接続して、その後WebSocketが使えると判明したらアップグレードするほうが良いという判断だそうです。
Node.JSのWebSocket実装の比較記事
あと、Finding the right Node.JS WebSocket implementation — Node.js & JavaScript — Mediumの記事も非常に詳しくて有用でした。
他の言語のWebSocketライブラリもロングポーリングとの切り替えまで面倒見てくれるようになるといいなー
軽く検索した程度なので知らないだけかもしれませんが、rubyとかgoだとWebSocketのライブラリはあるみたいですけど、ロングポーリングとの切り替えまで面倒見てくれるのはまだなさそうです。
Socket.IO 1.0が出てアップグレード方式が良いねという認識が広まって、他の言語でもそういうライブラリが増えるといいなーと思いました。