2011-02-04 5 views
98

Socket.IO sembra essere la libreria di emulazione WebSocket più popolare e attiva. Juggernaut lo utilizza per creare un sistema pub/sub completo.Faye vs. Socket.IO (e Juggernaut)

Faye è anche popolare e attivo e dispone di una propria libreria javascript che rende la sua completa funzionalità paragonabile a Juggernaut. Juggernaut usa il nodo per il suo server e Faye può usare sia il nodo che il rack. Juggernaut utilizza Redis per la persistenza (correzione : utilizza Redis per pub/sub) e Faye mantiene solo lo stato in memoria.

  1. È tutto sopra preciso?
  2. Faye dice che implementa Bayeux - penso Juggernaut non lo fa - è che, poiché Juggernaut è di livello inferiore (IE, posso realizzare Bayeux utilizzando Juggernaut)
  3. potrebbero passare Faye a utilizzare il browser Socket.IO javascript biblioteca se lo volesse? O le loro librerie javascript fanno cose fondamentalmente diverse?
  4. Ci sono altre differenze di architettura/design/filosofia tra i progetti?
+3

Nel caso in cui, Juggernaut è stato deprecato! Leggi perché http://blog.alexmaccaw.com/killing-a-library. – Maziyar

+0

HTML 5 Gli eventi inviati dal server sembrano essere l'alternativa consigliata in base all'autore di Juggernaut – Harindaka

risposta

117

Disclosure: Sono l'autore di Faye.

  1. Per quanto riguarda Faye, tutto ciò che hai detto è vero.
  2. Faye implementa la maggior parte di Bayeux, l'unica cosa che manca adesso sono i canali di servizio, di cui devo ancora essere convinto dell'utilità di. In particolare, Faye è progettato per essere compatibile con l'implementazione di riferimento CometD di Bayeux, che ha una grande influenza sui seguenti.
  3. Concettualmente, sì: Faye potrebbe utilizzare Socket.IO. In pratica, ci sono alcuni ostacoli a questo:
    • Non ho idea di quale tipo di supporto Socket lato server.L'IO richiede, e il requisito che il client Faye (ci sono client lato server in Node e Ruby, ricorda) sia in grado di parlare con qualsiasi server Bayeux (e il server Faye a qualsiasi client Bayeux) potrebbe essere un break-off.
    • Bayeux ha requisiti specifici che server e client supportano determinati tipi di trasporto e dice come negoziare quale utilizzare. Specifica anche come vengono utilizzati, ad esempio come il Content-Type di una richiesta XHR influisce sul modo in cui il suo contenuto viene interpretato.
    • Per alcuni tipi di gestione degli errori, è necessario l'accesso diretto al trasporto, ad esempio resending messages when a client reconnects after a Node WebSocket dies.
    • Per favore correggimi se ho qualcosa di sbagliato - questo si basa su una scansione superficiale della documentazione Socket.IO.
  4. Faye è solo pub/sub, è solo sulla base di un protocollo leggermente più complesso e ha un sacco di sottigliezze costruito in:
    • server e lato client estensioni
    • jolly pattern-matching sulle linee del canale
    • Riconnessione automatica, ad es. quando WebSockets muoiono o il server va offline
    • Il client funziona in tutti i browser, sui telefoni e server-side sul nodo e Ruby

Faye probabilmente sembra molto più complessa rispetto a Juggernaut perché Juggernaut delega di più, ad es delega la negoziazione dei trasporti a Socket.IO e il routing dei messaggi a Redis. Queste sono entrambe ottime decisioni, ma la mia decisione di usare Bayeux significa che devo fare più lavoro da solo.

Per quanto riguarda la filosofia del design, l'obiettivo principale di Faye è che dovrebbe funzionare ovunque il Web sia disponibile e dovrebbe essere assolutamente banale per andare avanti. È molto semplice iniziare, ma la sua estensibilità significa che può essere personalizzato in modi abbastanza potenti, ad esempio è possibile trasformarlo in un servizio push da server a client (ovvero arrestare i client arbitrari che lo spingono) aggiungendo estensioni di autenticazione .

C'è anche del lavoro in corso per renderlo più flessibile sul lato server. Sto cercando di aggiungere il supporto per il clustering e rendere il core pub-sub plug-in in modo da poter utilizzare Faye come front-end Web senza stato per un altro sub-pub come Redis o AMQP.

Spero che questo sia stato utile.

+1

Grazie per l'ottima risposta. Non avevo realizzato la flessibilità del protocollo Bayeux, quindi un client arbitrario dovrebbe essere in grado di parlare con server arbitrari/multipli? Conoscete eventuali progetti o servizi di produzione che ne traggono pienamente vantaggio? –

+4

Recentemente sono passato da Socket.IO a Faye e devo dire che Faye ha salvato la mia domanda. Con un semplice server Faye e un server medio, la mia applicazione può gestire 6000 utenti contemporaneamente secondo google analytics –

13
  1. per quanto ne so, sì, a parte il fatto Juggernaut utilizza solo Redis per PubSub, non è la persistenza. Significa anche che le librerie client nella maggior parte delle lingue sono già state scritte (poiché richiede solo un adattatore Redis).
  2. Juggernaut non implementare Bayeux, ma piuttosto ha una molto semplice, personalizzata JSON protocollo
  3. Boh, probabilmente
  4. Juggernaut è molto semplice, e progettato per essere in quel modo. Anche se non ho usato Faye, dai documenti sembra che abbia molte più funzionalità di PubSub. Essendo costruito su Socket.IO ha anche dei vantaggi, Juggernaut è supportato praticamente in ogni browser, sia desktop che mobile.

Sarò davvero interessato a ciò che l'autore di Faye ha da dire. Come ho detto, non l'ho usato e sarebbe bello sapere come si paragona a Juggernaut. Probabilmente è il caso di utilizzare lo strumento migliore per il lavoro. Se è necessario pubub, Juggernaut lo fa molto bene.

+0

Grazie per l'ottima risposta. Non mi rendevo conto che Redis era usato solo per le sue caratteristiche di pubblicazione/sub. Mi ha fatto chiedere questo: http://stackoverflow.com/questions/4938520 –