Update einer Chatfunktion

[dedlfix]

Tach!

    public function onMessage(ConnectionInterface $from, $msg) {
/* Der Funktion onMessage könnte man ja noch ein wenig mehr Variablen mitgeben. zum Beispiel für eine Abfrage in Welche Tabelle etwas in die DB geschrieben wird. Sprich die Informationen aus den Checkboxen. Bezug zu Kommentar 2 */
    }

Nein, du kannst da keine weiteren Variablen einbauen. Die Funktion wird genauso von Ratchet aufgerufen. Du hast nur die beiden Parameter und nichts weiter. Du musst all deine Daten aus der Message entnehmen. Und das war der Grund, warum ich sagte, dass du da ein Protokoll brauchst. Im einfachsten Fall packst du deine Daten auf dem Client mit JSON zusammen. Das ist dann deine Message. Die kannst du auf dem Server auseinandernehmen und hast wieder die einzelnen Bestandteile. Und nun kannst du mit den extrahierten Daten deine Funktionen aufrufen, die damit irgendwas spezielles tun.

    public function onOpen(ConnectionInterface $conn) {
        // Store the new connection to send messages to later

       /*Die Infos aus den checkboxen müssten ja mindestens hier einmal auftachen, dann würden sie aber nicht erneuert, wenn ein client ein neues häckchen setzt/entfernt erneuert, oder?
    }

Nein. Dieser Event-Handler wird nur beim Verbindungsaufbau aufgerufen. Dabei werden noch keine Nutzdaten übertragen. Die kommen frühestens im ersten onMessage-Event.

    public function onMessage(ConnectionInterface $from, $msg) {
        $numRecv = count($this->clients) - 1;
        echo sprintf('Connection %d sending message "%s" to %d other connection%s' . "\n"
            , $from->resourceId, $msg, $numRecv, $numRecv == 1 ? '' : 's');

        foreach ($this->clients as $client) {
            /* Kommentar 2 : Dann könnte man hier im  if  fragen in welche tabelle man eine neue  Zeile anlegen will und $msg und alles was man eben hat in ein SQL-Statement basteln.*/

Ja. Nein. Die Daten musst du schon hier in diesem Eventhandler zumindest entgegennehmen. Sie auch noch hier auszuwerten, bläht die ganze Funktion ganz schön auf, was man der Übersichtlichkeit wegen vermeiden möchte. Aber das lasse ich mal eben unberücksichtigt.

Du bekommst eine $msg übergeben. Aus der musst du die Information zur Tabelle und den eigentlichen Chat-Text herausfischen. Das war das Ja. Das Nein bezieht sich darauf, dass du hier schon im foreach bist. In diesem Beispiel wird einfach stur an alle derzeit verbundenen Clients die eingegangene Chatnachricht rausgesendet. Außerdem ist dieses Beispiel so einfach gehalten, dass nur die Chatnachricht und nichts weiter übertragen werden. Da ist noch nichtmal ein Name dabei, so dass die Clients keine Information bekommen, wer die Nachricht geschickt hat. Vielleicht kannst du aus den Metadaten im $from noch eine IP-Adresse finden, aber das wars dann auch schon. Du musst also erstmal auf anderem Weg an den Namen kommen, den der Nutzer bei sich eingegeben hat, falls du den Gesprächsbeteiligten nicht nur eine ID anzeigen möchtest. Das ist der nächste Grund für ein sich zu überlegendes Protokoll, damit festgelegt ist, wie solche Metainformationen übertragen werden.

         **jetzt müsste ich hier noch irgendwie Informationen aus onOpen (?) herkriegen die sagen welcher client welche Nachrichten lesen will (Die Infos aus dem SELECT)

Nicht aus dem onOpen, sondern aus einem der onMessages. Womit wir wieder beim Protokoll sind.

Was da dafür unbedingt brauchst, ist der Zugriff auf den Server, denn Websocket ist serverseitig nicht einfach nur ein PHP-Script, das über Requests aufgerufen wird. Da muss ständig ein separater Server auf Verbindungsversuche lauschen. Und diesen Server musst du starten können, was nicht damit getan ist, per FTP Dateien ins DocumentRoot des Webservers zu legen.

Ähm...^^ SRY Denn ersten Satz versteh ich noch, dann wird kritisch.

Herkömmlich ist der Apache dafür ausgelegt, einen Request zu bekommen, den übergibt er dem PHP-Script, das erzeugt eine Antwort und ist daraufhin fertig und wird beendet. Für deinen Chat über Websockets brauchst du eine ständige Verbindung und nicht nur eine, die kurz für einen Request-Response besteht. Für solche Dauerverbindungen ist der Apache nicht direkt ausgelegt. In der aktuellen Version 2.4 gibt es lediglich ein Proxy-Modul, das die Kommunikation durchreicht. Und das an einen weiteren Server (sprich in deinem Fall: Ratchet), der ständig laufen muss und nicht nur ein kurz aufgerufenes PHP-Script ist. Diesen Server musst du starten können, wofür du Zugriff auf das Betriebssystem brauchst. Ein Webspace allein reicht dafür nicht, da brauchst du einen Server (diesmal als Hardware gemeint, inklusive virtualisierte). Der Proxy im Apachen ist nicht unbedingt notwendig, aber dann brauchst du einen zweiten Port, auf dem der Ratchet laufen kann und die Clients verbinden sich direkt dorthin. Das hat den Nachteil, dass dieser Port von den Firewalls der Clients nicht geblockt werden darf. In restriktiven Umgebungen wird meist nur Verkehr zum Port 80 (und 443) durchgelassen. Kurz: Du brauchst einen Server und musst diesen administrieren können.

Die Alternative dazu ist Polling. Das funktioniert herkömmlich und dabei wird die Request-Response-Verbindung künstlich lange (bis zum Timeout) offengehalten, darüber Daten gesendet, wenn in der Zeit welche anfallen. Nahc dem Timeout muss die Verbindung wieder aufgebaut werden. Oder sie fragen nur einen normalen Request an, der sofort mit "hab was/nichts neues" beendet wird und feuern diese entsprechend oft.

Bei Websocket musst du auch noch dafür Sorge tragen, dass warum auch immer unterbrochene Verbindungen wieder aufgebaut werden. Beim Polling passiert das ja schon aus Prinzip ständig.

Du siehst hoffentlich, mit ein paar kleinen Änderungn ist da nichts getan. Das System braucht noch ein paar mehr Überlegungen.

dedlfix.