tami: Websocket grunsätzlich - Variante mit PHP + Variante mit ZF2

Beitrag lesen

hi alle,

http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket beschreibt einen simplen Websocket-Server und -Client mit PHP/Javascript.

Das Serverscript wird schlussendlich gestartet mit:

php -q c:\path-to-server\server.php

Im Script (server.php und auch clientseite) wird noch notiert: "ws://localhost:9000/daemon.php".

Dieses "daemon.php" ist aber kein Script, das existiert, wie ich das sehe. "Was" ist das? Ein Alias für den Daemon?

Zwei Fragen, vor dem Experimentieren habe ich noch:

1. Wie stoppe ich das Script, dass ich ja über die Konsole aufrufen muss (da gibts dann wohl auch keine MaxExecutionTime)? Sicherlich kann ich über ps ax mir alle Prozesse aurufen und mit killall <Prozessnummer> dann den Prozess wieder killen, aber fragt sich, ob das der beste Weg ist. Unter Windows7 funzt die Konsole ja auch u.U. garnicht so ...; gut, da gäbe es den Taskmanager.

2. Dieser Websocket-Server ist dann für alle Clientanfragen zuständig. Die Frage ist bestimmt blöde, aber ich denke mal, dass das ja Sinn des Servers ist, alle Anfragen zu steuern. Ab welcher Fülle von Anfragen verschluckt sich dann aber das Ding?

Abgesehen davon beschäftigt mich noch: mal angenommen, es soll kein Chat damit realisiert werden, sondern zB. ein GPS-Tracker, wo der Client alle 10 Sekunden (oder auch jede Sekunde) seine Position an den Server übermittelt. Wäre da ein Socket überhaupt sinnvoll? http://www.websocket.org/quantum.html beschreibt, wie das mit den HTTP-Headern im Vergleich zu Websocktverbindung aussieht: "And what about the reduction in latency? Take a look at the following figure. In the top half, you can see the latency of the half-duplex polling solution. If we assume, for this example, that it takes 50 milliseconds for a message to travel from the server to the browser, then the polling application introduces a lot of extra latency, because a new request has to be sent to the server when the response is complete. This new request takes another 50ms and during this time the server cannot send any messages to the browser, resulting in additional server memory consumption.

In the bottom half of the figure, you see the reduction in latency provided by the WebSocket solution. Once the connection is upgraded to WebSocket, messages can flow from the server to the browser the moment they arrive. It still takes 50 ms for messages to travel from the server to the browser, but the WebSocket connection remains open so there is no need to send another request to the server." (besonders auch die Grafik dazu).

Ansonsten finde ich noch eine Variante, die auf dem ZendFramework basiert als Modul: http://modules.zendframework.com/stanislav-web/ZF2-PHP-WebSocket-Server. Hier starte ich den Server mit "php -q index.php websocket open" was nahelegt, dass ich mit dem Paramter "close" das Ding wieder schließen könnte. Allein die index.php muss ich mir selber basteln, umd das Modul zu integrieren. Da habe ich den Autor angemailt und die Antwort erhalten: "Hello, Robert!

You must initialize the application in your public index.php.

Add the following code

date_default_timezone_set('Europe/Berlin');
// Change to the current dir
chdir(dirname(__DIR__));

// Running application (that is after autiloader init)
Zend\Mvc\Application::init(require 'config/application.config.php')->run();"

Da ist mir (immer noch) nicht ganz klar, ob und wenn ja wie das entsprechende Modul dann eingebunden wird, aber da wird die Doku vom ZF vermutlich noch weiter helfen.

Wer da noch irgendwie Tipps zu hätte, wäre ich dankbar.

mfg

tami