AJAX / Push technieken + data overdracht
Ik wil een applicatie schrijven, waarbij het van belang is dat de data redelijk real time op het scherm komt van de gebruikers.
Het eerst waar ik dan aan denk is Periodieke AJAX requests, zoals ik dat "Vroeger" deed.
Nou heb ik op internet een beetje gezocht, en dan vind je ook informatie over push technieken, comet etc. De reden dat ik aan periodieke ajax requests twijfel, is omdat het nogal useless is (IMHO) als er steeds geen data binnenkomt...
Hoe zouden jullie dat doen? Zijn er hier mensen die al ervaring hebben met die push technieken?
En dan nu de data storage.
Stel in het geval van een webchat (wil ik niet bouwen, maar even voor de versimpelde overview).
Gebruiker A stuurt een bericht, komt aan bij de server. Hoe gaat dit dan terug naar gebruiker B?
Er moet (neem ik aan) een soort van "tussen layer" tussen zitten, en zoals je veel ziet word hier dan een SQL database voor gebruikt.
Dat klinkt me persoonlijk ook nogal "vies" in de oren, je wilt toch geen database gebruiken voor data die in 2 secs weer weg is?
Als het zou kunnen als een echte daemon, dan sla je dat gewoon op in een array ofzo, en die stuur je dan meteen door als een push over een socket. Dan word het niet onthouden.
Maar we hebben het hier over PHP ( neem ik aan ? ) en niet over C o.i.d.
Of is de 1 of andere push techniek (ik weet (nog) niet hoe dat precies werkt) ook te combineren met C in plaats van PHP?
Help would be very appreciated :)
Althans, dat is de theorie. In werkelijkheid heb je dus een directe verbinding tussen je daemon en APE of Orbited, als een proxy dus, welke dan weer als http server op een of andere obscure manier de data doorspeelt aan de browser. (Vaak meerdere technieken, zoals content replacement, long polling, chunked content, allemaal nog een beetje hackish, en het een werkt in de ene browser beter dan in de andere. Maar daarom zijn APE en Orbited er ook, die doen dit werk voor je)
Meestal komen deze daemons ook standaard al met een message queue. Het idee is dat de client subscribed op een kanaal, en dat de server dan berichtjes naar kanalen pusht. Dit topic zou bijvoorbeeld een kanaal kunnen zijn, kanaal /topics/70296, en de server zou naast mijn nieuwe post in de database wegschrijven ook meteen de inhoud van m'n nieuwe post naar de message queue kunnen sturen, specifiek met als doel kanaal /topics/70296. De message queue zorgt er dan voor dat dat naar alle verbindingen die ingeschreven zijn bij dat kanaal wordt doorgestuurd, en APE of Orbited zorgt er dan voor dat het bericht zo snel mogelijk bij de webbrowser die gekoppeld is aan die ene verbinding wordt bezorgd. In javascript kan je het opvangen, en kan je het zeg maar behandelen als een event.
Voor chat berichten zou ik alleen een message queue gebruiken (of specifieker gewoon een chat daemon, IRC kan trouwens ook! Word vaak als voorbeeld van de mogelijkheden gebruikt) Wil je dat de data terug te lezen is, dan maak je van het push-gebeuren gewoon een extra laag.
De message queue hoeft verder op zich niet een array met berichten bij te houden, zolang de verbinding open blijft zorgt orbited of APE er wel voor dat de berichten aankomen. Maar als je zeker wilt weten dat de berichten aankomen, ook wanneer mensen pagina's herladen of verlaten, zal je toch iets met een array en ontvangst-bevestingen moeten opzetten. Soms blijft een verbinding tussen de daemon en orbited nog gewoon open staan, omdat orbited dan nog niet door heeft dat de gebruiker de pagina verlaten heeft. Dus alleen op de status van de verbinding vertrouwen is niet genoeg. Volgens mij heeft het STOMP protocol, wat zo'n beetje de standaard is onder de message queues, ontvangstbevestiging wel ingebouwd.
Periodieke ajax requests zijn trouwens wel gemakkelijker te implementeren, maar in mijn ervaring soms echt totaal killing voor de webserver en zou ik eigenlijk proberen te vermeiden voor meer dan 20 bezoekers. (zeker als die webserver Apache + suPHP + php-cgi, en dan geen fcgi si)
edit: niet duidelijk gezegd, maar het is zo dat webbrowsers dus eigenlijk direct verbinding maken met de message queue (via een proxy dan weliswaar) en ook zelf berichten naar andere kanalen zouden kunnen sturen. Ik weet niet of het handig is voor jouw toepassing (je krijgt als het ware een soort p2p communicatie met jouw queue alleen als doorgever) maar je zou ook kunnen kiezen om alleen PHP aan queues te laten schrijven, en de browsers alleen laten ontvangen en eventueel ontvangst-bevestigingen laten sturen naar de queue zelf, en niet verder. Dan heb je meer controle over je "netwerk".
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Welke raad jij aan?
Want zo te horen heb je er wel ervaring mee, Jelmer.
De techniek klinkt me inderdaad goed in de oren, en ontvangsbevesteging zou wel fijn zijn. Het is fijn om te weten wanneer een persoon het kanaal verlaat.
Het gaat trouwens om een speelkaart game.
Ik moet wel zeggen dat ik Orbited nog niet heb getest met veel gebruikers tegelijkertijd. De grootste tekortkoming van Orbited tot nu toe is dat ik niet betrouwbaar kan zien wanneer de verbinding verbroken is. Maar ik denk dat dat eerder een tekortkoming is van http, en dat orbited daar met pingen omheen probeert te werken. Maar pingen heeft een interval. Vandaar die ontvangstbevestiging.
APE is in C(++?) en volgens mij iets actiever op het moment. Ze hebben ongeveer een maand geleden versie 1.0. Het heeft de kanalen volgens mij ingebakken, en je kan zelf plugins schrijven in C++ en javascript. Ik weet niet precies hoe die proxy-functie zoals die zit in Orbited werkt in APE.
Orbited is geschreven in Python (maakt gebruik van het Twisted framework voor HTTP volgens mij) en is wel heel gemakkelijk in gebruik.