[Grundlegendes] Echtzeit im Web

para_noid

hirnrissig
Ich würde gerne wissen, welche verlässlichen (Kompatibilität, Sicherheit, Performance) Methoden es gibt, Teile einer Webapplikation in Echtzeit zu ändern.

Beispiel: ich hab eine Anwendung mit Benutzern, die dazu berechtigt sind, sich gegenseitig Nachrichten zu schicken (ist nur Beiwerk zum eigentlichen Projekt). Die Seite an sich ist klassisch mit PHP und MySQL aufgebaut.
Ich möchte jetzt erreichen, dass ein angemeldeter Benutzer umgehend über den Eingang einer neuen Nachricht informiert wird, in Form eines eingeblendeten Icons oder Infofensters oder weiß der Geier was.

Wie kann ich das realisieren?
  • Clientseitiges Javascript mit Ajax allein haut ja nicht hin - ich könnte hier nur Intervalle definieren, in denen der Server mit Anfragen zugebombt wird.
  • serverseitiges Javascript wie node.js ist zurzeit noch wie ein Buch mit sieben Siegeln für mich - soweit ich's verstanden habe, muss ich dafür einen extra Server laufen lassen und ich wüsste nicht, wie ich meine bestehenden PHP-Scripte damit verknüpfen könnte. Ich möchte ja nicht alles in Echtzeit haben.
  • ich habe weiterhin von HTML5-Sockets gehört, die für solche Fälle geeignet sein sollen, von deren Verwendung aber mangels Kompatibilität noch abgeraten wird.
  • ?

Gibt es weitere Möglichkeiten? Könnte jemand was zu den genannten ergänzen? Wie würdet ihr das Beispielproblem angehen?
Ich weiß einfach nicht, wo ich anfangen soll.
 
Am verbreitetsten und wahrscheinlich einfachsten ist Variante 1, sprich per Ajax Requests an den Server schicken und die aktuelle Situation abfragen.

Ich würde dir ja gerne wissen wie Facebook das umgesetzt hat, aber ich glaube die haben für ihren Webauftritt einige eigene grundlegende Dinge selbst entwickelt, wie z.B. ihre Datenbank. Ich glaube auch, dass sie eine eigene Programmiersprache verwenden. Aber theoretisch können sie die Abfragen auch nur über Ajax lösen. Javascript gibts jedenfalls genug im Quellcode.
 
Am verbreitetsten und wahrscheinlich einfachsten ist Variante 1, sprich per Ajax Requests an den Server schicken und die aktuelle Situation abfragen.

Ja, am einfachsten bestimmt - aber ich mag nicht wahrhaben, dass ich wahrscheinlich darauf setzen muss ;)

Ich hab mir das mal bei Stackoverflow & Rest angeschaut, weil man dort auch in Echtzeit (oder nah dran) die Notifications bekommt. Ich konnte mit Firebug keinen Request gen Server ausmachen, bis die Meldung da war. Ich kann mir aber genausowenig vorstellen, dass die Seiten alle in einer selbstentwickelten Sprache oder durchgehend mit node erstellt sind.

Auf Facebook treib ich mich nicht rum ;) aber zumindest in Richtung PHP hatten die mal was eigenes. Aber dass darüber dann die Echtzeit realisiert wurde wag ich irgendwie zu bezweifeln..
 
Was verstehst du unter "Echtzeit"?
Zwischen einem Webchat und zB einem browsergame wo die ressourcen in Echtzeit berechnet werden, bestehen große unterschiede in der Implementierung.
 
Nimm doch das Beispiel aus meinem Eingangsbeitrag. Notifications auf einer Webpage in Echtzeit beim Benutzer zeigen.
Was würdest du denn für deine Beispiele jeweils anwenden? Was macht wann Sinn?
 
Ich würde auch zu ersterem tendieren, da hier in den meisten Anwendungsfällen eh keine 100% Echtzeit garantiert werden muss, dh der Ajax-Request alle x Sekunden (interval) reicht vollkommen aus.
Einen (größeren) webchat kann man über einen websocket lösen, oder alternativ bei kleineren userzahlen eben auch irgendwas über http.. vllt auch mit ajax.
Bei browsergames weiß ich nicht was man einsetzt bzw einsetzen sollte. Gehört habe ich schon von daemons, also im hintergrund laufende programme die die vielen berechnungen durchführen, die bei einem BG anfallen.
 
Hi Leute,

seiten wie Facebook oder viele andere arbeiten mit sogenannten "Push-Servern". Da solche massiven Community Seiten meistens auf Cluster-Servern betrieben werden, wird meist eine(oder mehrere) node innerhalb des Clusters extra für diese Art von Diensten abgestellt. Somit können Updates in Echtzeit zu dem Client geschickt werden. Der Client direkt braucht dafür keinen request zum Server zu schicken, da der Server selbst merkt, wann es ein Update in der Datenbank gibt. Nach dem Update in der Datenbank wird dann eine query erstellt, welche mit sogenannten background workern abgearbeitet wird. Diese schicken dann mit Hilfe des Push-Servers die Updates direkt zum Client.

Node.js ist eine von vielen varianten um dies umzusetzen. Die einfachste Möglichkeit für dich wird allerdings erst einmal per Ajax/Javascript deinen Server mit requests zuzubomben (was auf einer Standard Webseite mit normalen Besucherzahlen keine drastischen Performanceprobleme verursachen sollte). Top ist diese Lösung natürlich noch lange nicht, aber es funktioniert... ;)

Ich hoffe ich konnte ein wenig Licht in die Sache bringen.

Gruß
Chans
 
dh der Ajax-Request alle x Sekunden (interval) reicht vollkommen aus.

Reicht aus, belastet aber schon ziemlich. Nehmen wir mal 500 User (einfach als Hausnummer) die gleichzeitig online sind und von deren Clients alle 5 Sekunden n Request rausgeballert wird. Das wären 30.000 Anfragen pro Minute wenn ich jetzt nicht komplett vorbei bin, bei denen nichmal zwangsläufig was Gescheites zurückkommen muss. Das ist vielleicht nicht gerade tödlich, aber mit kommt's halt so tödlich ineffizient vor.

Gehört habe ich schon von daemons, also im hintergrund laufende programme die die vielen berechnungen durchführen, die bei einem BG anfallen.

Weißt du noch mehr dazu (bestimmten googlebaren Begriff vielleicht)? Interessant hier wäre wieder, wie die errechneten Werte zum Client kommen.

@ chans danke für die Infos. Aber
Nach dem Update in der Datenbank wird dann eine query erstellt, welche mit sogenannten background workern abgearbeitet wird. Diese schicken dann mit Hilfe des Push-Servers die Updates direkt zum Client.
könntest du den Teil vielleicht noch etwas erläutern (nur interessehalber, nicht weil ich es umsetzen möchte)? Wie läuft das genau ab, wenn die Push-Server den Client updaten? Läuft auf denen dann nur node o.Ä.?


edit: hab ich das jetzt richtig aufgefasst, dass Websockets so ne Art Zwischenstufe von JS/Ajax zu Node/komplett-serverseitig sind? Oder wo könnt ich die einordnen?


Naja, schade. Ich dachte vielleicht ich könnte nen besseren Weg nehmen als den üblichen weil's so viel neues Zeug gibt :rolleyes: trotzdem erstmal danke an alle.
 
Zuletzt bearbeitet:
Zurück