PHP-Pozess eine Message senden

[TS]

Hello,

ich bastel immer noch mit dem "Websocket-Server" rum. Der PHP-Prozess idlet jetzt schon über eine Woche störungsfrei auf dem Host herum und antwortet manchen Benutzern auch ganz brav.

Wie kann ich dem Prozess, außer über den offenen Port, Messages (nicht Signale) senden. Mit pnctl scheint man nur Signale senden zu können?

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Wie kann ich dem Prozess, außer über den offenen Port, Messages (nicht Signale) senden.

Suchstichwort: linux (oder php) interprocess communication. Es gibt da ein paar Techniken.

dedlfix.

[Rolf b]

Was spricht gegen eine weitere Kommunikation über den offenen Websocket-Port?

Welche Websocket-Library Du verwendest und wie sie genau tickt, das weiß ich nicht, aber normalerweise sollte diese Library eine Komponente enthalten, die auf den Port für die Clients lauscht und die offengehaltenen Connections managed. Vermutlich ruft sie PHP-Funktionen als Callback auf, wenn eine Nachricht eintrifft. Und vermutlich gibt's darin irgendwelche Authentication Mechanismen, so dass Du validieren kannst, ob eine Message von der Client-Seite oder von der "anderen" Seite kommt.

Ob deine Websocket-Library nun Ratchet ist oder eine andere - sie wird ziemlich sicher folgendes tun: Nach einer Initialisierung kommt ein run() Aufruf und dann ist die Kontrolle beim Listener, den die Library enthält. D.h. wenn Du einen parallelen, zweiten Messaging-Weg installieren willst, beißen sich die beiden, es sei denn, du willst Dich noch mit pthreads herumschlagen und hast das Glück, dass deine Messaging-Komponenten Multithreading-fähig sind.

Just my tuppence...
Rolf

[dedlfix]

Tach!

Was spricht gegen eine weitere Kommunikation über den offenen Websocket-Port?

Administrationszugang über die öffentliche Client-Schnittstelle ist nicht unbedingt das, was man möchte. Wenn es also solche eine Kommunikation ist, die TS anstrebt, würde ich lieber nach Out-of-band-Wegen suchen.

dedlfix.

[TS]

Hello,

Was spricht gegen eine weitere Kommunikation über den offenen Websocket-Port?

Administrationszugang über die öffentliche Client-Schnittstelle ist nicht unbedingt das, was man möchte. Wenn es also solche eine Kommunikation ist, die TS anstrebt, würde ich lieber nach Out-of-band-Wegen suchen.

Das stimmt haargenau!

Signale habe ich schon hinbekommen dank eines Threads von 2007(?), in dem Dennis einen Weg aufgezeigt hatte. Ich muss nur noch rausfinden, wo und wann genau PHP die Teststopps einbaut und wie man das selber steuern kann. Vor JEDEM Statement ist das schließlich nicht notwendig - aber in der Schleife...

Bisher übermittele ich Befehle durch Auslesen einer Textdatei, in der sie eingtragen werden müssen.

Ich würde sie sonst ins Environment schieben, wenn ich wüsste, ob man das nachträglich ändern kann. Das ist schon vorhanden und muss nicht ständig gesucht, geöffnet, gesperrt, gelesen, geleert, geschlossen werden. Aber ich gehe erstmal deinem Tipp nach über Interprozesskommunikation.

Liebe Grüße
Tom S.

[Rolf b]

Wie oben von mir schon geschrieben - die Frage ist, wieviel Hoheit über den Prozess die Websocket-Library beansprucht. Welche verwendest Du?

Rolf

[TS]

Hello,

Wie oben von mir schon geschrieben - die Frage ist, wieviel Hoheit über den Prozess die Websocket-Library beansprucht.

Wer beansprucht hier was? Da komm ich gerade nicht mit.
Mein Websocket-Prozess muss biderektional Daten und Befehle transferieren können, dafür ist er da. Da er als "Server" auch wieder im Mittelpunkt steht, muss er also zwischen diveresen Clients und diversen Server-Prozessen vermitteln können. Er soll nicht dafür genutzt werden, tatsächlich Datenmengen zu transferieren. Wenn der Client vom Server eine größere Datenmenge bekommt, wird er vom Websocket-Server dazu aufgefordert, sich diese abzuholen. Wenn er nicht darauf vorbereitet war, ignoriert er die Info einfach. Damit bleibt die eigentliche Prozesshoheit beim Client.

Welche verwendest Du?

Ich baue einen eigenen Websocket-Hub

Liebe Grüße
Tom S.

[Rolf b]

Ich hatte mir oberflächlich Ratchet angeguckt und da musste man eine run Methode aufrufen, von der ich den Eindruck hatte, dass sie nicht mehr zurückkommt und als Event-Verteiler für registrierte Listener arbeitet. D.h. du hättest keinen eigenen Code mehr, der unabhängig vom Socket-Listener läuft. Ich habe mir Ratchet aber nicht SO genau angeguckt. Es mag Möglichkeiten geben, eigenen Code parallel oder quasiparallel zum Ratchet-Listener laufen zu lassen.

Wenn du einen eigenen Hub baust, wie dann? Mit den Socket-Funktionen von PHP oder mit einem anderen Helper? Wenn Socket-Funktionen, mit socket_set_nonblock()? Dann KÖNNTEST Du abwechselnd einen socket_read() auf zwei unterschiedliche Input-Sockets machen. Einer ist von außen zugänglich, der andere nicht und dient der internen - und ggf. höher autorisierten - Kommunikation. Damit kannst Du dann sicherstellen, dass nicht irgendwer dein Passwort für den Command-Level errät und von außen die Kontrolle übernimmt. Ich würde eine einheitliche Kommunikationstechnik nach wie vor für vorteilhaft halten. Dann kannst Du für beide Seiten den gleichen Infrastruktur-Code verwenden.

Rolf

[TS]

Hello,

Wenn du einen eigenen Hub baust, wie dann? Mit den Socket-Funktionen von PHP oder mit einem anderen Helper?

Mit den Socket-Funktionen von PHP. Das Ganze basiert auf einem Vorschlag von Google.

Die übrigen Ideen muss ich mir die nächsten Tage erstmal anschauen und damit herumspielen.

Liebe Grüße
Tom S.