PHP ban hogy lehet ilyent?

...Makó Jeruzsálemtől?

- De azt ugye tudod, hogy Makó ebben az eseteben nem a város-t jelenti?

A PHP-t alapvetően arra találták ki, hogy jön egy kérés a klienstől, a PHP előállít dinamikusan egy tartalmat, majd elküldi a kliensnek, és vége. A kliens szólítja meg a szervert, és nem fordítva. Itt viszont a szervernek kellene jelezni a kliens felé, hogy Pistike rajzolt egy vonalat. Hogy lehet ezt megoldani?

1. A kliens mondjuk másodpercenként letölti a képet. Ez így nem lesz folyamatos, de eléggé leterheli a szervert. Ahány néző, annyiszor kell előállítani egy képet. Itt jobb, ha nem a képet tároljuk le raszteresen, hanem valamilyen vektoros formában küldi el a szerver a vonalakat, íveket a kliensnek. Ekkor kisebb adatot kell átküldeni, de így is annyi oldalkérés, ahány néző van. Egy sima Apache2+PHP kombinációnál ilyenkor mindig elindul egy új PHP értelmező, előállítja az adatokat, majd bezáródik. Egy nginx + PHP-FPM esetén kicsivel jobb a helyzet, de nem túl szerencsés még mindig, az asszinkron működés miatt. Az oldalkérések egymástól függetlenek, akár az egy klienstől érkező kérések, illetve a válaszok sorrendje is összekeveredhet, ami nézőként nem néz ki túl jól. Ráadásul még mindig csak 1 FPS-el látnák a nézők a rajzolást, ha növeled az FPS-t, akkor a másodpercenkénti oldalletöltéseket is növeled.

2. A másik megoldás a polling. Ilyenkor a kliens elküld egy kérést, arra a szerver elindítja a PHP értelmező egy példányát, vagy a PHP-FPM-ben nyit egy szálat, az küld is adatot, de nem zárja le a kapcsolatot. A szerver folyamatosan nézi, jött-e a rajzolótól új vonal, ív, és ha igen, akkor abban a pillanatban kiküldi a kliens felé, de még mindig nem zárja le a kapcsolatot. A probléma, hogy előbb-utóbb le kell zárni a kapcsolatot, ezért azt mindig újra kell nyitni. A másik probléma, hogy a szervernek folyamatosan mondjuk adatbázisból kell figyelnie, hogy történt-e változás, így a futó szálak eléggé eszik a processzoridőt. Nem mellesleg ahány néző, annyi élő szál, ami meg a memóriát eszi meg.

3. Az ideális megoldás a websocket használata. De annak implementálására a PHP nem annyira alkalmas, azt inkább node.js-el, vagy más nyelvel érdemes megoldani. Ott meg tudja a szerver is szólítani a klienst, a rajzoló kliense is meg tudja szólítani a szervet, így viszonylag kis erőforrás igénnyel el tud futni az egész. Persze ha vektorosan tárolod a képet. De itt is ugye le kell tárolni a vonalakat, mert ha valaki nyom egy frissítést, vagy közben csatlakozik be, akkor szeretné ugyanazt a képet látni, mint az, aki az elejétől fogva figyel.

Szóval a dolog nem egyszerű, és nagyon nem PHP-ban kellene nekiállni. A kliens része még egyszerűbb, ahhoz bőven jó a HTML5 Canvas. De ott is van mit megírni, optimalizálni.

Ergo ha el sem tudod kezdeni, akkor megette a fene. Ehhez azért kell „némi” tudás és tapasztalat, és nem 10 perces munka, senki nem fog teljes megoldást adni a kezedbe ingyen és bérmentve.

"...ebből anyit nem tudok hogy hogyan kell iylen rajzolós dolgot és hogy live ban lássák real time ahogy rajzolva van"

Magyarul, fin/god sincs az egészről.

WebSocket + Canvas...

Nem egy két sor lesz ennek a kivitelezése.

Az #1 -es példájával élve, Makó sokkal közelebb van Jeruzsálemhez,

mint te a megoldáshoz, te kb. másik Galaxisból kezded és nem Samsung.