AJAX / Push technieken + data overdracht

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

Java Developer / Domotica / Public Cloud / Verbete

Functieomschrijving Wil jij als Java Developer een bijdrage leveren aan het ontwikkelen van innovatie Java applicaties die het levensgeluk van patiënten in diverse zorginstellingen aanzienlijk verbeterd? Lees dan snel verder! Ontwikkelen van nieuwe applicaties in Public Cloud; Optimaliseren en verbeteren van bestaande applicaties in Private Cloud; Meedenken over verbeterprojecten; Maken en uitvoeren van Stress Testing; Ontwikkelen en verbeteren van de Mobile app. Functie-eisen Hbo werk- en denkniveau; Minimaal 5 jaar relevante werkervaring; Ervaring in Java 8; Kennis van Linux, Public- en Private Cloudtechnieken; Je bent communicatief erg sterk en kan tegen de nodige stress. Bedrijfsomschrijving Deze organisatie is al ruim

Bekijk vacature »

Niek s

niek s

17/01/2010 22:51:00
Quote Anchor link
Hi,

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 :)
 
PHP hulp

PHP hulp

20/01/2020 01:19:11
 
Jelmer -

Jelmer -

17/01/2010 23:38:00
Quote Anchor link
Orbited en APE hebben allebei een websocket-alike implementatie. Eigenlijk kan je dat zien als gewoon sockets in de browser. Je kan dan vanuit Javascript een verbinding openen met een socket op jouw server, en die verbinding blijft dan open zolang de user op die pagina blijft.

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 -
 
Niek s

niek s

17/01/2010 23:45:00
Quote Anchor link
Ik hoor je praten over Orbited en over APE.
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.
 
Jelmer -

Jelmer -

18/01/2010 12:28:00
Quote Anchor link
Ik gebruik zelf Orbited, omdat APE toentertijd nog niet te compileren was op een mac, en testen dan niet lekker wil. Tegenwoordig kan dat wel, maar ik heb verder niet veel meer naar APE gekeken.

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.