[PHP/JS] Realtime response

[Sagittarius]

Momenteel heb ik een idee in mijn hoofd voor een applicatie, maar ik loop tegen mijn technische beperkingen aan.

De situatie is als volgt:

• Er zijn 2 pc's die verbonden zijn aan een netwerk of internet
• PC1 is de PC waarop invoer van gegevens zal plaatsvinden
• Via het netwerk/internet zullen deze gegevens worden opgeslagen in een DB en voor elke complete opdracht zal een nieuwe record worden aangemaakt in de DB

Tot zover nog geen probleem, maar hier begint mijn beperking:

• PC2 is een PC die geen gegevens zal invoeren.
• Op het scherm van PC2 worden alle records getoond die in de opdrachtentabel van de DB staan, zodra deze via PC1 zijn geplaatst. (Bijna) Realtime dus.
• Gebruiker van PC2 zal per record aangeven of het akkoord is of niet

Nu kan ik dit wel deels oplossen door een interval te plaatsen en iedere x sec gegevens op te vragen, maar ik zou graag een mogelijkheid hebben om een soort trigger te bouwen die dit voor me zal opvangen.

Is dit mogelijk en in welke richting moet ik dan denken? PHP, JS of misschien toch iets anders?

[--MeAngry--]

Met PHP en JS gaat zoiets mbv een push systeem niet lukken. (Of je moet echt rare fratsen en hacks uithalen.) Dan kun je dus beter naar een applicatietaal kijken en een native applicatie schrijven die wel dit soort zaken ondersteunt.

[MueR]

Dat gaat je, zoals MeAngry zegt, niet lukken met webapplicaties. Daar is het web namelijk niet voor gebouwd. Dat is een pull protocol, informatie komt pas als jij er om vraagt.

[Cartman!]

Zulke toepassingen kun je wel met bijv. Flash of Java. Python heeft er ook een library voor zeg ik uit mn hoofd. Het keyword (buzzword) om op te zoeken is COMET.

[DexterDee]

Er zijn technisch veel fraaiere oplossingen te bedenken, maar als PHP als taal echt een vereiste is, dan zijn er wel oplossingen die relatief gezien niet echt hacks zijn. Het vereist echter wel wat geavanceerd programmeerwerk. Ik heb zelf dergelijke applicaties gemaakt (voor fun en ook voor wat meer serieuze zaken) en ik kan je garanderen dat het prima werkt.

Dit is een mogelijke oplossing voor een push mechanisme:

Maak op PC1 een PHP script met deze kenmerken:
- Open een listening socket op een poort (bijv. 8080)
- Implementeer een hele simpele HTTP webserver via de sockets functie van PHP
- De webserver heeft als doel HTML/Javascript terug te geven
- Op het moment dat je een push event moet sturen, schrijf je iets als <script>push();</script> op de socket.
- Zorg ervoor dat er om de zoveel seconden een bogus javascript statement gestuurd wordt om de verbinding open te houden, bijv. <script>heartbeat();</script>
- Zet het webserver script in een oneindige loop en sluit de socket pas als je een socket write error krijgt. Herinitializeer dan en luister opnieuw naar de poort

Op PC2 open je een webpagina waarbij je via een hidden ajax div (of piepklein iframe) die HTML gaat inladen via http://192.168.1.1:8080. De meeste browsers waaronder IE en Firefox hebben de prettige gewoonte om Javascript meteen uit te voeren als het binnen komt en in de DOM geschreven wordt. Op het moment dat die <script>push();</script> over de lijn gestuurd wordt, zal in de browser de functie push() onmiddelijk aangeroepen worden. Hier kun je dan een bepaalde actie aan verbinden. Met een timerobject kijk je wanneer de laatste heartbeat() is binnengekomen om te detecteren dat de verbinding is uitgevallen. In dat geval moet je opnieuw (via ajax) een request doen naar de PHP webserver.

Doordat het PHP webserver proces periodiek blijft schrijven zal de verbinding geen timeout krijgen en zolang als nodig in stand gehouden worden. Natuurlijk kan er op netwerkniveau ook iets mis gaan met de verbinding, maar daar heb je die heartbeats dan voor.

Het is niet de meeste nette methode en zeker niet de meest voor de hand liggend, maar je push events zijn wel zo goed als realtime, zónder de overhead van meerdere polls per seconde.

Natuurlijk krijg ik met deze oplossing allerlei criticasters over me heen die me gaan vertellen dat een browser niet gemaakt is om een permanente socketverbinding open te laten. In de praktijk werkt het echter prima, ook voor langdurige sessies. Dit is natuurlijk een poor man's client-server oplossing, waar vele betere alternatieven voor zijn. Soms is het echter leuk om out-of-the-box te denken en iets op te lossen met een taal waarvan de meerderheid zegt dat het niet mogelijk is

[Cartman!]

Voor 1 enkele verbinding kan dat best werken maar aangezien die thread oneindig open blijft staan vind je webserver dat echt niet tof. Het is gewoon niet "the right tool for the job", begin er dan ook niet aan vind ik dan.

[Janoz]

Vergeet de manier van DexterDee.

Php is ontworpen om als kort lopend single thread proces te draaien. Hierdoor hebben de ontwikkelaars allemaal aannames kunnen doen mbt geheugen beheer en resources. Gebruik je php voor iets waarvoor het niet bedoeld is dan zul je geheid tegen problemen aanlopen zoals memory leaks.

Wat me in dit geval relevanter lijkt is om te kijken wat nu daadwerkelijk de requirements zijn. Definieer realtim eens. Moet dat echt binnen enkele miliseconden zijn? Je zou ook richting een ajax oplossing kunnen kijken waarbij je telkens kijkt of er updates zijn. Zorg gewoon dat het resultaat van dit request heel klein is waardoor het dataverkeer beperkt blijft. Het hoeft helemaal geen probleem te zijn om deze vervolgens meerdere keren per seconde op te vragen.

[DexterDee]

Cartman! schreef op vrijdag 02 oktober 2009 @ 16:19:
Voor 1 enkele verbinding kan dat best werken maar aangezien die thread oneindig open blijft staan vind je webserver dat echt niet tof. Het is gewoon niet "the right tool for the job", begin er dan ook niet aan vind ik dan.

Ten eerste heeft hij het over 2 PC's, niet over honderden simultane webclients. Ten tweede gebruik je niet een 'echte' webserver maar is je PHP script de webserver. En die vindt het prima om oneindig te draaien. En dat dit niet de 'right tool for the job' is heb ik al duidelijk gemaakt in mijn post. Maar wellicht is onder de omstandigheden deze oplossing 'good enough' voor de TS.

[Sagittarius]

Janoz schreef op vrijdag 02 oktober 2009 @ 16:29:
Vergeet de manier van DexterDee.

Php is ontworpen om als kort lopend single thread proces te draaien. Hierdoor hebben de ontwikkelaars allemaal aannames kunnen doen mbt geheugen beheer en resources. Gebruik je php voor iets waarvoor het niet bedoeld is dan zul je geheid tegen problemen aanlopen zoals memory leaks.

Wat me in dit geval relevanter lijkt is om te kijken wat nu daadwerkelijk de requirements zijn. Definieer realtim eens. Moet dat echt binnen enkele miliseconden zijn? Je zou ook richting een ajax oplossing kunnen kijken waarbij je telkens kijkt of er updates zijn. Zorg gewoon dat het resultaat van dit request heel klein is waardoor het dataverkeer beperkt blijft. Het hoeft helemaal geen probleem te zijn om deze vervolgens meerdere keren per seconde op te vragen.

Dat is een goede vraag. Daarom had ik er ook bijna voor gezet

Het gaat om een softwarepakketje dat ik ga maken voor een afhaal- en bezorgcentrum. Voor bezorg tellen de secondes niet zo zeer, maar de minuten wel degelijk.

Terwijl ik zo over dit probleem nadenk, denk ik dat de meest eenvoudige en beste oplossing toch is om eens in de 10 seconden een request naar de server te sturen om te kijken of er een nieuwe record is. Ik zat gewoon veel te moeilijk te denken, terwijl een server prima meerdere reqs per minuut aankan.

[Verwijderd]

Eventueel kun je nog kijken naar Reverse Ajax: Wikipedia: Reverse Ajax

[B0rf]

een andere manier die je kunt doen is met javascript/iframe een PHP-pagina te openen, en deze op de server te laten wachten. Dit laten wachten kan bijvoorbeeld met blocking IOstreams. Op deze manier kan PHP meteen de data doorsturen zodra deze binnenkomt, en verschijnt de boel nagenoeg direct op het scherm. Nadat dit bericht is verstuurd sluit de verbinding, handelt javascript het bericht af, en verbind opnieuw. Je moet natuurlijk wel iets van een buffer op de server hebben, anders zouden er dingen verloren kunnen gaan.

Op deze manier blijft PHP niet lang lopen, de client maakt nog steeds meerdere requests, alleen het wachten is verplaatst van client naar server, waardoor je directer kunt reageren

[DexterDee]

Janoz schreef op vrijdag 02 oktober 2009 @ 16:29:
Vergeet de manier van DexterDee.

Php is ontworpen om als kort lopend single thread proces te draaien. Hierdoor hebben de ontwikkelaars allemaal aannames kunnen doen mbt geheugen beheer en resources. Gebruik je php voor iets waarvoor het niet bedoeld is dan zul je geheid tegen problemen aanlopen zoals memory leaks.

Ik snap heel goed wat je hier bedoelt, echter hoewel PHP niet bepaald gemaakt is om dit soort taken te draaien, doe je PHP wel wat te kort. Ik heb op een aantal Linux server daemomized PHP scripts draaien die al vele maanden zonder onderbreken hun werk doen en met sockets en andere IPC middelen (message queues, shared mem) communiceren. Deze scripts had ik keurig in C kunnen schijven, maar dan kon ik het hele (bestaande en nogal uitgebreide) backend objectmodel in PHP niet hergebruiken. Uitendelijk heb ik daar enorm veel tijd kunnen besparen.
Natuurlijk zijn er allerlei valkuilen zoals memory leaks, maar daar valt prima omheen te werken. Door dezelfde strategie aan te houden als in talen zonder garbage collector voorkom je problemen (zoals het strategisch unsetten van variabelen). Om het CPU verbruik te optimaliseren is het vaak genoeg om met socket_select en usleep te werken. De processen die ik heb gemaakt bevatten absoluut geen memory leaks en doen hun werk uitstekend en met minimale CPU belasting. Zeker als je geen top performance hoeft te hebben van een native compiled language. Om diezelfde reden zou je ook Perl en Python kunnen afschieten, want daar zijn ook genoeg projecten die van deze strategie gebruik maken (denk aan grote pakketten als Trac en Webmin).

Ik had deze reactie wel verwacht en was daarom extra voorzichtig met mijn bewoordingen en heb ook duidelijk gezegd dat het niet de meest optimale oplossing is. Maar feit blijft dat ik behoorlijk wat praktijkervaring heb op het gebied van permanent draaiende PHP processen en de IPC tussen meerdere lopende PHP processen. En ik weet dat dit niet per definitie altijd een slechte oplossing is. Ik programmeer zelf ook o.a. Objective-C/C++ en weet heel goed waar de zwakke en sterke punten liggen van diverse programmeertalen. Uit principe een oplossing neersabelen is natuurlijk erg makkelijk.

[storeman]

Wellicht dat Google Web ToolKit je kan helpen. Ik weet dat Google 'Wave' aan het bouwen is, dit is dus echt realtime, character voor character tussen meerdere browsers. Ik denk dus dat deze functionaliteit hier in te vinden is.

Een ander voorbeeld is google search-hint. Deze werkt ook zonder request (volgens bugzilla). Volgens mij weer met behulp van de Web Toolkit

[RobIII]

Mensen moeten eens leren beseffen wanneer iets (near)realtime nodig is en wanneer niet. Voor een pizzaboer boeit het echt niet als er (bijv.) iedere 30 seconden gepolled wordt of er nog nieuwe orders zijn. Het is niet alsof 'ie 2ms na het ontvangen van een realtime bericht aan de slag gaat.

Realtime is in een he-le-boel gevallen gewoon onzin en levert vaak overengineered en complexe (en dus dure) oplossingen die op de lange termijn de investering tegen een simpel polletje vet verliezen.

[DrivinUCrazy]

Het is al weer anderhalf jaar geleden dat ik iets voor het laatst geprogrammeerd heb, en misschien is het niet wat je zoekt. Maar misschien heb je iets aan "Dojo Toolkit. Daar hebben we toen webbased "real-time" communicatie mee opgezet. Het nadeel van Dojo was toen wel nog dat het erg slecht gedocumenteerd was, maar inmiddels kan dat best zijn verbeterd.

[Borizz]

Heb je al eens naar het APE (Ajax Push Engine) project gekeken? Lijkt me een prima oplossing in jou geval.