Faye kontra Socket.IO (i Juggernaut)

102

Socket.IO wydaje się być najpopularniejszą i najbardziej aktywną biblioteką emulacji WebSocket. Juggernaut używa go do stworzenia kompletnego systemu pub / sub.

Faye jest również popularna i aktywna i ma własną bibliotekę javascript, dzięki czemu jej pełna funkcjonalność jest porównywalna z Juggernaut. Juggernaut używa węzła jako swojego serwera, a Faye może używać węzła lub szafy. Juggernaut używa Redis do trwałości ( poprawka: używa Redis dla pub / sub), a Faye przechowuje tylko stan w pamięci.

  1. Czy wszystko powyżej jest dokładne?
  2. Faye mówi, że implementuje Bayeux - myślę, że Juggernaut tego nie robi - to dlatego, że Juggernaut jest niższy poziom (IE, mogę zaimplementować Bayeux za pomocą Juggernaut)
  3. Czy Faye mogłaby przełączyć się na korzystanie z biblioteki javascript przeglądarki Socket.IO, gdyby chciała? A może ich biblioteki javascript robią zasadniczo różne rzeczy?
  4. Czy są jakieś inne różnice architektoniczne / projektowe / filozoficzne między projektami?
John Bachir
źródło
3
Na wszelki wypadek Juggernaut został wycofany! Przeczytaj, dlaczego blog.alexmaccaw.com/killing-a-library .
Maziyar
Zdarzenia
wysyłane przez

Odpowiedzi:

121

Ujawnienie: jestem autorem Faye.

  1. Jeśli chodzi o Faye, wszystko, co powiedziałeś, jest prawdą.
  2. Faye implementuje większość Bayeux, jedyne, czego w tej chwili brakuje, to kanały serwisowe, o których użyteczności nie byłem jeszcze przekonany. W szczególności Faye została zaprojektowana tak, aby była kompatybilna z referencyjną implementacją CometD firmy Bayeux, która ma duży wpływ na następujące kwestie.
  3. Koncepcyjnie tak: Faye mogłaby użyć Socket.IO. W praktyce istnieją pewne bariery:
    • Nie mam pojęcia, jakiego rodzaju obsługi po stronie serwera wymaga Socket.IO i jaki jest warunek, aby klient Faye (pamiętajcie, że są klienci po stronie serwera w Node i Ruby) może komunikować się z dowolnym serwerem Bayeux (i Faye serwer do dowolnego klienta Bayeux) może być przyczyną zerwania transakcji.
    • Bayeux ma określone wymagania, zgodnie z którymi serwery i klienci obsługują określone typy transportu, i mówi, jak negocjować, którego użyć. Określa również, w jaki sposób są one używane, na przykład w jaki sposób typ zawartości żądania XHR wpływa na interpretację jego treści.
    • W przypadku niektórych typów obsługi błędów potrzebuję bezpośredniego dostępu do transportu, na przykład ponownego wysyłania wiadomości, gdy klient łączy się ponownie po śmierci Node WebSocket .
    • Proszę mnie poprawić, jeśli coś z tego wynikło z błędu - jest to oparte na pobieżnym skanie dokumentacji Socket.IO.
  4. Faye to po prostu pub / sub, jest po prostu oparty na nieco bardziej złożonym protokole i ma wiele wbudowanych dodatków:
    • Rozszerzenia po stronie serwera i klienta
    • Dopasowywanie wzorców symboli wieloznacznych na trasach kanałów
    • Automatyczne ponowne połączenie, np. Gdy WebSockets umrze lub serwer przejdzie w tryb offline
    • Klient działa we wszystkich przeglądarkach, na telefonach oraz po stronie serwera na Node i Ruby

Faye prawdopodobnie wygląda na dużo bardziej złożoną w porównaniu do Juggernaut, ponieważ Juggernaut deleguje więcej, np. Deleguje negocjacje transportu do Socket.IO i routing wiadomości do Redis. Obie są dobre, ale moja decyzja o użyciu Bayeux oznacza, że ​​muszę sam wykonać więcej pracy.

Jeśli chodzi o filozofię projektowania, nadrzędnym celem Faye jest to, że powinno działać wszędzie tam, gdzie jest dostępna sieć, i powinno być absolutnie trywialne. Nie jest naprawdę łatwy do rozpoczęcia, ale jego rozszerzalność oznacza, że ​​można go dostosować na dość potężne sposoby, na przykład można przekształcić go w usługę wypychania serwera do klienta (tj. Zatrzymać wysyłanie do niego dowolnych klientów), dodając rozszerzenia uwierzytelniania .

Trwają również prace nad uczynieniem go bardziej elastycznym po stronie serwera. Chcę dodać obsługę klastrowania i umożliwić podłączenie podstawowego silnika pub-sub, abyś mógł używać Faye jako bezstanowej nakładki internetowej dla innego systemu pub-sub, takiego jak Redis lub AMQP.

Mam nadzieję, że to było pomocne.

jcoglan
źródło
1
Dzięki za świetną odpowiedź. Nie zdawałem sobie sprawy z elastyczności protokołu Bayeux - więc dowolny klient powinien móc rozmawiać z dowolnym / wieloma serwerami? Czy znasz jakieś projekty lub usługi produkcyjne, które w pełni to wykorzystują?
John Bachir,
4
Niedawno przeniosłem się z Socket.IO na Faye i muszę powiedzieć, że Faye uratowała moją aplikację. Dzięki prostemu serwerowi Faye i średniemu serwerowi moja aplikacja może obsłużyć 6000 użytkowników jednocześnie, zgodnie z Google Analytics
Tan Nguyen
13
  1. AFAIK, tak, poza tym, że Juggernaut używa Redis tylko dla Pubsub, a nie wytrwałości. Oznacza również, że biblioteki klienckie w większości języków zostały już napisane (ponieważ potrzebny jest tylko adapter Redis).
  2. Juggernaut nie implementuje Bayeux, ale ma bardzo prosty niestandardowy protokół JSON
  3. Nie wiem, prawdopodobnie
  4. Juggernaut jest bardzo prosty i tak zaprojektowany. Chociaż nie używałem Faye, z dokumentów wygląda na to, że ma o wiele więcej funkcji niż tylko PubSub. Zbudowany na podstawie Socket.IO ma również swoje zalety, Juggernaut obsługuje praktycznie każdą przeglądarkę, zarówno stacjonarną, jak i mobilną.

Bardzo mnie zainteresuje, co ma do powiedzenia autorka Faye. Jak mówię, nie korzystałem z niego i byłoby wspaniale wiedzieć, jak wypada na tle Juggernauta. Prawdopodobnie jest to przypadek użycia najlepszego narzędzia do pracy. Jeśli potrzebujesz pubu, Juggernaut robi to bardzo dobrze.

Alex MacCaw
źródło
Dzięki za świetną odpowiedź. Nie zdawałem sobie sprawy, że Redis był używany tylko do funkcji pub / sub. Sprawił, że zapytałem: stackoverflow.com/questions/4938520
John Bachir,