[解決済み] Faye vs. Socket.IO (とJuggernaut)

1. Fayeについて、あなたが言ったことはすべて真実です。
2. FayeはBayeuxのほとんどを実装しています。今足りないのはサービスチャンネルだけで、その有用性についてはまだ納得していません。特に Faye は、Bayeux の CometD リファレンス実装と互換性があるように設計されており、これは以下に大きく関係しています。
3. 概念的にはそうです: Faye は は Socket.IO を使用できます。実際には、これにはいくつかの障壁があります。
   • Socket.IOがどのようなサーバーサイドのサポートを必要とするのか見当もつきませんし、Fayeクライアント（NodeとRubyにはサーバーサイドクライアントがありますね）が任意のBayeuxサーバーと（そしてFayeサーバーが任意のBayeuxクライアントと）対話できることが必要ですが、これは破たんするかもしれません。
   • Bayeuxは、サーバーとクライアントが特定のトランスポートタイプをサポートするという特定の要件を持ち、どれを使うかをネゴシエートする方法を述べています。また、例えば XHR リクエストの Content-Type がそのコンテンツの解釈にどのように影響するかなど、それらがどのように使用されるかを明記しています。
   • ある種のエラー処理のために、トランスポートに直接アクセスする必要があります。 Node WebSocket が終了した後にクライアントが再接続したときにメッセージを再送信する。 .
   • これは、Socket.IO のドキュメントをざっと読んだだけですが、間違っているところがあれば訂正してください。
4. Faye は単なる pub/sub で、少し複雑なプロトコルをベースにしており、多くの巧妙な機能が組み込まれています。
   • サーバーおよびクライアントサイドの拡張機能
   • チャネルルートでのワイルドカードパターンマッチング
   • WebSocket が停止したときやサーバーがオフラインになったときなどの自動再接続
   • クライアントはすべてのブラウザ、携帯電話、サーバーサイドはNodeとRubyで動作します。

JuggernautはトランスポートネゴシエーションをSocket.IOに、メッセージルーティングをRedisに委ねるなど、より多くの委譲を行うため、Juggernautと比較するとFayeはおそらくより複雑に見えるでしょう。これらは両方とも良い決断ですが、Bayeuxを使うという私の決断は、私自身がより多くの作業をしなければならないことを意味します。

設計思想としては、Fayeの最優先目標は、Webが利用可能な場所ならどこでも動作することであり、絶対に簡単に始められるものでなければなりません。たとえば、認証の拡張機能を追加することで、サーバーからクライアントへのプッシュ サービスに変えることができます (つまり、任意のクライアントからのプッシュを停止させることができます)。

また、サーバー側でより柔軟にするための作業も進行中です。クラスタリングのサポートを追加したり、コアなPub-Subエンジンをプラグイン可能にしたりして、FayeをRedisやAMQPといった別のPub-Subシステム用のステートレスWebフロントエンドとして使えるようにしようと思っています。

お役に立ったでしょうか？