XMPP oder Websocket

BTCStorage

Ensign
Registriert
Mai 2020
Beiträge
175
Hallo,

wenn ich ein Realtime Chat bauen will wo zwei Leute gleichzeitig chatten und die Nachrichten sollen zeitgleich fuer beide sichtbar werden, welche Technik ist da besser geeignet XMPP oder Websockets oder was ganz anderes?

wenn ich ein Besucherzaehler bauen will, wo Leute zeitgleich sehen sollen wenn neue Besucher auf die Seite gekommen sind, welche Technik benutzt man dann am besten XMPP oder Websockets oder was ganz anderes?

Ich will mir gerne verschiedene Meinungen anhoeren und kucken ob ich was dazu lerne, im Prinzip weis ich das es mit beiden Techniken moeglich sein wird, aber vielleicht hat ja eine Technik besondere Vorteile.
 
XMPP (über HTTP) kann man für sowas nutzen, ist aber unnötig kompliziert.

Websockets sind zu Zeiten von HTTP2 veraltet.

Am einfachsten ist, Nachrichten vom Browser aus einfach wie gewohnt per HTTP POST zu senden und die andere Richtung per Server-Sent Events (SSE) zu machen. Das geht auch sauber per HTTP2, ist ganz simpel zu programmieren und macht weniger Probleme als Websockets. Google weiß mehr dazu.
 
GrumpyCat schrieb:
Am einfachsten ist, Nachrichten vom Browser aus einfach wie gewohnt per HTTP POST zu senden und die andere Richtung per Server-Sent Events (SSE) zu machen.

Das ist interessant, das schaue ich mir mal an.

Wird das mit SSE auch auf allen Geraeten funktionieren smartphone, pc usw?
 
beim internet explorer scheint es ueberhaupt nicht zu funktionieren und ob leute noch opera mini benutzen weis ich auch nicht, aber opera mini wird auch oft bei "caniuse" als nicht unterstuetzt angezeigt.

ich habe mir gedacht man koennte es dann so bauen das erst geprueft wird ob SSE im browser funktionierrt und falls nicht dann schaltet man auf Short Polling, also man laest dann mit Javascript alle paar Sekunden den Browser neu nachfragen und wenn SSE aber unterstuetzt wird, benutzt man SSE, wie findest du mein Denkansatz?

Und ab wann wuerdest du sows wie Websocket oder XMAPP einsetzen?
 
KitKat::new() schrieb:

sieht auch gut aus, wuerdest du aus irgendeinen Grund Matix vorziehen gegenueber Websocket oder XMPP oder anderen Loesungen?

Ich kenne Matix noch nicht, aber ich nehme einfach mal an das man dort auch fertige Scripts finden wird die man anpassen kann und nicht alles komplett neu bauen muss, ist ja meistens so bei aehnlichen Projekten.

Ich habe jetzt fuer meine Webseite nicht die grosen Ansprueche und koennte auch einfach simples Short Polling benutzen aber fand die Idee SSE auch schon ein Schritt besser als Polling und ich habe auch nichts dagegen was richtig gutes direkt ein zu bauen, solange es keine Nachteile im Vergleich zu den simplen Loesungen hat, alles was gut oder am besten funktioniert ist generell interessant fuer mich, ich knn es nur nicht einschaetzen welche Sachen jetzt die meisten Vorteile haben, aber wenn ich es durch eure Tipps heraus finden kann, dann arbeite ich mich auch gerne in die beste Loesung ein.
 
KitKat::new() schrieb:
Was für Probleme?
Z.B. dass Websockets über HTTP2 ganz einfach nicht funktionieren. Dass Websockets nicht einfach so über Proxies laufen - für den Endanwender ggf. nicht so relevant, aber nervig, wenn man serverseitig Frontend-Proxies oder Caches hat. Da muss dann überall applikationsspezifische Config in die Einstellungen rein (also Sonderbehandlungen für alle Websocket-URLs). Hässlich.

Matrix ist (wie XMPP) ein kompletter Stack. Viel zu schwergewichtig, um sowas wie eine nen Besucherzähler damit zu implementieren.
 
GrumpyCat schrieb:
Dass Websockets nicht einfach so über Proxies laufen

ich habe so aehnliche Sachen auch schon oft gehoert, das Websockets Probleme machen koennen, aber was ist den wenn man sowas wie socket.io benutzt, haben die ihre Codes nicht auf alle diese probleme optimiert?
 
socket.io kann ja auch nichts machen in den Fällen, in denen Websockets nicht funktionieren. Bzw. was sie dann machen, ist automatischer Fallback auf Polling (weil socket.io kein SSE kann, auch wenn's seit nunmehr fast 10 Jahren auf GitHub bei denen PRs dafür gibt m( ).
Ganz toll: Dann bekommt man noch nichtmal unbedingt direkt mit, dass da was kaputt ist, stattdessen ist die App irgendwie nur langsam.
 
GrumpyCat schrieb:
Dann bekommt man noch nichtmal unbedingt direkt mit, dass da was kaputt ist, stattdessen ist die App irgendwie nur langsam.

Ich finde es gut das du so offen und kritisch von Websockets berichtest. Dein Tipp SSE zu benutzen war auch sehr gut, ich werde mir SSE auch demnaechst noch viel genauer anschauen.

Was waere den wenn Websockets ueber HTTP2 laufen wuerden, waeren damit die Probleme geloest welche Websockest sonst haben? Ich frage das weil ich mich erinnern kann das irgendwo erzaehlt wurde das man Websocket auch mit HTTP2 bauen kann.
 
Tatsächlich beschreibt RFC 8441 Websockets über HTTP2, und das scheint auch wenigstens in Firefox inzwischen zu gehen, aber ansonsten sieht's anscheinend eher mau aus: https://trac.nginx.org/nginx/ticket/1992

Die Frage ist halt, wozu der Aufwand? Nur weil alle "Echtzeit" mit "Websockets" assoziieren, weil die 2013 mal hip waren? Wenn's simpel sein und funktionieren soll, ist SSE besser. Wenn man voll flexibel sein will (inkl. P2P) und Komplexität mag, gibt's WebRTC.
 
Danke das du mich an deiner Erfahrung teilhaben laest. ich baue zur Zeit eine Webseite bei der ich gerne ein bis zwei neue gute Techniken einsetzen will, deswegen interissiert mich das, einerseits soll die Webseite durch bessere Technik gut laufen und andererseits will ich auch generell zur Zeit ein bis zwei neue Sachen dazu lernen, also sinnvolle neue Techniken.

Wenn WebRTC bei allen Platformen gut funktionieren wird im Gegensatz zu Websockets, dann sollte ich mich auch mit der Technik beschaeftigen. Und mit SSE werde ich mich auch beschaeftigen.

Macht es eigentlich auch ein Sinn wenn man React noch einsetzt oder ein aehnliches Framework, fuer solche Sachen wie Livebesucher zaehler, paar live Grafiken ueber aktuellen Besucherverlauf, Push Notifications bei neuen Nachrichten usw. also einfach alles bisjen dynamisch und aktiv zu halten, wird da ein Framework wie React Sinn machen oder reicht es aus wenn man SSE und/oder WebRTC einsetzt?
 
React ist in erster Linie ein UI-Framework. "Darin" kann man natürlich SSE/WebRTC/Websockets oder eine Bibliothek, die die jeweiligen Techniken benutzt, einsetzen. Vermutlich gibt es fertige Plugins für React, die sowas wie Besucherzähler-Widgets implementieren, und die eben genau SSE (vermutlich aber eher socket.io :( ) "unter der Haube" einsetzen.
 
Websockets sind ja eigentlich weit verbreitet, aber ich habe auch schon oft gehoert das die Probleme machen koennen, fuer mich ist das nicht einschaetzbar, aber da du mich an deiner Erfahrung teilhaben laest, glaube ich das es mehr Sinn machen wird, mit diesen beiden anderen Techniken zu arbeiten SSE und/oder WebRTC, ich werde mich damit etwas mehr beschaeftigen.
 
Zurück
Oben