Kommunikation PHP <--> Browser

[samtux]

Wie ist es möglich, so etwas zu realisieren:
Ich habe eine Seite mit PHP fertig generiert und ausgegeben. Jetzt möchte ich später noch eine Information an den Browser senden, damit dieser die Information mittels Javascript in die Seite einbauen kann. Macht man das auch über AJAX? Wie genau?

Möglich ist das ja. Bei Facebook passiert ja das gleiche, wenn man eine Nachricht erhält...

[Der Martin]

Hallo,

Wie ist es möglich, so etwas zu realisieren:
Ich habe eine Seite mit PHP fertig generiert und ausgegeben.

dann ist die Geschichte aus der Sicht des Browsers eigentlich erledigt. Er betrachtet die Übertragung als beendet, und widmet sich der Interpretation der empfangenen Daten (teilweise tut er das sogar schon, während die Daten noch empfangen werden).

Jetzt möchte ich später noch eine Information an den Browser senden, damit dieser die Information mittels Javascript in die Seite einbauen kann.

Das geht nicht, weil der Browser in dem Moment gar nicht mehr zuhört. Du musst es also umgekehrt anpacken. Der Browser muss von sich aus nach einiger Zeit wieder anfragen: "Is' noch was?" Das kann eventuell sogar zyklisch immer wieder passieren, nicht nur einmal.

Macht man das auch über AJAX? Wie genau?

Das ist eine verbreitete Möglichkeit. Per Javascript wird eine Anfrage (ein Request) an den Server gestellt, ein Script auf dem Server reagiert darauf, liefert die gewünschten Antworten. Das browserseitige Javascript interpretiert dann die empfangenen Daten und fügt sie ins dargestellte Dokument ein.

Möglich ist das ja. Bei Facebook passiert ja das gleiche, wenn man eine Nachricht erhält...

Kann schon sein. Aber auch da muss die Initiative vom Client ausgehen, nicht vom Server. Der Server kann nur auf Anfragen _re_agieren.

Ciao,
 Martin

[samtux]

Also ist es die einzige Methode vom Browser aus immer nachzufragen, ob es was neues gibt. Welcher Zeitabstand ist denn das sinnvoll?

[Encoder]

Also ist es die einzige Methode vom Browser aus immer nachzufragen, ob es was neues gibt.

Schau mal ob du unter passenden Suchbegriffen (html push, http push, ajax push....) was brauchbares findest. Ich meine einmal was davon gehört zu haben. Inwiefern das aber wirklich Push ist und wie brauchbar es ist, kann ich aber nicht sagen. Habs nicht weiterverfolgt.

Welcher Zeitabstand ist denn das sinnvoll?

Einer der zur Aktualität deiner Daten passt :-) Bei der Abfrage von Messages in "fast Echtzeit" öfter, bei der Darstellung von langsamer eintreffenden Neuigkeiten seltener.

Eine Anfrage könnte von einem Server auch eine gewisse Zeit offen gehalten werden. Sie wird dann nicht gleich beantwortet sondern erst wenn es was neues gibt. Die Abfrage läuft in einen Timeout wenns nichts neues gibt, oder sie wird vorher vom Server geschlossen. Dann kann eine neue Anfrage gestellt werden. Vielleicht funtionieren ja manche Systeme auf diese Weise.

[samtux]

Meinst du sowas? WebSockets

[Encoder]

Meinst du sowas? WebSockets

Ja so irgendwas hab ich gesehen, mich aber nicht weiter damit beschäftigt.
PHP ist auf der Seite allerdings nicht zu finden. Könnte daran liegen dass ein Aufruf an ein PHP Script nach der Bearbeitung des Scripts schon wieder Geschichte ist. Da bleibt nichts bestehen.
Außer da gibts inzwischen auch wieder etwas neues?

[Tom]

Hello,

Meinst du sowas? WebSockets
Ja so irgendwas hab ich gesehen, mich aber nicht weiter damit beschäftigt.
PHP ist auf der Seite allerdings nicht zu finden. Könnte daran liegen dass ein Aufruf an ein PHP Script nach der Bearbeitung des Scripts schon wieder Geschichte ist. Da bleibt nichts bestehen.
Außer da gibts inzwischen auch wieder etwas neues?

Da suchst Du hier im Archiv mal nach "Dauerlauf"

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[molily]

PHP ist auf der Seite allerdings nicht zu finden. Könnte daran liegen dass ein Aufruf an ein PHP Script nach der Bearbeitung des Scripts schon wieder Geschichte ist. Da bleibt nichts bestehen.

PHP ist erst einmal eine Programmiersprache. Sie wird im Webserver-Umfeld (Apache, nginx… mit CGI, FastCGI, Webserver-Modul…) dazu verwendet, um HTML-Seiten zu generieren. In diesem Anwendungsbereich ist die Laufzeit des Scriptes sehr kurz und auf das Beantworten eines HTTP-Requests begrenzt.

PHP kann auch außerhalb dieses Setups auf der Kommandozeile eingesetzt werden. Eine Laufzeitbeschränkung gibt es dann nicht. PHP kann auch TCP-Sockets öffnen und als Daemon »ewig« laufen. Ein WebSockets-Server kann also auch in PHP implementiert sein, z.B. Ratchet.

Ob es eine gute Idee ist, einen Websockets-Server gerade in PHP zu schreiben, weiß ich nicht. Es gibt Implementierungen, die wahrscheinlich performanter und robuster sind. Die meisten HTTP-Daemons enthalten bereits Module für Websockets.

Grüße
Mathias

[samtux]

Ich werde es jetzt so machen, dass ich alle paar Sekunden eine Abfrage via AJAX an den Server schicke. Das ist die einfachste Variante...

[1UnitedPower]

Meine Herren!

Macht man das auch über AJAX?

Häufig macht man das über AJAX oder JSONP, es gibt da im Wesentlichen zwei Verfahren:

1. Der Browser schickt in regelmäßigen Zeitabständen Anfragen an den Server, der antwortet sofort mit den Änderungen, das ist das sogenannte Short-Polling.

2. Der Browser schickt eine Anfrage an den Server und der Server hält die Verbindung so lange offen, bis ein Ereignis eintritt und antwortet dann. Der Browser baut dann nach der Antwort (oder Timeout) die Verbindung erneut auf, das nennt sich dann respektive Long-Polling.

Diese Strategien sind sehr robust gegenüber Browser-Kompatibilität, haben aber auch ihre Schwächen, zum Beispiel ein hoher Transport-Overhead und ein vergleichsweise hoher Implementations-Aufwand auf der Client-Seite.

Mit Blick auf die neuere Browser-Generationen gibt es zweckmäßigere Möglichkeiten.

3. WebSockets – darauf bist du ja inzwischen selber gestoßen. Bei WebSockets wechseln Browser und Server auf ein anderes Kommunikations-Protokoll, das es erlaubt Nachrichten bidirektional und ohne viel Overhead auszutauschen. Die WebSocket-API arbeitet sehr stark Ereignis-orientiert und kann so den Implementations-Aufwand auf der Client-Seite drastisch senken. Auf der Serverseite (wenn PHP im Einsatz ist) wird es allerdings etwas komplizierter, aber auch dazu finden sich inzwischen viele Anleitungen im Netz.

4. Server Sent Events – Häufig ist es gar nicht notwendig, dass der Browser auch Nachrichten an den Server schicken muss, in diesen Fällen bieten sich SSEs an. Der Browser meldet sein Interesse an einem Ereignis-Feed des Servers an und wird nun immer benachrichtigt, wenn ein neues Ereignis, das von Interesse ist, eingetreten ist.

Beachte: Bei allen vier Strategien wird die Kommunikation vom Browser veranlasst, aber in den Fällen 3 und 4 gibt es echtes Server-Push-Verhalten, wohingegen 1 und 2 Polling-Verfahren sind.

Manche Anwendungen, zum Beispiel Chats, bedürfen nicht notwendiger Weise eine serverseitige Geschäftslogik, da reicht es aus, wenn Nachrichten von Client zu Client geschickt werden können. Für diesen Anwendungsfall gibt es WebRTC; dabei handelt es sich um einen Versuch, echtes Peer-2-Peer in den Browser zu bringen. Der WebServer dient in einem solchen Fall nur noch als Vermittler, der die Kommunikations-Partner miteinander bekannt macht.

[Martin R.]

Guten Morgen,

4. Server Sent Events – Häufig ist es gar nicht notwendig, dass der Browser auch Nachrichten an den Server schicken muss, in diesen Fällen bieten sich SSEs an. Der Browser meldet sein Interesse an einem Ereignis-Feed des Servers an und wird nun immer benachrichtigt, wenn ein neues Ereignis, das von Interesse ist, eingetreten ist.
   Beachte: Bei allen vier Strategien wird die Kommunikation vom Browser veranlasst, aber in den Fällen 3 und 4 gibt es echtes Server-Push-Verhalten, wohingegen 1 und 2 Polling-Verfahren sind.

meines Wissens nach macht der Browser bei SSEs auch nichts anderes als Long-Polling. Bisher gibt es auch noch keine Unterstützung dafür im Internet Explorer.

\0

[1UnitedPower]

Meine Herren!

meines Wissens nach macht der Browser bei SSEs auch nichts anderes als Long-Polling.

In der Spezifikation [w3c] konnte ich beim Überfliegen keine entsprechende Vorschrift finden, dort steht lediglich, dass eine neue Zeile im Event-Feed ein onmessage-Event feuern soll.

Es kann natürlich trotzdem sein, dass Browser auf Polling setzen um diese API zu implementieren. Ich habe es gerade mal mit Firefox, Chrome und Wireshark überprüft und das sieht für mich sehr nach einen Short-Polling aus. Es werden auch nicht weniger Request-Header an den Server gesendet, somit ist die Bandbreiten-Einsparung gegenüber AJAX-Shortpolling natürlich hinfällig. Dadurch dass uns der Polling-Algorithmus aber nativ vorliegt, bleibt die clientseitige Arbeitseinsparung natürlich unangetastet und zumindest dieser Vorteil bleibt bestehen.

Bisher gibt es auch noch keine Unterstützung dafür im Internet Explorer.

Guter Hinweis. Für solche Fälle gibt es bestimmt Polyfills und die dürften durch die gerade gewonnene Erkenntnis den nativen Implementierungen zumindest bei der Datenübertragung in nichts nachstehen.

[Martin R.]

meines Wissens nach macht der Browser bei SSEs auch nichts anderes als Long-Polling.
In der Spezifikation [w3c] konnte ich beim Überfliegen keine entsprechende Vorschrift finden, dort steht lediglich, dass eine neue Zeile im Event-Feed ein onmessage-Event feuern soll.

Da hast du aber ein altes Dokument rausgekramt! Aktuell empfiehlt das W3C diesen Kandidaten.
Nichtsdestotrotz scheint das Onlinebeispiel, das ich mir heute Nacht angesehen habe, fehlerhaft zu sein; bei meinen eigenen Tests trat das von dir beschriebene Verhalten auf (Client meldet sein Interesse an, Server schickt ohne weitere Anfragen Daten raus, Client ACKʼd die eintreffenden TCP-Pakete). Cool!

\0

[Tom]

Hello,

Beachte: Bei allen vier Strategien wird die Kommunikation vom Browser veranlasst, aber in den Fällen 3 und 4 gibt es echtes Server-Push-Verhalten, wohingegen 1 und 2 Polling-Verfahren sind.

Was dann bedeutet:
1. anderes Protokoll
2. anderer Port
3. andere Richtung

Darauf muss die ganze Übertragungsstrecke Rücksicht nehmen und dies auch zulassen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg