Ich habe eine Datenbank, die in unregelmäßigen Abständen( 0,5 Sekunden bis 5 Minuten) mit Zahlen gefüttert wird.
Der „Inhalt“ (Abfrageergebnisse) der Daten werden über eine Webseite in PHP bereit gestellt.
Ich möchte jetzt erreichen, dass die PHP Seite sich neu lädt, wenn ein neuer Eintrag in die Datenbank geschrieben wird. Ein Trigger von dem Programm das die Daten in die Datenbank schreibt ist nicht das Problem.
Meine Frage ist, wie bekomme ich es hin, dass der Client eine aktualisierte Anzeige bekommt.
Man könnte dieses über einen Autoreload auf der PHP-Webseite Seite erreichen, der würde mir aber zum einen zuviel unnötige Last auf der Datenbank erzeugen und zuviel sinnlosen Netztraffic.
Daher würde ich es gerne so machen, dass sobald der Trigger meldet, das ein neuer Eintrag in der DB ist, die Seiten ihr Anfrage erneut stellen.
entweder einfach alle 5 sec minuten via AJAX pullen mit angabe des letzten ausgelieferten eintrages und nur bei änderung gibts neue daten.
Oder mit Comet System , z.v. ape , is kostenlos und füttert ganz viele user gleichzeitig . http://www.ape-project.org/
leidr alles nciht mehr aktuell auf der support seite, aber der mailinglist support ist gut
um einen „reload“ kommst du wohl nicht rum, da Abfragen nur die Richtung Client=>Server laufen können.
Eine Möglichkeit dem Server zu sagen, bitte stupse den Browser an, wenn neue Daten da sind, ist so einfach nicht möglich. (Vielleicht indem du ein p2p Netzwerk aufbaust oder so… aber dann gibts clientseitig wieder etwas zu tun).
Ich hätte gesagt du nimmst dir client-seitig jQuery zur Hand und setzt alle 5 sekunden einen ajax call ab.
PHP Seitig lässt du deinen „Trigger“ jedes Mal wenn er neue Daten in die Tabelle schreibt, ein Array (nennen wir es &clients) in den APC von PHP cachen.
Wenn nun ein Client seinen ajax call absetzt, überprüft das empfangende PHP ob diese session id schon in &clients vorhanden ist. Wenn nicht, holt sie sich die neusten Daten aus der Datenbank, trägt die eigene Session ID in &clients ein, und sendet die Daten zurück. Wenn die session id bereits eingetragen ist, wurden also schon die aktuellen Daten abgefragt und es wird einfach nichts zurück gegeben. Somit kannst du schon mal unterscheiden welcher client bereits die neusten Daten hat, und welcher nicht.
Wenn jetzt dein „Trigger“ wieder neue Daten hat, überschreibt er &clients, die Liste ist wieder leer und jeder client holt genau ein mal ab. Bis die eigene ID eben wieder in &clients steht.
zwar musst du immer noch die Netzlast in kauf nehmen (allerdings auch weniger weil ja nicht jedes Mal etwas zurück geschickt wird), es greift nicht jeder client jedes Mal auf die Datenbank zu, wenn z. B. mal 5 Minuten lang nichts geschieht. Den dann ist jeder in &clients und es passiert nichts. Erst wenn wieder neue Daten geschrieben werden, ist die Liste wieder leer.
Im Grunde genommen ruft das Clientseitige Javascript den EventListener auf. Dieser öffnet die PHP auf Serverseite (Im Session Konzext).
In dieser muss eine Schleife ständig überprüfen ob neue Daten da sind, und wenn, dann müssen diese an den Client ge"flusht" werden. Zum Überprüfen muss der Weg von vorhin wieder benutzt werden. „gemeinsames Array mit allen clients“.
Aber man würde sich tatsächlich das Pollen per AJAX sparen.
nur. wie gesagt. Solang das nicht vom IE Unterstützt wird, und der IE aber immer noch einer der wichtigsten Browser ist, fällt diese Geschichte meiner meinung nach weg.
Ich bin aber auf dem Weg einige meiner Projekte darauf umzubauen, damit sie in den Startlöchern stehen, sollte der IE sich mal verarbschieden
Ich hatte schon geschrieben comet system, das nennt man beiläufig in der fachsprache so wenn es um server http push geht .
z.b. ape
oder auch node.js
damit kann man ganz gut pushen , von mir aus auch sockets, das nehmen jedenfals die web-spielehersteller heutzutage um tausende von usern zu füttern mit aktuellen daten .
