[PHP][Android] Reverse push

[Stphnvlstk]

Ik ben een momenteel een Android applicatie en bijhorende web interface aan het ontwikkelen, maar ik geraak er maar niet uit hoe ik iet-wat efficiënt vanaf de web interface informatie kan ophalen van het Android toestel.

Meer concreet:

1. Gebruiker vult een search query in op de webpagina
2. Server stuurt query naar Android app (C2DM lijkt me hier aangewezen)
3. App verwerkt de query (in de achtergrond) en returnt data
4. Geretourneerde data wordt meteen zichtbaar op de webpagina

Dit hele proces moet binnen enkele seconden voltooid zijn, en hoe sneller hoe liever. Ik heb denk ik zowat alle mogelijke technieken à la reverse AJAX, Comet, websockets, NowJS, ... gezien, maar ik geraak er niet uit wat ik nu écht nodig heb.

Ik heb momenteel een shared hosting pakket, en daar kan ik jammer genoeg geen NowJS (of vergelijkbare paketten) op installeren. Ook reverse AJAX en Comet lijken me verre van ideaal, aangezien die zoveel resources nodig hebben bij een te groot aantal users.
Dan blijft alleen nog websockets over, maar ik vind maar niet of en hoe ik dat concreet kan implementeren. De voorbeelden op internet werken telkens met javascript clients. Mijn app post echter de data via een gewone POST request naar een .php pagina (die ik de data dan tijdelijk ga laten wegschrijven in een MySQL db denk ik?), daar komt helemaal geen javascript aan te pas. Ben ik nu gewoon nogal kortzichtig bezig, of kan ik websockets inderdaad niet gebruiken? (Ik weet overigens dat websockets nog maar door weinig browsers ondersteund wordt, maar dat neem ik er wel bij.)

Ik ben uit wanhoop aan het overwegen om over te stappen op een VPS pakket, maar aangezien het project nog wel een tijdje in beta zal zijn vind ik het zo zonde om daar zoveel geld aan uit te geven. (En ik heb ook helemaal geen ervaring met server management )

Alvast bedankt voor jullie input!

[Icekiller2k6]

Dit lijkt me toch echt een gevalletje Ajax + php niet?

ook al zeg je dat dat niet ideaal is..

je hebt een zoekveld met een button button hangt vast aan een javascript, die dan een met mootools of jquery de info ophaalt van een php pagina (dus javascript geeft text field value mee aan de php pagina..) deze data krijgt javascript terug.. en dit vul je dan in in een css div.

waar loopt het precies mis volgens jou?

dit verbruikt aan server kant niet meer of minder of je effectief naar de php pagina gaat die hij oplaad
bv
http://www.w3schools.com/php/php_ajax_database.asp

dit is met een listbox maar zoekveld & button is ongeveer hetzelfde behalve dat selectedItem variabel is


als het echter een native app is:
http://inchoo.net/mobile-...ask-and-the-ajax-analogy/

[ Voor 34% gewijzigd door Icekiller2k6 op 05-05-2011 02:57 ]

[Stphnvlstk]

Nee, ik denk het niet. De informatie kan niet zomaar opgehaald worden, die moet eerst door de Android applicatie verwerkt en verstuurd worden. Wanneer die informatie terug toekomt op de server is onduidelijk (C2DM werkt niet met gewone POST requests waarbij meteen data terugkomt ofzo, de communicatie verloopt maar in 1 richting), en elke second (o.i.d.) pollen lijkt me verre van ideaal qua server load.

edit: even de links van je edit bekijken

[ Voor 5% gewijzigd door Stphnvlstk op 05-05-2011 02:58 ]

[alwinuzz]

Stphnvlstk schreef op donderdag 05 mei 2011 @ 02:57:
[...] en elke second (o.i.d.) pollen lijkt me verre van ideaal qua server load.

Meten is weten. Waarom doe je niet eerst de makkelijkste oplossing (pollen?), en dan kijken hoe het met de load zit?

[Stphnvlstk]

Ik heb met m'n huidig pakket maar maximaal 30 gelijktijdige verbindingen. Aangezien de app wel vrij regelmatig verbinding maakt met de server wil ik voor de rest het aantal connecties zo laag mogelijk, anders moet ik vrijwel meteen na de eerste toestroom van users al van concept veranderen.. voor zover ik begrepen heb stelt dat probleem zich niet met websockets?

[alwinuzz]

Geen idee, ik heb even gezocht op 'websockets open connection' en het lijkt alsof websockets een open verbinding houden, dus dan zou je maar 30 gebruikers kunnen hebben? Lijkt polling me handiger. Keep it simple

Hoeveel gebruikers denk je te gaan halen als je je nu, zonder te meten, al druk maakt over de server load?

Als de load te hoog wordt/teveel connecties, dan kan je je host vragen of die instelt dat er meer verbindingen open mogen zijn, of je gaat alsnog naar een VPS. Dan kan je nu eerst je app afmaken, en als het nodig is pas het load probleem.

edit: met websockets zelf kan ik je helaas niet helpen. Succes

[ Voor 4% gewijzigd door alwinuzz op 05-05-2011 03:43 ]

[Stphnvlstk]

Ik hoop op middellange termijn ongeveer 10.000 users te hebben, wat niet onnoemelijk veel is maar imo toch genoeg om op een ietwat zuinige manier met resources om te gaan. Waarschijnlijk bezie ik het nu inderdaad wel allemaal wat te groots en is polling inderdaad m'n beste keuze, maar moest iemand toch nog weten hoe ik het met websockets kan doen hoor ik het graag!

[Gomez12]

Ik zal waarschijnlijk het hele concept niet snappen.

Maar ik voer dus ergens op een desktop pc in een browser iets in, en dan moet mijn android telefoon zoeken en het wat mijn telefoon vindt, dat krijg ik via-via terug in mijn desktop-browser?

En dan gaat jouw vraag over hoe je op de server het antwoord van de android terugkrijgt binnen een redelijke termijn?

Of ik zie het concept verkeerd of het lijkt me schier onmogelijk met alle technieken die je noemt. Elke polling kost data-verkeer aan de client kant, ik weet niet of mensen zitten te wachten op 24/7 data-verkeer...
Traditionele server-side push is afaik ook niet universeel makkelijk te doen (je hebt geen vast (ip)adres waarheen de server iets kan sturen)

Ik zou gewoon voor de grap eens kijken op wat techblogs van bijv een whatsapp, die hebben het push-mechanisme wel werkend. Maar eerlijk gezegd heb ik geen idee hoe (alhoewel ik vermoed dat het geen polling is)

Maar als je 10.000 gebruikers verwacht dan kan je toch ook gewoon nu een investering doen in een VPS oid als je bij je hosting provider tegen problemen aanloopt?

[Verwijderd]

Je zou ook eens kunnen kijken naar het implementeren van en RESTful web service. Je kan dan ook gemakkelijk data vanaf je Android app laten opslaan. RESTful authenticatie er tussen met behulp van ssl, een extra token en dan is de data overdracht tussen client en server ook "veilig".

[Tim]

De server stuurt via C2DM een query. De applicatie verwerkt die en stuurt het resultaat terug via een POST naar een php pagina.

Dat is wat je nu hebt? Wat vind je dat daar mis mee is?

[Stphnvlstk]

Gomez12 schreef op donderdag 05 mei 2011 @ 07:16:
Ik zal waarschijnlijk het hele concept niet snappen.

Maar ik voer dus ergens op een desktop pc in een browser iets in, en dan moet mijn android telefoon zoeken en het wat mijn telefoon vindt, dat krijg ik via-via terug in mijn desktop-browser?

En dan gaat jouw vraag over hoe je op de server het antwoord van de android terugkrijgt binnen een redelijke termijn?

Klopt!

Gomez12 schreef op donderdag 05 mei 2011 @ 07:16:
Elke polling kost data-verkeer aan de client kant, ik weet niet of mensen zitten te wachten op 24/7 data-verkeer...

Er is ook helemaal geen 24/7 dataverkeer! Enkel wanneer de gebruiker een search query ingeeft op de website moet er gepolld (wel, of dus liefst iets anders) worden.

Gomez12 schreef op donderdag 05 mei 2011 @ 07:16:
Traditionele server-side push is afaik ook niet universeel makkelijk te doen (je hebt geen vast (ip)adres waarheen de server iets kan sturen)

Het gebrek aan vast ip-adres lijkt me niet echt een obstakel. Bij het versturen van de search query kan het IP adres tijdelijk opgeslagen worden.

Gomez12 schreef op donderdag 05 mei 2011 @ 07:16:
Ik zou gewoon voor de grap eens kijken op wat techblogs van bijv een whatsapp, die hebben het push-mechanisme wel werkend. Maar eerlijk gezegd heb ik geen idee hoe (alhoewel ik vermoed dat het geen polling is)

Ik vermoed dat zij (net als Facebook chat bvb) gebruik maken van Erlang. Dat implementeren is op m'n huidige hosting sowieso onmogelijk, en zelfs moest het wel mogelijk zijn zou het mij wel enorm veel extra werk opleveren.

Gomez12 schreef op donderdag 05 mei 2011 @ 07:16:
Maar als je 10.000 gebruikers verwacht dan kan je toch ook gewoon nu een investering doen in een VPS oid als je bij je hosting provider tegen problemen aanloopt?

Houdt inderdaad steek, maar voor hetzelfde geld flopt het project helemaal en komt er geen kat op af. Een paar honderd euro is voor de gemiddelde webdeveloper waarschijnlijk geen onoverkomelijke ramp, maar ik ben gewoon een student met een idee, en niet al teveel geld (en ervaring). Van zodra de zekerheid er is wil ik gerust meer investeringen doen, maar nu ben ik daar niet meteen toe geneigd.

Verwijderd schreef op donderdag 05 mei 2011 @ 07:31:
Je zou ook eens kunnen kijken naar het implementeren van en RESTful web service. Je kan dan ook gemakkelijk data vanaf je Android app laten opslaan. RESTful authenticatie er tussen met behulp van ssl, een extra token en dan is de data overdracht tussen client en server ook "veilig".

Net opgezocht over REST, had er nog nooit van gehoord, lijkt interessant! Als ik het goed begrijp is REST echter geen oplossing voor mijn push probleem - hoewel het de server load wel kan verminderen. Correct?

Tim schreef op donderdag 05 mei 2011 @ 12:41:
De server stuurt via C2DM een query. De applicatie verwerkt die en stuurt het resultaat terug via een POST naar een php pagina.

Dat is wat je nu hebt? Wat vind je dat daar mis mee is?

Die php pagina zou de verkregen data nog moeten doorpushen naar de browser van de gebruiker (of laten weten dat nieuwe data beschikbaar is). Aangezien (long-)polling een niet zo heel propere manier van werken is, zou ik graag websockets o.i.d. implementeren, dat véél zuiniger zou werken.

Bedankt voor de input allemaal!

[Icekiller2k6]

Aanbieden van diensten is hier niet toegestaan, hoe goed het waarschijnlijk ook bedoeld is

[ Voor 61% gewijzigd door Woy op 05-05-2011 15:13 ]

[Verwijderd]

Als ik het probleem begrijp dan ben je opzoek naar iets wat Chrome2Phone ook gebruikt.

Hierbij is het mogelijk om de URL van je browser door te sturen naar je Android apparaat.

Hoewel ik totaal geen kennis van de code heb (of de technieken), lijkt het mij een interessant project waar je misschien wat ideeën uit kan opdoen.

[Stphnvlstk]

Chrome2Phone pusht slechts in 1 richting, van Chrome naar de gsm d.m.v C2DMessaging. Dat vormt helemaal geen probleem, het gaat echter om de informatie die van de gsm terug naar de browser moet gaan.

[voodooless]

Ik zou het niet moeilijker maken dan het is:

1. user voert query in in browser
2. webserver krijgt query en zet deze klaar voor ontvangende telefoon in een database, en blijft vervolgens de database pollen tot er een antwoord is of timeout (of je doet dat async met ajax bende ofzo)
3. android telefoon laat je dmv long polling wachten op een query om uit te voeren. Krijg je een query, voer je die uit en stuur je het resultaat terug naar de server. Wil je dit efficiënter maken kun je ook websockets of gewone sockets gebruiken, maar dat is zeer zeker meer werk.
4. server update de in de database staande query met het resultaat
5. user krijgt resultaat te zien omdat server telefoon klaar is met zijn request (of omdat de browser via ajax naar het resultaat pollt).

done

[Janoz]

@voodooless: Je stappenplan is leuk, maar niet relevant. De situatie nu is de volgende:

1: User voert een query in op de website
2: de webserver stuurt de opdracht via C2DM naar de telefoon

3: De telefoon submit het resultaat van de query naar de server middels een post.
4: Gebruiker moet resultaat op de website te zien krijgen.

Als ik de TS goed begrijp zit het probleem er voornamelijk in dat de actie bij punt 3 niet makkelijk op het bij punt 1 genoemde request in kan haken en dat er dus een andere manier gebruikt moet worden om de website bezoeker op de hoogte te brengen van het resultaat.


@topicstarter: Hoe snel moet het resultaat op het scherm komen? Is het belangrijk dat het zo instantaan mogelijk is? Als je gewoon (middels ajax) om de seconde of de halve seconde gaat pollen (en dan natuurlijk niet een complete pagina, maar gewoon iets korts teruggeeft) dan hoeft de polling load absoluut niet zwaar te worden.

[ Voor 21% gewijzigd door Janoz op 05-05-2011 20:15 ]

[voodooless]

Dat is toch precies wat ik beschreven heb? Of je nu C2DM, long polling, sockets of whatever gebruikt maakt toch niet uit..


stukje code van de webserver na submitten van query

JavaScript:

// hier zet je de query klaar voor een telefoon om af te handelen
var id = putQueryInDatabase("ik zoek oude sokken?");
var result = "pending";
while(true || timeout()){
   // hier wacht je op resultaat van de telefoon
   result =getQueryResult(id);
   if(result == 'done'){   
     // hier return je
     doResultToBrowser();
      return;
   }
   if(result == "error"){
      break;
   }
}
// hier gaat het fout
doErrorToBrowser();

[ Voor 68% gewijzigd door voodooless op 05-05-2011 20:20 ]

[Knutselsmurf]

Volgens mij is dat prima iets dat met pollen is op te lossen. Ik neem ten minste aan dat de tijdsperiode tussen stap 2 en 3 in het overzichtje van Janoz relatief kort is. Dan is er maar een kleine periode waarin actief bij de server om data gezeurd moet worden. Is die data binnen, dan kan er gestopt worden met pollen, totdat er een nieuwe query gestart wordt

[Janoz]

Het probleem is inderdaad de asynchroniteit, maar het is echter andersom. Je oplossing gaat uit van een situatie waarbij een telefoon constant gaat kijken naar een klaarstaande query op de server. C2DM werkt echter andersom. Daarmee kun je keurig een bericht sturen naar een telefoon, maar daarbij krijg je niet gelijk het resultaat terug. De server zal moeten wachten tot de telefoon (via POST) zijn resultaat teruggemeld heeft. Het poll probleem is juist tussen de server en de webbrowser.

[ Voor 6% gewijzigd door Janoz op 05-05-2011 20:20 ]

[voodooless]

Ik zie het probleem niet..

* telefoon krijgt query (hoe dan ook)
* telefoon post resultaat terug (hoe dan ook)

[Gomez12]

Stphnvlstk schreef op donderdag 05 mei 2011 @ 17:59:
Chrome2Phone pusht slechts in 1 richting, van Chrome naar de gsm d.m.v C2DMessaging. Dat vormt helemaal geen probleem, het gaat echter om de informatie die van de gsm terug naar de browser moet gaan.

Dan is er toch geen probleem?
- Je kan dan data versturen van server naar gsm via C2DMessaging.
- Je pakt op de gsm de data op, doet er je bewerking mee en als laatste actie roep je een php-script op met wat post-waardes ( en authenticatie en .. en ... )

Van gsm naar browser zie ik geen probleem, dat is simpelweg van gsm een server-side script aanroepen welke de browser weer van de server afhaalt via ajax.

Even stapsgewijs :
1 - Browser surft naar pagina en geeft zoekwaarde in.
2 - Server ontvangt zoekwaarde en verstuurt een C2DMessaging bericht naar een telefoon en tegelijktertijd verwijst het de browser naar een ajax-pagina die om de x tijd server pollt voor antwoord.
3a - Browser pollt rustig door
3b - Telefoon verwerkt het verzoek en stuurt via een post-request de data terug naar server
4 - Server heeft opeens een antwoord voor de pollende browser en verwijst de browser naar de antwoord pagina die niet meer pollt.

Shared hosting moet nog steeds xxxx requests per seconde aankunnen en met polls van 1x per 0.5 sec oid gok ik dat je zelfs met een veelvoud van 10.000 bezoekers niet aan de 500 gelijktijdige bezoekers op de poll pagina zit. Zoals ik het nu voorstel is je pollpagina iets van 0,01% (qua tijd) waar de gebruiker op zit.
Het intikken van de searchquery en het lezen van de respons is voor de gebruiker echt iets van 99% van de tijd

Ik zou zeggen, bouw het eerst. Gooi er een test-programma tegenaan en ga dan eens kijken waar de pijnpunten zitten. Treden er pijnpunten op bij 10.000 gelijktijdige gebruikers, dan kan je altijd nog kijken of je eerst wil beginnen met iets van een max van 5.000 gebruikers om daarna over te gaan op andere hosting (dan heb je als het goed is al inkomsten) of investeer direct in andere hosting als je heilig overtuigt bent dat je 10.000 gebruikers haalt.

[Verwijderd]

Stphnvlstk schreef op donderdag 05 mei 2011 @ 14:18:
Net opgezocht over REST, had er nog nooit van gehoord, lijkt interessant! Als ik het goed begrijp is REST echter geen oplossing voor mijn push probleem - hoewel het de server load wel kan verminderen. Correct?

Correct.

Je kan push eventueel ook doen via een oplossing als http://www.pubnub.com/.

[Gomez12]

Verwijderd schreef op donderdag 05 mei 2011 @ 23:08:
[...]
Correct.

Je kan push eventueel ook doen via een oplossing als http://www.pubnub.com/.

Maar waar moet het push-gedeelte dan voorkomen? Het enige echte push wat ik zie is van server naar gsm en dat kan schijnbaar via C2DMessage.
De rest is of posten of ajax-polling. Die gaan vervangen met push is imho premature optimalisation als een nieuw-hosting account al te veel gaat kosten.

Push in een stateless omgeving (http) is duur en moeilijk, het heeft wel zijn voordelen. Maar ajax-polling en simpelweg fatsoenlijke hosting levert volgens mij in het door mij geschetste plaatje meer bang for the buck.

[Icekiller2k6]

Ik heb dit naar een PM naar topicstarter gestuurd.

statische html pagina maken aan de hand van een unieke sessionid, deze heeft maar 1 getal 0 of 1.
Als het 1 is gaat hij de informatie ophalen anders wacht hij ..

Als query voor sessionid uitgevoerd is -> statische pagina op 1 zetten.
Dit in combinatie met een queue systeem in het achterliggend systeem voor sql queries uit te voeren.

[ Voor 10% gewijzigd door Icekiller2k6 op 06-05-2011 00:13 ]

[Gomez12]

Icekiller2k6 schreef op vrijdag 06 mei 2011 @ 00:13:
Ik heb dit naar een PM naar topicstarter gestuurd.

statische html pagina maken aan de hand van een unieke sessionid, deze heeft maar 1 getal 0 of 1.
Als het 1 is gaat hij de informatie ophalen anders wacht hij ..

Als query voor sessionid uitgevoerd is -> statische pagina op 1 zetten.
Dit in combinatie met een queue systeem in het achterliggend systeem voor sql queries uit te voeren.

Waarom wil je gelijk caching gaan invoeren op een dynamisch stuk?
Waar is de behoefte hiervoor?
Valt er niet een algemener caching systeem te verzinnen / implementeren ipv voor elke pagina het wiel opnieuw uit te vinden?

Gewoon maar even wat vraagjes hoor. Jouw oplossing is simpelweg een vorm van caching enkel dan niet generiek maar puur voor 1 pagina. Leuk hobby-bob gehalte, maar op de langere duur niet echt onderhoudbaar imho.

[Terranca]

Voor mijn twee centen zou ik zeggen, keep it simple. Dus zoals al eerder is gezegd 2 interacties: browser <-> server en server <- c2dm -> android. Zou zeker geen openstaande verbindingen houden tussen je server en Android of de Android gaan zitten pollen. Die verbindingen zijn nogal eens instabiel en kunnen op zich laten wachten.

Browser doet query, Server slaat deze op in een db (zoekactie [id, status, resultaat, timestamp]) en stuurt dmv c2dm het commando naar de android. Server returnt het zoekactie id zodat de browser de zoekactie kan volgen. Dan kan je een scherm laten zien met 'Sending query to phone...' oid.

Afhankelijk van je voorkeuren en beschikbaarheid van technieken kan je dan websockets, long polling, etc opzetten tussen browser <-> server, waarbij alleen wordt gekeken of de database-rij met een bepaald zoekactie id een veranderde status heeft, wat een zeer simpele low-load query is die absoluut geen probleem mag zijn, ook niet als het elke seconde door 10% van je totale app gebruikers gedaan wordt (en dat is een probleem dat je graag wil hebben; dan kan je gaan kijken naar database replicatie of speciale databases die goed zijn in veel reads/sec -- een nosql datastore bijvoorbeeld).

Aan de andere kant heb je een android telefoon die het commando krijgt, ergens in de achtergrond uitvoert, en when done, opstuurt naar de server, welke op zijn beurt het resultaat opslaat in de zoekactie tabel.

Eerstvolgende keer dat de browser de server pollt, kan je het resultaat terugsturen en laten zien aan de gebruiker.

Als ik het zou implementeren zou ik het doen in Node.JS met Socket.IO voor realtime push van browser <-> server ipv de polling, als de browser dat ondersteunt. Maar dan zal je wel van je shared hosting af moeten stappen. Dat kan trouwens heel goedkoop, heb zelf vps bij linode voor $20/maand (~12E) die per maand opzegbaar is. Probeer verder ook niet alles voor 100% uit te stippen. Try and fix what doesn't work, is vaak veel leerzamer. Veel succes in ieder geval

[Janoz]

Gomez12 schreef op donderdag 05 mei 2011 @ 23:31:
[...]

Maar waar moet het push-gedeelte dan voorkomen?

Van de server naar de webbrowser op het moment dat de telefoon zijn gegevens aan de server gemeld heeft.

[Gomez12]

Janoz schreef op vrijdag 06 mei 2011 @ 13:27:
[...]

Van de server naar de webbrowser op het moment dat de telefoon zijn gegevens aan de server gemeld heeft.

Wat is dan precies de meerwaarde van push boven alle andere methodes?
Het opzetten van push is schijnbaar veel moeilijker dan TS met de huidige mogelijkheden makkelijk kan implementeren, oftewel wat is nu echt de meerwaarde boven een simpeler te implementeren techniek?

[Janoz]

Gomez12 schreef op vrijdag 06 mei 2011 @ 15:23:
[...]

Wat is dan precies de meerwaarde van push boven alle andere methodes?

Niks, maar de topicstarter denkt dat het te zwaar wordt. En omdat bijna iedereen in dit topic denkt dat het om het verkeer tussen de server en de telefoon gaat (terwijl het in werkelijkheid gewoon een simpel asynchroon probleem is waarbij de webserver iets wil pushen naar de webbrowser) sneeuwen de opmerkingen waarin wordt gezegd dat het pollen helemaal geen probleem hoeft te zijn helemaal onder.

[Stphnvlstk]

Geweldig bedankt voor de input allemaal, ik heb hier veel bijgeleerd. Blijkbaar was mijn mening over polling toch iets te negatief, het lijkt me dat ik me momenteel beter focus op hoe ik zo efficiënt mogelijk kan pollen, in plaats van er alternatieven voor te zoeken. Van zodra de userbase dan groot genoeg is schakel ik over op vps (of dedicated! ) en bijhorende nieuwe pushtechnieken.

[Makkelijk]

Ik krijg een beetje een [url=It's a Problem When It's a Problemhttp://gettingreal.37signals.com/ch04_Its_a_Problem_When_Its_a_Problem.php]It's a Problem When It's a Problem[/url] gevoel bij dit topic, maar dat zie je nu zelf ook

Als je ooit verdrinkt in het succes (vergeet niet dat de meeste systemen pollen, dit forum volgens mij ook ), of gewoon wilt pushen omdat je het leuk vind, kan je denk ik het beste naar dedicated push webservers kijken. Die zijn in tegenstelling tot apache geoptimaliseerd voor een groot aantal slapende connecties. Apache doet het gewoon heel slecht daarmee, daarom vinden webhosters het ook niet zo leuk

[ Voor 67% gewijzigd door Makkelijk op 08-05-2011 11:20 ]

[Verwijderd]

Janoz schreef op vrijdag 06 mei 2011 @ 15:57:
[...]

Niks, maar de topicstarter denkt dat het te zwaar wordt. En omdat bijna iedereen in dit topic denkt dat het om het verkeer tussen de server en de telefoon gaat (terwijl het in werkelijkheid gewoon een simpel asynchroon probleem is waarbij de webserver iets wil pushen naar de webbrowser) sneeuwen de opmerkingen waarin wordt gezegd dat het pollen helemaal geen probleem hoeft te zijn helemaal onder.

Misschien dat dit komt omdat de rest geen problemen ziet in het versturen van de telefoon naar de browser.

Nu ik het "probleem" (eindelijk) snap, is de oplossing eigenlijk heel simpel:

1) gebruiker plaats request in de browser
2) request wordt opgeslagen op de server (adhv unieke ID)
3) request wordt verstuurd naar toestel (met C2DM, of welke techniek dan ook)
4) app op toestel stuurt data naar server (simpele POST naar PHP script)
5) browser controleert of de data is ontvangen (pollen met AJAX, dit is bijna verwaarloosbaar qua performance)
6) browser haalt data op van server en toont dit aan de gebruiker

Als je de database wilt ontzien (bij het pollen) kun je stap 2 en 5 in een losse tabel zetten met alleen de unieke request ID en de status van het request, welke wordt verwijderd wanneer de gebruiker de informatie heeft binnengehaald.

Op deze manier kun je zonder problemen een groot aantal gebruikers afhandelen, zonder dat je in de problemen komt. Je kunt de AJAX request dan aanpassen qua tijd afhankelijk van de serverload en de snelheid van de request naar het toestel zelf (bv. eerste pol pas na 5 seconden, daarna elke seconde).

[Janoz]

Verwijderd schreef op maandag 09 mei 2011 @ 09:52:
Misschien dat dit komt omdat de rest geen problemen ziet in het versturen van de telefoon naar de browser.

Dus verzinnen ze er maar 1tje bij?

[FragFrog]

Stphnvlstk schreef op vrijdag 06 mei 2011 @ 15:58:
Blijkbaar was mijn mening over polling toch iets te negatief, het lijkt me dat ik me momenteel beter focus op hoe ik zo efficiënt mogelijk kan pollen, in plaats van er alternatieven voor te zoeken

Mwoach, op zich is er weinig mis met pushen. Zelf heb ik een klein jaar geleden al eens gekeken naar WebSockets, een server geschreven in JAVA die verbindingen kan accepteren (vooral als vingeroefening hierin, er zijn ook kant-en-klare paketten voor en het handshake protocol is nogal dramatisch) en prestaties zijn erg goed - ik gebruik het voor een multiplayer RTS en er zit nagenoeg geen lag tussen spelers (op een lokaal netwerk).

Grootste nadeel is echter wel dat momenteel (voor zover ik weet) alleen Chrome native ondersteuning biedt: Safari, Firefox en Opera hebben support voor WebSockets wel ingebakken maar default uitstaan (twijfels over de veiligheid ervan), IE7 en IE8 ondersteunen het niet en van IE9 weet ik niet of die het inmiddels wel kan, maar het zou me enigszins verbazen. Wel zijn er client libraries beschikbaar die proberen terug te vallen op alternatieven middels Flash, JAVA applets en als laatste redmiddel long-polling. Geen ervaring mee, maar wellicht nuttig om naar te kijken

Verwijderd schreef op maandag 09 mei 2011 @ 09:52:
[...]
(pollen met AJAX, dit is bijna verwaarloosbaar qua performance)
[...]

Te kort door de bocht. Als TS een applicatie heeft die binnen ~1s moet reageren betekent het minimaal 1 request / seconde voor elke gebruiker die momenteel een query heeft uitstaan. Als de queries zelf een seconde of vijf duren (willekeurig getal tbv dit voorbeeld) doe je vijf keer zoveel requests als nodig is. Om nog maar te zwijgen over de stateless nature van een XMLHttpRequest, elke keer dat er eentje binnenkomt moet je weer opnieuw je context opbouwen (inclusief access validatie, data initialisatie, etc). Met een push techniek als bijvoorbeeld WebSockets hoeft dat allemaal niet en krijg je een betere responsetijd (ik haal makkelijk < 0.1s) tegen een lagere load (mits efficient toegepast uiteraard). Natuurlijk, het zijn doorgaans simpele en korte requests, maar als je er maar genoeg van genereert krijg je elke server wel op z'n knieeen.

[ Voor 28% gewijzigd door FragFrog op 09-05-2011 11:39 ]