Faye vs. Socket.IO (i Juggernaut)

Question

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

jest również popularny i aktywny, ma własną bibliotekę javascript, dzięki czemu jego pełna funkcjonalność jest porównywalna z Juggernaut. Juggernaut używa węzła dla swojego serwera, a Faye może używać węzła lub stojaka. Juggernaut używa Redis do utrzymywania (korekta: używa Redis dla pub/sub), a Faye tylko utrzymuje stan w pamięci.

1. Czy wszystko jest powyżej dokładności?
2. Faye mówi realizuje Bayeux - myślę Juggernaut nie robi tego - jest to, że ponieważ Juggernaut jest niższy poziom (IE, można zaimplementować Bayeux za pomocą Juggernaut)
3. Could przełącznik Faye do korzystania z przeglądarki Socket.IO javascript biblioteka, jeśli chce? Czy ich biblioteki javascript robią zasadniczo różne rzeczy?
4. Czy istnieją inne różnice architektoniczne/projektowe/filozoficzne między projektami?

Answer 1

Ujawnienie: Jestem autorem Faye.

1. Jeśli chodzi o Faye, wszystko, co powiedziałeś, jest prawdą.
2. Faye wdraża większość Bayeux, jedyne, czego brakuje teraz to kanały serwisowe, których jeszcze nie przekonałem o przydatności. W szczególności Faye ma być kompatybilny z implementacją referencyjną CometD dla Bayeux, która ma duże znaczenie dla następujących elementów.
3. Koncepcyjnie, tak: Faye może użyć Socket.IO. W praktyce istnieją pewne bariery:
   • Nie mam pojęcia, jaki rodzaj wsparcia po stronie serwera.IO wymaga, a wymóg, aby klient Faye (są klienci po stronie serwera w Node i Ruby, pamiętajcie) móc rozmawiać z dowolnym serwerem Bayeux (a serwerem Faye do dowolnego klienta Bayeux) może być deal-breaker.
   • Bayeux ma określone wymagania, które serwery i klienci obsługują określone typy transportu, i mówi, jak wynegocjować, 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 sposób interpretowania jego treści.
   • W przypadku niektórych rodzajów obsługi błędów potrzebuję bezpośredniego dostępu do transportu, na przykład resending messages when a client reconnects after a Node WebSocket dies.
   • Proszę, popraw mnie, jeśli coś jest nie tak - jest to oparte na pobieżnym skanie dokumentacji Socket.IO.
4. Faye jest tylko pub/sub, to jest po prostu opiera się na nieco bardziej skomplikowanym protokołem i ma dużo subtelności zbudowanych w:
   • server- i po stronie klienta rozszerzeń
   • Wildcard wzór dopasowywania na trasach kanałowych
   • Automatyczne ponowne połączenie, np. kiedy WebSockets umrzeć lub serwer rozłącza
   • Klient działa we wszystkich przeglądarkach, na telefonach i server-side na węźle i Ruby

Faye prawdopodobnie wygląda o wiele bardziej skomplikowane w porównaniu do Juggernaut ponieważ Juggernaut deleguje więcej, np deleguje negocjacje dotyczące transportu na Socket.IO i przekazywanie wiadomości do Redis. Są to zarówno dobre decyzje, ale moja decyzja o użyciu Bayeux oznacza, że ​​muszę sam wykonać więcej pracy.

Co do filozofii projektowania, nadrzędnym celem Faye jest to, aby działał wszędzie tam, gdzie jest dostępna sieć i powinien być absolutnie banalny, aby zacząć działać. Zwykle nie jest to łatwe, ale jego rozciągliwość oznacza, że ​​można go dostosowywać w dość potężny sposób, na przykład można go przekształcić w usługę push do serwera (tj. Zatrzymanie dowolnych klientów) poprzez dodanie rozszerzeń uwierzytelniania .

Trwają również prace nad zwiększeniem elastyczności po stronie serwera. Zastanawiam się nad dodaniem obsługi klastrów i włączeniem głównego silnika pub-sub, aby można było używać Faye jako bezstanowego interfejsu sieciowego dla innego systemu sub-pub, takiego jak Redis lub AMQP.

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

Answer 2

Faye z pewnością mógł. Innym przykładem podobnego projektu na szczycie Socket.IO:

https://github.com/aaronblohowiak/Push-It

Answer 3

1. AFAIK, tak, niezależnie od faktu, Juggernaut używa tylko Redis dla PubSub, nie upór. Oznacza to również, że biblioteki klienckie w większości języków zostały już napisane (ponieważ potrzebuje tylko adaptera Redis).
2. Juggernaut nie implementuje Bayeux, ale raczej ma bardzo prosty zwyczaj protokołu JSON
3. wiem, prawdopodobnie
4. Juggernaut jest bardzo prosta, a zaprojektowany tak być. Chociaż nie używałem Faye, z dokumentów wygląda na to, że ma o wiele więcej funkcji niż tylko PubSub. Wbudowany na Socket.IO ma również swoje zalety, Juggernaut jest obsługiwany praktycznie w każdej przeglądarce, zarówno na komputerze stacjonarnym, jak i mobilnym.

Będę naprawdę zainteresowany tym, co autor Faye ma do powiedzenia. Jak już mówiłem, nie użyłem go i byłoby wspaniale wiedzieć, jak to się ma do Juggernaut. To prawdopodobnie przypadek użycia najlepszego narzędzia do pracy. Jeśli potrzebujesz pubsub, Juggernaut robi to bardzo dobrze.