Ich habe PHP-Websockets mit Ratchet getestet, und alles lief perfekt, bis ZMQSocket :: send plötzlich ohne ersichtlichen Grund zu hängen begann.
%Vor%Beachten Sie, dass ich ZMQ :: MODE_NOBLOCK verwenden kann, und das stoppt das Hängen, aber es behebt das Problem nicht. Der Client erhält immer noch nichts. Ich habe auch meine Box neu gestartet, die das Problem nicht behebt.
Update: Ich habe das Problem behoben, indem ich meinen Code in:
geändert habe %Vor%Jetzt ist die Frage, warum hängt es überhaupt, wenn es für ungefähr eine Stunde oder zwei in Ordnung war? Gibt es etwas, wonach ich Ausschau halten muss?
Zunächst bin ich nicht sicher, ob das eine gültige Antwort ist, aber ich spiele jetzt seit ein paar Tagen mit php-zmq und habe selbst einige Probleme. Ihre Frage führte mich zu einer Epiphanie, die wahrscheinlich meine Probleme lösen wird, und ich vermute, dass Ihre verwandt sein könnten.
Mit meinem letzten php-zmq-Problem habe ich die Umlaufzeit zwischen meinem Laptop und meinem VPS mit der Auslöse-Methode in der Zguide . Alles, was ich getan habe, war eine Kopie des Skripts tripping.php auf meinem Laptop zu ändern, indem ich die URL zu meinem VPS hinzufügte, so dass es sich mit demselben Skript verbinden würde, das remote auf dem VPS lief. Ich habe den synchronen Abschnitt in einer langen Schleife ausgeführt und den asynchronen Abschnitt mit der gleichen for-Schleife.
Ich bemerkte, dass nur ein "Client" in der Lage war, während der synchronen Schleife eine Verbindung herzustellen, egal ob er versuchte, mehrere Clients von meinem Laptop oder einen von meinem Laptop und einen von einem anderen Server zu verbinden war in der Lage zu einer Zeit zu verbinden. Ich bemerkte auch im asynchronen Abschnitt, dass meine Nachrichten pro Sekunde von ungefähr 100 Nachrichten pro Sekunde auf ungefähr 2 Sekunden pro Nachricht fielen, sobald Nachrichten an meinem Laptop eintrafen. Mein Laptop kann problemlos 10+ HTTP-Anfragen pro Sekunde mit cURL durchführen, also sind 2 Sekunden pro Nachricht nicht netzwerkbezogen.
Ich bin seit 6 Jahren PHP-Erweiterungsentwickler und PHP-Core-Hacker und habe solche Probleme schon mal erlebt. Ich bin mir ziemlich sicher, dass es aus einem Parallelitätsproblem zwischen PHP-Benutzerbereich und den internen Zeromq-Threads stammt. Mit anderen Worten, die Zeromq IO-Threads senden Befehle an den Haupt-Zeromq-Thread, aber der Zeromq-Hauptthread wird innerhalb von PHP über die Zend-Engine ausgeführt und ist an das gleiche grundlegende Verhalten wie andere PHP-Methoden / -Funktionen gebunden. Ich bin mir noch nicht sicher, ob wir genau das gleiche Verhalten in PHP-zmq erwarten können, das wir in czmq oder anderen zeromq Bindings haben - PHP ist von Natur aus sehr synchron und zeromq ist asynchron. Meine Erfahrung war größtenteils positiv, wenn nicht-blockierende Muster in php-zmq verwendet wurden.
Edit: um das mögliche Problem zu klären - Zeromq behandelt alle IO asynchron in separaten Threads. Blockierungsverhalten (wie beispielsweise req / rep) wird durch Nachrichtenaustausch zwischen den IO-Threads und dem Hauptthread anstelle der tatsächlichen Blockierung / synchronen IO erzeugt. Es ist die Nachrichtenübermittlung und Synchronisierung zwischen Threads, von denen ich denke, dass sie in PHP falsch funktionieren. Die "blockierungsfreien" Zeromq-Muster scheinen gut zu funktionieren. Die Blockierungsmuster funktionieren, zeigen aber in diesen entfernten Fällen seltsames Verhalten.