Xmpp Vs Websocket [zamknięte]

88

Mam zamiar stworzyć stronę internetową, która będzie miała czat w czasie niemal rzeczywistym. Wiem, że można to zaimplementować za pomocą protokołów xmpp lub websocket. Wiem też, że protokół xmpp powstał w 1999 roku i myślę, że w dzisiejszych czasach powinien być już dojrzały, z drugiej strony protokół websocket został opracowany w 2011 roku.

  1. Jaka była potrzeba Websocket, jeśli xmpp był dobry w obsłudze rozmów w czasie rzeczywistym?
  2. Jakie są główne różnice między dwoma protokołami?
  3. A kiedy powinienem wybrać jedną z nich zamiast drugiej?
java websocket xmpp real-time near-real-time Khafaga
źródło
1
Niedawno natknąłem się na ten sam problem, moją odpowiedzią było przejście na WebSockets. Node.JS staje się niezwykle popularnym językiem i zgodnie z prawem powinien nim być. XMPP jest w porządku - jednak moim zdaniem ograniczasz się do przodu, decydując się na tę starszą technologię. Node to jednak podstępna bestia i musisz podejść do niego inaczej niż do JavaScript. Jeśli jesteś wystarczająco cierpliwy, proponuję wybrać Node - nie tylko w tym celu, ale pozwoli ci to na łatwiejszą ekspansję w innych obszarach.
JustSteveKing
7
XMPP to Extensible Messaging and Presence Protocol, a Websocket to protokół zapewniający komunikację w trybie pełnego dupleksu przez port 80. Porównujesz jabłka do pomarańczy.
Flow
16
@Flow: Moim zdaniem mogę porównywać jabłka do pomarańczy. Ale pytam, co powinienem wybrać przy tworzeniu strony internetowej, która umożliwia czat w czasie rzeczywistym.
Khafaga
1
@JustSteveKing Większość rzeczy jest już zrobiona w XMPP, jednak musisz nimi zarządzać w node.js. Jest to równoznaczne z ponownym wynalezieniem koła.
Shahid Karimi

Odpowiedzi:

133

Krótka odpowiedź brzmi: „oba”.

XMPP to zestaw protokołów aplikacji do prowadzenia rozmów w czasie rzeczywistym (i wielu innych rzeczy, jeśli o to chodzi) - następnie musi zostać w jakiś sposób przesłany przez sieć, więc potrzebujesz powiązania transportowego. Istnieją trzy główne powiązania transportowe dla XMPP -

  1. TCP / IP, którego zwykle używa się w Internecie z natywnymi klientami na urządzeniach
  2. HTTP (zwany BOSH), który jest tradycyjnie używany podczas korzystania z XMPP w przeglądarce (ponieważ protokół TCP-IP nie jest dostępny dla aplikacji Javascript w przeglądarce)
  3. Websockets, których używa się podczas robienia XMPP w nowoczesnej przeglądarce.

Więc jeśli tworzysz aplikację do czatu w przeglądarce, wybierz XMPP jako protokół aplikacji i użyjesz websockets (w nowoczesnej przeglądarce) lub BOSH (w starszej przeglądarce) jako transportu sieciowego. Jeśli używasz biblioteki XMPP dla Javascript, takiej jak Stanza.io ( https://github.com/otalk/stanza.io ), będzie ona obsługiwać obie i będziesz po prostu myśleć o `` XMPP '', a nie o warstwie transportowej, inaczej niż podczas konfiguracji, kiedy musisz powiedzieć mu, z którym punktem końcowym ma się połączyć.

(Nie możesz używać `` tylko gniazd sieciowych '' do czatu - możesz używać gniazd internetowych bez XMPP, ale to naprawdę oznacza, że ​​wymyślasz własny protokół warstwy aplikacji do czatu, a szanse, które zamierzasz zaoszczędzić dużo czasu i bólów głowy, wykorzystując pracę, która już została włożona w napisanie takiej, która ma przydatne właściwości (bezpieczeństwo, tożsamość, rozszerzalność itp.) i dla której istnieją istniejące biblioteki i serwery, zamiast tego przechodząc na XMPP.

Kev
źródło
1
Cześć, przepraszam, pytania minęło trochę czasu, po prostu się zastanawiam, więc czy to oznacza, że ​​transportowanie powiązania jest podobne do socket.io/strophe.js, a xmpp jest podobne do (openfire / Ejabbered)?
Jan
1
Nie, to, co nazywasz, to biblioteki i serwery.
Kev,
Tutaj jest więcej o warstwach (w tym transport, warstwy aplikacji): en.wikipedia.org/wiki/OSI_model
Karina Klinkevičiūtė
2
dobra odpowiedź od Keva, ale warto zaznaczyć, że 1> TCP należy do warstwy 4 - warstwy transportowej, podczas gdy HTTP i Websocket należą do warstwy 7 - warstwy aplikacji.
Gob00st
Rzeczywiście @ Gob00st - tutaj też jestem zdezorientowany. Ta odpowiedź od Keva mówi „jedno i drugie”, ponieważ „używałbyś gniazd sieciowych (w nowoczesnej przeglądarce)… jako transportu sieciowego ” . Ale jak to pogodzić z faktem, że WebSocket (tak jak XMPP i HTTP) są w rzeczywistości protokołami aplikacji (a nie transportowymi) w np. Warstwie 7 OSI? Dlaczego XMPP miałby być „na wierzchu” WebSockets w nowoczesnej przeglądarce?
Amelio Vazquez-Reina