[PHP] Websocket & XML-RPC

[Ultimation]

Ik ben wat aan het experimenteren met Websockets in PHP. Alleen niet op Client <=> Server niveau, eerder (XML-RPC/Websocket)Server <=> (XML-RPC/Websocket)Client <= Website

Even een concrete omschrijving. De website is voorzien van een XML-RPC Client die met een XML-RPC Server via Websockets de XML-RPC calls communiceert. Deze XML-RPC calls bevatten opdrachten, bijvoorbeeld voeg dit Nieuwsartikel object toe.

Het opzetten van de communicatie via Websocket tussen de XML-RPC client en server is geen probleem. Dat gaat prima. Omdat de Websocket verbinding werkt middels een eindeloze while-loop (altijd openstaande verbinding) is het niet mogelijk om na het starten van de while-loop nog code uit te voeren. Hierom draait de WebsocketClient middels een background proces. Om de XML-RPC call op de Websocket verbinding te krijgen gebruik ik IPC (Inter-Proces Communication). Dus de Websocket client heeft een "backdoor" via een interne socket waar de XML-RPC class zijn call naar toe kan sturen. Deze wordt opgepakt en verzonden over de Websocket naar de XML-RPC Server verstuurd, die deze ontvangt, verwerkt en zijn respons stuurt.

Het laatste stuk loop ik nu op vast. Hoe kan ik de XMLRPC-Response van de WebsocketServer weer op de plek van aanvragen krijgen (de XML-RPC client).

De WebsocketClient bestaat uit 3 gedeelten namelijk:

1. Het openen van de Websocket verbinding
2. Het draaien van een IPC-proces zodat de XML-RPC client zijn calls via de Websocket kan versturen
3. Het kunnen ontvangen van de XML-RPC (server) calls via de Websocket verbinding (while-loop)

Op dit moment kan ik alleen 2 of 3 draaien omdat je anders in een blocking toestand terecht komt.

Ik heb al gekeken naar naar PHP pthread, alleen ik vind de voorbeelden te mager om hier iets mee te kunnen. Daarbij blijf ik met het proberen van het opzetten van die threads tegen een blocking-event aanlopen.

Ik heb zelf o.a het volgende bedacht. De while loop waarmee ik aan het verzenden ben in de WebsocketClient ook voorzien van een optie om te ontvangen. Alleen hoe krijg ik dan de data die ik wil verzenden in die eindeloze while loop? Dit is immers een blocking-event.

Ik ben opzoek naar iemand met de gouden tip!

[Hipska]

Ik vermoed dat je het nodeloos ingewikkeld maakt met extra processen, of er mist iets in je uitleg waarin duidelijk wordt waarom bepaalde dingen niet kunnen.

[TheNephilim]

Als je met websockets aan de slag, kun je volgens mij beter wegblijven van PHP. Wat je nu aan het doen bent is (denk ik) van Server <=> Client met PHP en dan Client <=> met JS? Niet echt logisch allemaal, tenzij ik het verkeerd begrijp.

Realtime reageren binnen éénzelfde request is misschien wel mogelijk, maar verre van ideaal in PHP. PHP is stateless en begint bij iedere request weer helemaal opnieuw. Daar is het ook voor gemaakt, een request moet doen wat het doen moet en dan meteen afsluiten.

Als je echt met websockets aan de slag wil, heb je volgens mij alsnog een comet server nodig. Mocht je geen zin hebben om zelf een server op te zetten, dan is http://pusher.com/ een leuke manier om eens kennis te maken. Wil je toch zelf een server, dan kun je http://ape-project.org/ eens proberen. Relatief simpel en best compleet.

[storeman]

Klinkt mij ook behoorlijk complex in de oren. Ik heb eens wat geexperimenteerd met ElephantPHP, dit is een koppeling met NodeJS.

ElephantPHP < -- > NodeJS < -- > Browser

[Ultimation]

Aller eest bedankt voor de reacties!

Het experiment moet laten doen blijken of dit mogelijk overgenomen kan worden in een bestaand product. Dit bestaande product is opgebouwd uit XML-RPC request die nu nog via HTTP verlopen. Om het aantal request te verminderen ben ik aan het onderzoeken of het dit via Websockets kan verlopen. De theorie laat een drastische vermindering zien in de verbruikte bandbreedte.

Wegblijven van PHP is, hoewel ik weet dat het beter is hier mogelijk Python etc voor te gebruiken, geen optie.

De XML-RPC server bevat alle data voor de onderliggende clients. Deze clients zijn websites. De websites zijn geprogrammeerd in PHP en verwerken de binnen gekomen XML-RPC respons. De website verwerkt request die via HTTP gedaan worden. Dat past precies binnen de stateless PHP ideologie. Maar de technieken zijn er, dus is het de moeite waard dit te onderzoeken.

De bestaande producten en oplossingen gaan uit van een Client => Server model. In mijn situatie is dat geheel anders. Hier heb ik een (Web)Server <==> (Web)Server <= Client model.

Waar ik nu op vast loop is dat ik binnen mijn XML-RPC Client een 2 eindeloze while loops heb die wel onderling moeten communiceren. Namelijk de Websocket verbinding en een die het mogelijk maakt een backdoor te hebben in de eindeloze whileloop van de WebsocketClient. Anders is het niet mogelijk XML-RPC request te verzenden over de websocket verbinding. Dit is omdat de WebsocketClient de request aan de HTTP kant (website bezoeker) moet verwerken. De pagina (XML-RPC request voor de XML-RPC server met daarin verzoek om de data) moet eindelijk wel verwerkt worden.

Het is ook complex maar zeker een leuke uitdaging. Ik hoop dat dit het wat verduidelijkt. Als er vragen en nog steeds onduidelijkheden zijn, feel free to comment!

[TheNephilim]

Maar zelfs in een bestaand product, kun je toch nooit elke request op deze manier afhandelen met PHP? While loops, eindeloos, in PHP?

Dus een request moet van Client naar Server (1) en dan weer naar Server (2)? Waarvoor dient server 1? Als dat slechts een proxy is, haal je jezelf veel gezeur op de hals. Daarnaast begrijp ik dat communicatie tussen server 1 en server 2 ook realtime moet zijn toch?

[Ultimation]

TheNephilim schreef op donderdag 10 april 2014 @ 10:45:
Maar zelfs in een bestaand product, kun je toch nooit elke request op deze manier afhandelen met PHP? While loops, eindeloos, in PHP?

Dus een request moet van Client naar Server (1) en dan weer naar Server (2)? Waarvoor dient server 1? Als dat slechts een proxy is, haal je jezelf veel gezeur op de hals. Daarnaast begrijp ik dat communicatie tussen server 1 en server 2 ook realtime moet zijn toch?

Het is mogelijk om eindeloze while-loops te gebruiken in PHP. Deze kan je bijvoorbeeld via de commandline of als daemon starten.

Het geheel bestaat uit een XML-RPC backend en een XML-RPC front-end. Wanneer een website bezoeker een pagina opvraagt verstuurd de XML-RPC front-end een request naar de backend. Als respons krijgt hij de data van de opgevraagde pagina terug.

Hier een visualisatie van de opstelling:


b = website bezoeker

[Hipska]

Dus nu is de stippellijn een XML-RPC request. En wat is de volle lijn nu? AJAX request?

En waar is gegeven de opstelling nu de bottleneck? En waar wil je in de toekomst een WebSocket verbinding hebben?

[Ultimation]

De stippellijn is de XML-RPC request via Websocket. De volle lijnen "normale" http requests.

[DXaroth]

Ultimation schreef op donderdag 10 april 2014 @ 11:32:
[...]


Het is mogelijk om eindeloze while-loops te gebruiken in PHP. Deze kan je bijvoorbeeld via de commandline of als daemon starten.

mogelijk en enigzins verantwoord zijn 2 verschillende dingen. zoals eerder gezegd, PHP is gemaakt voor single-request afhandeling, niet voor eindeloos blijven draaien.. het heeft geen (zinnige) GC functionaliteit voor dit soort doeleinden, en je zult in 95% van de gevallen merken (na een tijd) dat dat narigheid gaat uithalen.

Je set-up lijkt me ook wat.. vreemd in opstelling; normaliter gaat de verdeling juist andersom: meerdere back-end server systemen die geloadbalanced worden op client verzoek, in plaats van meerdere clients die naar 1 server praten.. heeft dit een specifiek doel? of zijn het juist de clients die alle processing doen? (en is het eerder een koppeling server => datasource?

Om terug te komen op het websocket verhaal; is het niet zinniger om iets a-la HTTP keepalive te gebruiken? dan heb je ook meerdere requests over 1 tcp verbinding heen, maar keepalive is een HTTP standaard, dus hoef je niet je eigen xmlrpc implementatie te doen. (Ik ben altijd huiverig om standaarden aan te passen naar een specifiek doel, omdat je daarmee nieuwe standaarden creëert die later voor extra werk kunnen zorgen als je iets wilt vernieuwen/vervangen)