[php] Hoe verzend je realtime data tussen twee gebruikers?

[Onbekend]

Ik wil een website maken waarbij gebruikers tegelijkertijd online zijn.
De communicatie tussen deze gebruikers kan je volgens mij goed vergelijken met een chat, maar dat is het niet.
Het doel is dus dat een gebruiker data naar de server zend en nadat de server de data gecontroleerd heeft, deze het aan 1 of meerdere gebruikers door te sturen.


De website mag geen complete flash of Java-applicatie in de browser laden, omdat het grootste gedeelte van de code uit HTML en JavaScript bestaat. De ene gebruiker kan namelijk de content in de browser van de andere gebruiker aanpassen. Het HTML en JavaScript voor de verzender en ontvanger werkt prima, maar alleen de communicatie naar de server werkt niet zoals ik wil.
Bij het zoeken van voorbeelden voor communicatie (o.a. chats) en zelf heel wat testwerk gedaan te hebben stuit ik op een aantal problemen.

De meeste chatscripts (zonder flash en Java) die ik heb gevonden werken met AJAX die continu naar de server pollen. Dit gaat enorm veel dataverkeer kosten.
Stel dat er 20 gebruikers continu online zijn en 512 byte aan pakketten per seconde op de server afvuren, is dat dan 20 x 512 x 60 x 60 = bijna 37 MB per uur! (Ruim 27 GB per maand)
Dit dataverkeer is veel te veel, en natuurlijk verwacht ik overdag toch meer dan 20 gebruikers om m'n site te hebben. Die AJAX techniek om te pollen is dus geen optie.

Als een gebruiker data heeft verstuurd zou dit binnen 1 seconde ( het liefst real-time) op het scherm van de andere gebruiker komen te staan. Om dit te realiseren zou de browser dus een verbinding constant open moeten houden waarbij de server op het juiste moment data kan versturen.

Nu heb ik al wat geëxperimenteerd:
De zender verstuurt wat data naar de server, en het php-script wat er achter zit zet die data in een MySQL database. Een ander php-script, wat door elke ontvanger wordt aangeroepen, kijkt constant naar de database of er data is, en als die data er is wordt dit verzonden naar de ontvanger.

Nu heb ik het pollen verplaatst van de het dataverkeer naar de server zelf. Maar ik vind het niet zo'n goed idee om continu een query op die database los te laten. Als ik 20 ontvangers heb, staan er dus 20 van deze scripts te runnen die elke keer een query op die database afvuurt.
Dit kost natuurlijk heel veel processortijd (en harde schijf?!?) en ik zoek nu een manier om i.p.v. te pollen dit met een event te doen zodat die processortijd beperkt blijft.

Kent iemand een of andere techniek die die processortijd beperkt en waarbij de gebruiker "real-time" de data binnenkrijgt?

[Saven]

Volgensmij is er een manier die COMET heet ofzo. Maar daar weet ik het fijne niet van.
Iemand die ik ken gebruikte die methode veel (zei hij). Moet je even Googlen

[Blaise]

Je kan het e.e.a. cachen natuurlijk, zodat je database het minder zwaar heeft.

Comet is een techniek om data te pushen naar de client. Maar Apache is niet geschikt voor dat. Elke open connectie is één thread, en threads zijn zwaar bij Apache, dus als je veel gebruikers hebt kom je al snel in de problemen.

[Zoijar]

XmlHttpRequests maken met een lange time-out vanuit de client, en vervolgens de server thread opzetten met een condition variable op globaal (applicatie) niveau. Dan kan je je thread laten sleepen totdat een ander data klaar heeft en een wake-up op de conditie var doet. Dat zal vaak je server zijn die een batch aan events broadcast.

De hoeveelheid data kan je niets aan doen lijkt me, dat moet je sowieso sturen...

[mees]

Het eerste wat in mij opkomt, is een oplossing die als veel mensen waarschijnlijk als "vies" bestempeld zal worden:

In plaats van met javascript dmv AJAX elke seconde te pollen, kun je denken aan een zelfde soort constructie, maar dan een poll eens per 30 seconden (naar bijv poll.php). Poll.php geef je een execution time limit van 30 seconden. In deze poll.php laat je een while(true) loopje constant kijken voor nieuwe data. Zodra deze er is, output genereren, en de while loop doorbreken, zodat de AJAX een response krijgt. Krijgt de AJAX geen response, start deze een nieuwe poll.

Wellicht wat warrig uitgelegd. Mocht je me niet begrijpen, geef dat even aan, dan zal ik het trachten anders uit te leggen

[B0rf]

De techniek die ik gebruik is een flash xmlsocket verbinding. Je browser gebruikt dan een flash component van 500-700 bytes, die binnenkomende gegevens meteen doorstuurt naar javascript. Op deze manier blijft je webpagina wel javascript gebruiken, maar kan wel een actieve verbinding openhouden naar een server. Een net wrapper-script kun je vinden op http://www.devpro.it/xmlsocket/ . Eventueel zou je iets kunnen maken dat zodra er geen flash beschikbaar is, de gebruiker terugvalt op polling of COMET.

[MSalters]

Begrijp je wat een website precies is? Je gebruikers kijken naar een (X)HTML pagina met daarop Javascript, afgeleverd via HTTP. AJAX is niet veel meer dan het downloaden van extra data, met Javascript, via HTTP - creatief gebruik van de beperkte technlogie die je hebt.

Concreet heb je dus een HTTP communicatiekanaal tussen een HTTP server en de Javascript in een webbrowser=HTTP client. Het HTTP protocol stelt dat de client alle communicatie initieert. De server kan niet ongevraagd data sturen. Pollen is daarom een oplossing.

Overigens moet je niet denken dat je met HTTP zomaar pakketjes kunt sturen. Nagle's algoritme houdt je halfvolle pakketjes op, omdat er mogelijk meer daata komt wat er in dat pakketje meekan.

[Zoijar]

Ja precies, zelfde gedachte Maar die while(true) brengt je webserver snel op z'n knieen, dus vandaar een conditie variabele.

(Of gewoon standaard websites gebruiken waar ze voor bedoeld zijn en een applicatie schrijven )
(flash socket is wel vet; ga ik eens naar kijken)

[ Voor 38% gewijzigd door Zoijar op 26-01-2009 22:35 ]

[mees]

Ik ging er natuurlijk wel vanuit dat TS een programmeur van enig niveau is, en uiteraard een while(true) loop zou vertalen naar een passende loop

Hoewel een while(true) met een sleep(1) ook prima werkt, lijkt me.

Maar wat je zegt, zelfde gedachte

[Alain]

Als je deze restrictie's hebt: Moet het persee een applicatie zijn die in een browser draait? Het lijkt me dan beter om een open connectie op te zetten en updaten als de server je van nieuwe informatie voorziet, Alla IRC of jabber.

[RobIII]

En hoe "realtime" moet het zijn? Er is nogal een verschil tussen "realtime" en "realtime" Moet het écht binnen 1 seconde? Of is dat een gewenste (maar minder reële en praktisch lastigere) waarde? Klanten roepen vaak maar wat namelijk. Ik heb zat "real-time" systemen gemaakt waarbij orders "real-time" moesten binnenkomen uit allerlei systemen waarbij een 'poll' om de 5 minuten "real-time" genoeg was. Het is toch (vaak/meestal) niet alsof je een seconde na het ontvangen van een order omdat een klant op "OK" klikt begint met orderpikken ofzo.

[ Voor 76% gewijzigd door RobIII op 26-01-2009 22:54 ]

[Alain]

RobIII schreef op maandag 26 januari 2009 @ 22:51:
En hoe "realtime" moet het zijn?

Op zich een heel goed punt, maar realtime wil alleen zeggen dat de data binnen een bepaalde tijd beschikbaar is. Of dat nu 0,001s of 5 minuten is maakt voor de definitie niet uit.

Maar je punt is duidelijk en goed.:)

[moto-moi]

Ik vraag me af hoe je erbij komt dat een gemiddelde gebruiker 512 bytes per seconde zal versturen, daar kom je volgens mij nooit aan als het gewoon om tekstchatten gaat.
Verder bestaat wat je zoekt allang, dat noemen we een irc server Sterker nog, een ajax-enabled versie bestaat ook al, in de vorm van oa. mibbit

Hetgeen je trouwens ook in actie kunt zien door deze link te volgen

[Onbekend]

Wat een reacties.

Met "realtime" bedoel ik dat de data zonder pauze of wachttijd verstuurd wordt. Polling is dus niet realtime omdat die pas wacht voordat een x aantal miliseconden zijn verstreken.

Hoelang het duurt voordat de data de bestemming bereikt is natuurlijk afhankelijk van de serverload en hoeveelheid dataverkeer onderweg, maar een tijd van 1 seconde of lager vind ik acceptabel.

Over die 512 bytes heb ik op diverse websites gelezen dat je dat moet aanhouden bij het pollen m.b.v. AJAX. Je hebt namelijk een request wat naar de server moet, en de reactie van de server terug. Ook al staat er niets in dat pakketje, het heeft de benodigde headers voor het TCP/IP-protocol.

Gezien de hoeveelheid reacties ben ik denk ik de komende avonden wel zoet met het uitproberen van de verschillende mogelijkheden.

[MueR]

Dan moet je een applicatie maken, geen website. Daar is HTTP niet voor bedoeld.

[RobIII]

MueR schreef op dinsdag 27 januari 2009 @ 00:06:
Dan moet je een applicatie maken, geen website. Daar is HTTP niet voor bedoeld.

My idea exactly. Er zijn allerlei leuke 'workarounds', maar HTTP is nou eenmaal een pull-protocol. HTTP-push is 99 v.d. 100 keer ellende, en die ene keer dat 't misschien ("betrouwbaar" *kuch*) werkt tref je nét die ene gebruiker met lynx _{Jaja, ik dik het wat aan...}

Ik vraag me af wat er zo kritisch is dat binnen 1 seconde aan de andere kant moet zijn...

[ Voor 9% gewijzigd door RobIII op 27-01-2009 00:47 ]

[SinergyX]

Stel dat er 20 gebruikers continu online zijn en 512 byte aan pakketten per seconde op de server afvuren, is dat dan 20 x 512 x 60 x 60 = bijna 37 MB per uur! (Ruim 27 GB per maand)

Maar, zet dit nu eens op 3 seconde? Heb je dus maar 1/3de, net 9GB. Pak daarbij de kans dat er over een dag maar 50% nonstop van die 20 aanwezig zijn, 4,5GB. Desnoods 5 seconde. Zoals gezegt zal dit amper tot niet met html (of uberhaubt http) lukken, eigelijk progsel of irc heb je dan veel meer aan.

(ik heb een jaar of 3 terug zoiets moeten bouwen voor een plaatjes database, achteraf bleek enkel een check bij submit al genoeg te zijn om alles 'realtime' te houden. Een gewone website dus ).

[Wolfboy]

moto-moi schreef op maandag 26 januari 2009 @ 23:30:
Ik vraag me af hoe je erbij komt dat een gemiddelde gebruiker 512 bytes per seconde zal versturen, daar kom je volgens mij nooit aan als het gewoon om tekstchatten gaat.
Verder bestaat wat je zoekt allang, dat noemen we een irc server Sterker nog, een ajax-enabled versie bestaat ook al, in de vorm van oa. mibbit

Hetgeen je trouwens ook in actie kunt zien door deze link te volgen

Als je alleen al naar de HTTP headers van deze pagina kijkt dan zie je dat er al snel zo'n 500 bytes heen _en_ 500 bytes terug gestuurd worden. Nu kan dit uiteraard wel minder zijn, maar met alle http/tcp/ip/eth overhead kan 1 byte versturen al snel een kilobyte aan dataverkeer opleveren. Overigens nog steeds verwaarloosbaar m.i.

[Onbekend]

B0rf schreef op maandag 26 januari 2009 @ 22:22:
De techniek die ik gebruik is een flash xmlsocket verbinding. Je browser gebruikt dan een flash component van 500-700 bytes, die binnenkomende gegevens meteen doorstuurt naar javascript. Op deze manier blijft je webpagina wel javascript gebruiken, maar kan wel een actieve verbinding openhouden naar een server. Een net wrapper-script kun je vinden op http://www.devpro.it/xmlsocket/ . Eventueel zou je iets kunnen maken dat zodra er geen flash beschikbaar is, de gebruiker terugvalt op polling of COMET.

Na lang prutsen met xmlsocket krijg ik het voorbeeld zelfs niet aan de praat.
De server geeft bij connect: "23 bytes recieved from Client" en direct daarna "Client Disconnected".
Ik heb verder lopen zoeken maar niemand anders klaagt over deze melding. Ik heb al mijn eigen ip i.p.v. 127.0.0.1 geprobeerd aan te passen, en ook het poortnummer aanpassen naar andere nummers had totaal geen effect. Heeft iemand daarover ideeën hoe ik de oorzaak van deze fout kan vinden?

Dat irc ziet er wel interessant uit (nog nooit gebruikt ), maar daar heb ik serverside te weinig controle over denk ik. Daarnaast wil ik dus geen chatapplicatie maken.

@MueR en RobIII: Ik wil dit graag in een webbrowser laten draaien omdat ik niet zomaar bij iemand een .exe wil laten installeren. Daarnaast kan ik in een webapplicatie gemakkelijk iets updaten, terwijl het automatisch laten installeren van een update wat lastiger is.

[Confusion]

Onbekend schreef op maandag 26 januari 2009 @ 21:29:
Dit dataverkeer is veel te veel, en natuurlijk verwacht ik overdag toch meer dan 20 gebruikers om m'n site te hebben.

Voortdurend 20 concurrent gebruikers op je website? Heb je uitgerekend dat dat een redelijke verwachting is of zuig je dat uit je duim (in welk geval ik denk dat je er, zeker gedurende de opstarttijd minstens een factor 10 naast zit)? Schat eens hoeveel concurrent gebruikers T.net heeft.

Daarnaast hoef je niet iedere seconde te pollen om een redelijke responsesnelheid te hebben: die socket blijft wel langer dan een seconde open, zoals mees ook aangeeft.

Blaise schreef op maandag 26 januari 2009 @ 22:17:
en threads zijn zwaar bij Apache

FUD.

[Onbekend]

Het gaat om interactie tussen die gebruikers.
Ik heb die aantallen niet uitgerekend, maar dat dat toch wel een minimale verwachting is.
Mocht die site aardig werken zal het aantal gelijktijdige gebruikers (hoop ik) toenemen. In het begin zullen die aantallen inderdaad wel een flinke variatie hebben, maar dat komt later.
Het belangrijkste punt is dat bij normaal gebruik het dataverkeer naar de server niet enorm groot mag zijn.
Als ik met sockets ga werken, hoef ik inderdaad niet te pollen en dat scheelt enorm. Het probleem is dat ik die sockets helemaal niet aan de praat krijg.

[bredend]

Als je voor pollen gaat zou je ook HTTP codes kunnen gebruiken.

304 Not Modified
Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Utilizing this saves bandwidth and reprocessing on both the server and client.

[Confusion]

Onbekend schreef op zondag 01 februari 2009 @ 12:42:
Ik heb die aantallen niet uitgerekend, maar dat dat toch wel een minimale verwachting is.

Dit soort getallen ontrekken zich aan je intuitie. Als je het niet netjes probeert te schatten, dan is het volkomen onbetrouwbaar. Je had net zo goed een vierjarig buurkind om een getal tussen de 0 en de 50 kunnen vragen.

[MueR]

Onbekend schreef op zondag 01 februari 2009 @ 12:09:
@MueR en RobIII: Ik wil dit graag in een webbrowser laten draaien omdat ik niet zomaar bij iemand een .exe wil laten installeren. Daarnaast kan ik in een webapplicatie gemakkelijk iets updaten, terwijl het automatisch laten installeren van een update wat lastiger is.

Je wil een protocol misbruiken. HTTP kan dit niet fatsoenlijk, omdat het er niet voor gebouwd is. Doe nou niet eigenwijs, haal die vingers uit je oren en luister. HTTP is een pull protocol. Alle verkeer wordt namelijk gestart door de client. Jij wil al je clients binnen een of twee seconden die data op het scherm toveren, hoe nutteloos het ook mag zijn. Dat is niet waar HTTP ooit voor bedacht is, en ook je servers gaan dit niet leuk vinden. Met opzet meerdere servers, want die ga je wel nodig hebben. Maargoed, lekker eigenwijs doen en niet willen luisteren.

[roy-t]

Wat een gesloten hoofden hier, ja het is niet waar het voor bedacht is, maar de TS geeft vrij goed aan waarom hiervoor gekozen is. Ook is mibbit een programma dat prachtig laat zien dat het allemaal prima kan, ik vermoed dat je toch daar naar moet gaan kijken, je wilt geen chat maken, maar zo kun je wel vanuit de server/ client to client berichten versturen die je dan door js kunt laten parsen ofzo zodat er gebeurt wat je wilt.

Qua dataverkeer weet ik niet hoe je zit in mibbit, maar misschien dat moto-moi daar wat meer over kan vertellen?

[Janoz]

roy-t schreef op maandag 02 februari 2009 @ 09:25:
Wat een gesloten hoofden hier, ja het is niet waar het voor bedacht is, maar de TS geeft vrij goed aan waarom hiervoor gekozen is. Ook is mibbit een programma dat prachtig laat zien dat het allemaal prima kan, ik vermoed dat je toch daar naar moet gaan kijken, je wilt geen chat maken, maar zo kun je wel vanuit de server/ client to client berichten versturen die je dan door js kunt laten parsen ofzo zodat er gebeurt wat je wilt.

Qua dataverkeer weet ik niet hoe je zit in mibbit, maar misschien dat moto-moi daar wat meer over kan vertellen?

Wat mibbit doet is in dit topic al lang ter sprake gekomen. Verbinding openlaten eventueel icm pollen. Dit topic staat vol met randvoorwaarden en problemen die je hiermee kunt krijgen. Daarnaast zijn ook de impact van dataverkeer besproken. Je kunt de mensen wel van gesloten hoofden betichten, maar misschien zijn het wel jouw ogen die gesloten zijn .

[Confusion]

Some people have a mind that is so open that their brain has fallen out.

[roy-t]

Janoz schreef op maandag 02 februari 2009 @ 09:49:
[...]

Wat mibbit doet is in dit topic al lang ter sprake gekomen. Verbinding openlaten eventueel icm pollen. Dit topic staat vol met randvoorwaarden en problemen die je hiermee kunt krijgen. Daarnaast zijn ook de impact van dataverkeer besproken. Je kunt de mensen wel van gesloten hoofden betichten, maar misschien zijn het wel jouw ogen die gesloten zijn .

Natuurlijk is het belangrijk om de nadelen/onmogelijkheden van een gebruikte techniek te weten, maar het kan dus wel, en zover ik weet is Mibbit zelfs vrij stabiel. Ik wil natuurlijk niet iedereen betichten van een gesloten hoofd (excuses ). Er staan hier een paar hele behulbzame post van oa moto-moi, maar de meeste laatste posts beginnen met "Doe nu maar gewoon niet!" wat is er mis met experimenteren met deze techniek.

Ook is door TS aangegeven dat er echt goede redenen zijn om dit in een website te doen en niet in (een misschien logischer) java/C#/C++/whatever applicatie

[Janoz]

roy-t schreef op maandag 02 februari 2009 @ 11:29:
[...]


Natuurlijk is het belangrijk om de nadelen/onmogelijkheden van een gebruikte techniek te weten, maar het kan dus wel, en zover ik weet is Mibbit zelfs vrij stabiel. Ik wil natuurlijk niet iedereen betichten van een gesloten hoofd (excuses ). Er staan hier een paar hele behulbzame post van oa moto-moi, maar de meeste laatste posts beginnen met "Doe nu maar gewoon niet!" wat is er mis met experimenteren met deze techniek.

Ook is door TS aangegeven dat er echt goede redenen zijn om dit in een website te doen en niet in (een misschien logischer) java/C#/C++/whatever applicatie

Mwah, echt goede redenen heb ik nog niet gezien. TS zegt dat er redenen zijn, maar zegt niet welke. Het zal niet de eerste keer zijn dat er compleet verkeerde aannames mbt requirements gemaakt worden waardoor oplossingen bedacht worden voor problemen die er eigenlijk helemaal niet zijn.

Verder geven eisen als "Alles moet simultaan zonder een ms vertraging" en "Uit mijn grote duim komen 20 simultane constante gebruikers" mij niet de overtuiging dat er heel uitgebreid over nagedacht is, waardoor ik het niet vreemd vind dat andere gestelde eisen ook in twijfel getrokken worden.

Tot slot geeft TS aan dat het in php moet gebeuren. Daarmee is (vanwege de afwezigheid van een application scope) een oplossing zonder enige vorm van polling per definitie uitgesloten.

[Toolskyn]

Onbekend schreef op maandag 26 januari 2009 @ 21:29:
Kent iemand een of andere techniek die die processortijd beperkt en waarbij de gebruiker "real-time" de data binnenkrijgt?

Om even terug te komen op deze vraag: wat een redelijk effectieve manier is: je maakt een bestandje aan op de server, en elke keer als er iets wordt opgeslagen in de database (wanneer er dus een verandering is) touch je dit bestandje even. In je wachtende script kijk je vervolgens alleen maar naar dit bestandje. Zodra het bestandje een nieuwe wijzigingsdatum krijgt weet je dat er iets veranderd is in de database, kun je dus een verbinding met de database maken en kun je je query uitvoeren.

[Cartman!]

Toolskyn schreef op maandag 02 februari 2009 @ 12:14:
[...]


Om even terug te komen op deze vraag: wat een redelijk effectieve manier is: je maakt een bestandje aan op de server, en elke keer als er iets wordt opgeslagen in de database (wanneer er dus een verandering is) touch je dit bestandje even. In je wachtende script kijk je vervolgens alleen maar naar dit bestandje. Zodra het bestandje een nieuwe wijzigingsdatum krijgt weet je dat er iets veranderd is in de database, kun je dus een verbinding met de database maken en kun je je query uitvoeren.

Hij wil dus niet pollen maar pushen en daar is HTTP niet voor bedoeld. Dan kom je meer uit op Flash- of JAVA-applicatie.

[Janoz]

Toolskyn schreef op maandag 02 februari 2009 @ 12:14:
[...]


Om even terug te komen op deze vraag: wat een redelijk effectieve manier is: je maakt een bestandje aan op de server, en elke keer als er iets wordt opgeslagen in de database (wanneer er dus een verandering is) touch je dit bestandje even. In je wachtende script kijk je vervolgens alleen maar naar dit bestandje. Zodra het bestandje een nieuwe wijzigingsdatum krijgt weet je dat er iets veranderd is in de database, kun je dus een verbinding met de database maken en kun je je query uitvoeren.

Blijft pollen. Je zit constant de schijf te bekijken of het bestandje veranderd. Een variabele in applicatiescope lijkt mij veel makkelijker. Met php zul je dan naar shared memory oplossingen moeten kijk. Zou je echter een platform als bv Java of .NET gebruiken dan hoef je niet meer te pollen. Daar is de applicatie en sessie scope meer dan enkel data en kun je vanuit het ene request aanpassingen doen in de thread die bij een ander request of sessie hoort.

[Zoijar]

De grote overhead tov een applicatie is dat je voor elk request een thread moet afsplitsen, een connectie openen en sluiten, en alle http headers ontvangen en terug sturen. Verder is het ongeveer hetzelfde, want een applicatie moet ook al zijn connecties open houden.

Wat je dus moet proberen is om de connecties niet te sluiten en incrementeel data te ontvangen. Geen eof sturen vanuit je server dus, en een hele lange time-out op je client connectie. Dan asynchroon data lezen op je client. Server threads moeten sleepen op events en ze dan (na eventueel een x-aantal events te batchen) op de lijn zetten. Clients die events sturen naar de server hebben ook overhead. Daar is het lastig om je connectie open te houden oid. Je kan wel data met je request meesturen, maar ik denk niet dat je php script dat krijgt voordat de request klaar is. Al met al denk ik dat je het best wel efficient zou kunnen implementeren. Het hoeft niet per se veel trager te zijn. Het is wel ingewikkelde code...

Ik weet niet wat je precies wilt doen, maar je kan ook nog client-side en server-side prediction gebruiken. Als je bv een bewegende muiscursor wilt tonen, dan kan je best wat minder vaak samplen en de tussenliggende posities predicten.

[ Voor 10% gewijzigd door Zoijar op 02-02-2009 13:03 ]

[r0b]

Cartman! schreef op maandag 02 februari 2009 @ 12:43:
[...]

Hij wil dus niet pollen maar pushen en daar is HTTP niet voor bedoeld. Dan kom je meer uit op Flash- of JAVA-applicatie.

Hm; Facebook's oplossing is m.i. wel redelijk in dat opzicht.
Linkje hierover: http://highscalability.co...illion-users-using-erlang

[ Voor 8% gewijzigd door r0b op 02-02-2009 13:11 ]

[Cartman!]

Alleen is dat sowieso al geen PHP zoals de TS vraagt

Even snel doorgekeken maar ze werken in feite met een doorlopende http verbinding. Zij hebben daar wel servers voor maar ik gok zo dat de TS dit niet heeft

Blijf nog steeds staan dat de TS het verhaal over de concurrent users en de exacte reden waarom er geen 2ms vertraging in mag zitten niet goed kan/wil onderbouwen. Sowieso blijf je altijd met n beetje lag zitten, realtime over internet blijft lastig

[ Voor 79% gewijzigd door Cartman! op 02-02-2009 13:16 ]

[Onbekend]

Na lang uitzoeken en proberen ben ik tot de conclusie gekomen dat het voorbeeld van http://www.devpro.it/xmlsocket/ niet werkt.
Ik heb de code aan de hand van andere voorbeelden op internet inmiddels aangepast, en de communicatie werkt zoals ik het hebben wil. Hoewel hierbij wel van flash gebruik gemaakt wordt, is het voor de gebruiker niet storend en kan ik eenvoudig met Javascript verder werken.
Tot nu toe lijkt het script de processor nauwelijks te belasten, en er is (vrijwel) realtime communicatie mogelijk tussen drie clients. Ik tot nu toe nog niet méér kunnen testen dan dit, maar het ziet er in ieder geval goed uit.

@hierboven: Ik weet niet waar je die 2ms vandaan haalt, want dit is namelijk al een netwerkvertraging.
Zoals ik al eerder heb gezegd is om de 5 seconden pollen veel te langzaam, en ik moest dus iets anders verzinnen dan continu pollen omdat het anders veel te veel dataverkeer kost.

En natuurlijk weet ik dat http er in eerste instantie niet voor bedoeld is, maar dat is met meer dingen zo.

[RobIII]

Onbekend schreef op maandag 02 februari 2009 @ 18:13:
En natuurlijk weet ik dat http er in eerste instantie niet voor bedoeld is, maar dat is met meer dingen zo.

offtopic:
En dan gewoon net zo lang met een moker er op rammen tot 't doet wat je wil Wees maar blij dat je nu voor een betere manier hebt gekozen Of het 'de beste' manier is durf ik niet te zeggen; ik ken de randvoorwaarden niet en wellicht is het Flash-vereiste wel een probleem... Oh; en ik ken de ins-en-outs niet van XMLSocket (en ook geen tijd voor nu); ik weet niet hoe het server-side wordt opgelost dus daar doe ik geen uitspraken over.

[ Voor 28% gewijzigd door RobIII op 02-02-2009 18:18 ]

[AndriesLouw]

Iets wat ik recentelijk ben tegengekomen, en wellicht nuttig voor jou kan zijn:
http://cristian.nexcess.net/ajax/whiteboard/

Bijna realtime, en voorzien van genoeg achtergrond informatie.

[RobIII]

AndriesLouw schreef op maandag 02 februari 2009 @ 18:40:
Iets wat ik recentelijk ben tegengekomen, en wellicht nuttig voor jou kan zijn:
http://cristian.nexcess.net/ajax/whiteboard/

Bijna realtime, en voorzien van genoeg achtergrond informatie.

Ik zie daar anders ook gewoon een poll om de seconde

[Verwijderd]

Je zou evt onder aan je pagina gewoon een oneindige loop kunnen zetten. Je zou zelfs de loop in een iframe kunnen zetten. Nou is een query in een loop niet het beste ding, dus je kan hem misschien gewoon naar een socket laten luisteren.

Je zult even met de juiste "flush" headers moeten rommelen, maar daar kom je vast wel uit.

code:

<?php
ob_implicit_flush(true);
ob_end_flush();

// Do some fancy actions here:
connect_to_databases_etc();

?>
<html>
<head>
    <title>mySite</title>
</head>
<body>
    <div id="myDiv">Default Content.</div>
</body>
<html>
<script type="text/javascript">
<?php 

while(1) {
    $res = mysql_query() or die(trigger_some_error());
    if(mysql_num_rows($res) >= 1) {
        $row = mysql_fetch_row($res);
        print "document.getElementById('myDiv').innerHTML = '{$row[0]}';";
    }
}

?>

Ik ben benieuwd hoe jij het gaat oplossen! succes.

[ Voor 0% gewijzigd door Verwijderd op 02-02-2009 19:04 . Reden: typo! ]

[Voutloos]

Nofi maar die code voegt echt 0.0 toe. De enige relevante regel is while(1) en een continue loop was inmiddels al 20x besproken...

[Niemand_Anders]

1) 27GB traffic voor een website met continue 20 concurrent clients is niet veel. Het is zelfs erg weinig..
Als service voor een aantal financiele websites houden wij via een javascript wat statistieken bij en onze 'stats' server verwerkt elke seconden meer dan 45 requests (juist nu met de financiele krediet crises). Het javascript is 3521 bytes groot en trekt 382 GB per maand. Echter het overzicht gedeelte wat gemiddeld elke 30 minuten een request krijgt (er is voornamelijk een flinke piek aan het einde van de maand) trekt met gemak een 1,5 TB per maand.

2) Welke gebruiker zit erop te wachten elke seconden een bericht te krijgen. Een populaire gebruikers heeft op die manier zelfs niet meer de mogelijkheid om de rest van de website te bezoeken om of te reageren op al die berichten. Waarom verzamel je niet gewoon alle berichten voor een gebruiken en toon je deze bij de volgende requests?

3) .exe updaten lastig? Aangezien .exe bestanden alleen onder windows bestaan, zou je dus ook kunnen kijken naar een vb.net application welke dmv ClickOnce up-to-date wordt gehouden. Een andere mogelijkheid is dat jij een irc-server installeerd op je webserver en dat je bezoekers hun vertrouwde irc lcients zoals mirc kunnen gebruiken. Eventueel zou je zelfs op je website ergens een java applet kunnen plaatsen welke alsnog verbinding legt met de irc-server mocht de gebruiker geen zin hebben om speciaal voor jouw een irc-client te installeren..

[Onbekend]

RobIII schreef op maandag 02 februari 2009 @ 18:15:
[...]

offtopic:
En dan gewoon net zo lang met een moker er op rammen tot 't doet wat je wil Wees maar blij dat je nu voor een betere manier hebt gekozen Of het 'de beste' manier is durf ik niet te zeggen; ik ken de randvoorwaarden niet en wellicht is het Flash-vereiste wel een probleem... Oh; en ik ken de ins-en-outs niet van XMLSocket (en ook geen tijd voor nu); ik weet niet hoe het server-side wordt opgelost dus daar doe ik geen uitspraken over.

Het is niet met een moker er in geslagen, maar ik heb een puzzelstukje op zijn plaats gebracht en andere wat bijgevijld.
Het lijkt er op dat ik pas in het weekend weer tijd heb om er verder mee aan de slag te gaan, dus dan kan ik pas zeggen of het puzzelstukje ook naadloos aansluit op de rest van het geheel.

Niemand_Anders schreef op dinsdag 03 februari 2009 @ 09:30:
1) 27GB traffic voor een website met continue 20 concurrent clients is niet veel. Het is zelfs erg weinig..
Als service voor een aantal financiele websites houden wij via een javascript wat statistieken bij en onze 'stats' server verwerkt elke seconden meer dan 45 requests (juist nu met de financiele krediet crises). Het javascript is 3521 bytes groot en trekt 382 GB per maand. Echter het overzicht gedeelte wat gemiddeld elke 30 minuten een request krijgt (er is voornamelijk een flinke piek aan het einde van de maand) trekt met gemak een 1,5 TB per maand.

Zelf weet ik totaal niet hoeveel dataverkeer de site nodig zal hebben. Door vooronderzoek ben ik er achter gekomen dat pollen heel veel dataverkeer zou kosten. Vandaar dat ik nu al iets anders zocht.

2) Welke gebruiker zit erop te wachten elke seconden een bericht te krijgen. Een populaire gebruikers heeft op die manier zelfs niet meer de mogelijkheid om de rest van de website te bezoeken om of te reageren op al die berichten. Waarom verzamel je niet gewoon alle berichten voor een gebruiken en toon je deze bij de volgende requests?

Zoals ik al aangaf lijkt het op een chatapplicatie. Het heeft geen zin dat een gebruiker steeds op Refresh moet klikken om te kijken of de ander al heeft geantwoord.

3) .exe updaten lastig? Aangezien .exe bestanden alleen onder windows bestaan, zou je dus ook kunnen kijken naar een vb.net application welke dmv ClickOnce up-to-date wordt gehouden. Een andere mogelijkheid is dat jij een irc-server installeerd op je webserver en dat je bezoekers hun vertrouwde irc lcients zoals mirc kunnen gebruiken. Eventueel zou je zelfs op je website ergens een java applet kunnen plaatsen welke alsnog verbinding legt met de irc-server mocht de gebruiker geen zin hebben om speciaal voor jouw een irc-client te installeren..

Het is dus geen chat. De data op het scherm van een cliënt wordt getoond a.d.h. van kleine afbeeldingen, lijnen en kleuren. Ik zou er natuurlijk een chat naast kunnen zetten, maar dat is dus niet het hoofdonderdeel.

[Cartman!]

Je zou ook een irc server kunnen gebruiken voor t heen en weer sturen van de data achter de schermen maar die aan de voorkant dus anders weergeeft. Zodat je dus ook "grafische" data gewoon verstuurt als tekst in de chat aan de achterkant maar dit op de voorkant dus daadwerkelijk grafisch weergeeft.

Bottomline: PHP is niet bedoeld voor dergelijke toepassingen, dat is wat (de meesten) je een beetje willen duidelijk maken... verder denk ik dat je toch beter moet nadenken over de getallen voordat je begint met het stellen van eisen. Hoeveel gebruikers krijg je, hoeveel tegelijk etc. etc. zodat je beter inschattingen kunt maken qua dataverkeer bijv.

[RobIII]

Cartman! schreef op dinsdag 03 februari 2009 @ 22:52:
Bottomline: PHP is niet bedoeld voor dergelijke toepassingen

offtopic:
PHP niet zo zeer; eerder HTTP (en daardoor PHP indirect natuurlijk ook wel)

[BCC]

RobIII schreef op woensdag 04 februari 2009 @ 00:10:
PHP niet zo zeer; eerder HTTP (en daardoor PHP indirect natuurlijk ook wel)

Volgens mij is dat helemaal niet offtopic.

[Cartman!]

Maar aangezien PHP 99,9% van de keren werkt over HTTP heb je er gewoon niks aan dus RobIII

[unclero]

* unclero zou opteren voor het volgende:
XMLHttprequest in javascript voor het ophalen van de server van je spul.
HTTP POST voor het versturen naar de server van je spul.

Makkelijker kan toch bijna niet?

RobIII schreef op dinsdag 27 januari 2009 @ 00:33:
[...]

My idea exactly. Er zijn allerlei leuke 'workarounds', maar HTTP is nou eenmaal een pull-protocol. HTTP-push is 99 v.d. 100 keer ellende, en die ene keer dat 't misschien ("betrouwbaar" *kuch*) werkt tref je nét die ene gebruiker met lynx _{Jaja, ik dik het wat aan...}

Dan heeft ie maar pech gehad.
Bij het ontwikkelen van een website kijken wij altijd: wat gebruikt 80% van de gebruikers?

[RobIII]

unclero schreef op woensdag 04 februari 2009 @ 10:06:
* unclero zou opteren voor het volgende:
Dan heeft ie maar pech gehad.

Dan lees je mijn zin niet goed
Wat ik, met een knipoog, zeg is dat net die ene keer dat alles op orde is je de verkeerde gebruiker treft en dus in 100% van de gevallen ellende hebt

unclero schreef op woensdag 04 februari 2009 @ 10:06:
Bij het ontwikkelen van een website kijken wij altijd: wat gebruikt 80% van de gebruikers?

Dat is nogal een royale marge die jullie nemen! Kijk, realistisch is er gewoon altijd wel ergens een situatie die niet (goed) werkt of niet helemaal doet/rendert wat je wil. Maar 80% vind ik de lat wel érg laag leggen; dat is zo-goed-als IE+FX-only

[ Voor 13% gewijzigd door RobIII op 04-02-2009 10:21 ]

[unclero]

RobIII schreef op woensdag 04 februari 2009 @ 10:18:
Dat is nogal een royale marge die jullie nemen! Kijk, realistisch is er gewoon altijd wel ergens een situatie die niet (goed) werkt of niet helemaal doet/rendert wat je wil. Maar 80% vind ik de lat wel érg laag leggen; dat is zo-goed-als IE+FX-only

Ja... Als het dan een of andere obscure / exotische browser ook werkt, is aardig meegenomen, maar moet je geen rekening mee gaan houden.

[flashin]

RobIII schreef op woensdag 04 februari 2009 @ 10:18:
[...]
Dat is nogal een royale marge die jullie nemen! Kijk, realistisch is er gewoon altijd wel ergens een situatie die niet (goed) werkt of niet helemaal doet/rendert wat je wil. Maar 80% vind ik de lat wel érg laag leggen; dat is zo-goed-als IE+FX-only

Hij bedoelt het niet als in welke-browsers-worden-er-gebruikt, maar in de term van gebruiksvriendelijkheid en interaction design.

- maakt het uit dat er 1s lag op zit?
99% van de mensen weten het niet eens.

80% ie + ff only is m.i. ook niet correct. W3schools bezoekers IE en FF samen in jan '09: 90,2%
http://www.w3schools.com/browsers/browsers_stats.asp

Daarnaast quote ik:

W3Schools is a website for people with an interest for web technologies. These people are more interested in using alternative browsers than the average user. The average user tends to use Internet Explorer, since it comes preinstalled with Windows. Most do not seek out other browsers.

These facts indicate that the browser figures above are not 100% realistic. Other web sites have statistics showing that Internet Explorer is used by at least 80% of the users.

Developen voor IE en FF (en dat is bijna automatisch ook voor chrome) is m.i. als webdeveloper nog steeds voldoende. (Tenzij je een site hebt gericht op de safari-doelgroep)

[ Voor 114% gewijzigd door een moderator op 04-02-2009 11:14 . Reden: Oops... anders edit ik perongeluk een bericht i.p.v. quote... :X ]

[RobIII]

flashin schreef op woensdag 04 februari 2009 @ 11:04:
[...]
Hij bedoelt het niet als in welke-browsers-worden-er-gebruikt, maar in de term van gebruiksvriendelijkheid en interaction design.

Euh, niet zoals ik het lees:

unclero schreef op woensdag 04 februari 2009 @ 11:02:
Ja... Als het dan een of andere obscure / exotische browser ook werkt, is aardig meegenomen, maar moet je geen rekening mee gaan houden.

En waar je reactie verder over gaat zie ik eigenlijk niet...

[ Voor 40% gewijzigd door RobIII op 04-02-2009 11:16 ]

[flashin]

Hartstikke leuk dat je het verder "niet begrijpt". Het bericht typte ik tegelijkertijd met dat hij dat onderste bericht typte, dus daarnaar verwijzen klopt niet.

Ik heb er een beetje overheen gelezen maar ik wilde even reageren op de percentages die je noemde, of ontwikkelen voor lynx nou echt zo belangrijk is.

Nee.

[.oisyn]

Ik zit hier recentelijk ook aan te denken, maar dan voor network support van m'n javascript wolfenstein. Aangezien ik daarvoor een continuë datastroom voor nodig heb, wat voor server->client communicatie wel enigszins kan (met een hidden iframe en chunked encoding), is er voor de client->server communicatie geen andere oplossing dan voor elk event een XMLHttpRequest af te vuren. Die overhead is behoorlijk (zo'n 99%). M'n conclusie was: de huidige mogelijkheden van javascript sucken voor dit doeleinde, ik maak wel een scriptable java applet die een gewone TCP of UDP verbinding naar de server opent.

[Zoijar]

Bij een "geavanceerde" applicatie als dit kan je prima een gebruiker verplichten toch maar even FF te gebruiken (of IE) ipv, zeg, Lynx. (Die 10% die moeilijk doet die start dan maar even een keer een andere browser op, of blijft dwarsliggen en gebruikt je applicatie maar lekker niet.... good riddance )

[ Voor 38% gewijzigd door Zoijar op 04-02-2009 13:00 ]