[Java of Flash] Bijna realtime programma

[Verwijderd]

Een beurs gerelateerde applicatie, die ben ik van plan te maken. Alleen het probleem is welke technologieen gebruik ik hiervoor.

In het kort heeft m'n applicatie de volgende structuur:
client vraagt een server om informatie -> server stuurt nieuwe informatie -> client parsed nieuwe informat en geeft de informatie weer.
De server staat op het internet en de client is verbonden met het internet.
Mijn voorkeur gaat uit naar iets wat in een browser te starten is.

Ik heb wat rond gekeken en ben op de volgende technologieen gestoten:
- java (webstart of applet) <- vereist java plugin
- activex <- vereist goede instellingen + Internet Explorer
- flash <- vereist flash plugin

Activex valt vrijwel zeker af omdat het nogal wat problemen (instellingen, externe progs, IE only, enz.) met zich mee brengt. Dan blijft java en flash over. Met java is het goed mogelijk, je kunt namelijk een socket openen en een constante verbinding met een server onderhouden.

Dan hebben we nog flash, ik heb niet veel kaas gegeten van flash / actionscript maar ik zag in dat er xmlsocket was voor flash. xmlsocket kan schijnbaar ook niet xml ontvangen (vreemde naam dan die xmlsocket ).

Maar wat ik me afvraag is of xmlsocket voldoet om snel (zo rond de 250 msec, kan ook 500msec zijn) een server te pollen en eventueel informatie op te vragen/parsen. Zoals eerder aangegeven ben ik redelijk nieuw met flash, daarom kan ik niet zo een flash test programmatje in elkaar flansen zoals ik dat bij java heb gedaan.

[Bosmonster]

Flash is ideaal voor dit soort dingen, gezien de beschikbaarheid en het kleine formaat van de plugin.

Waarom je dat 4x per seconde zou willen updaten weet ik niet, dat lijkt me wat veel voor dit soort dingen. De gebruiker mist het niet als je het 1x per seconde doet en dat scheelt je wel een factor 4

[Verwijderd]

Je kunt nog wat andere uitdagingen beschouwen dan alleen welke plugin je nodig hebt. Ik zou in iedergeval de keuze van de taal niet daarvan laten afhangen, immers een plugin downloaden moet je toch. Wat me interressanter lijkt de manier van communiceren. Je kunt inderdaad de client om de zoveel tijd een verzoek laten plaatsen voor nieuwe informatie. Met heel veel clients is dit een zeer intensieve belasting van je server omdat ook heel vaak dezelfde informatie wordt opgevraagd.

Vandaar dat je het ook kunt omdraaien, zorg dat de server berichten stuurt naar actieve clients. in dat geval wordt de keuze misschien al makkelijker.

Volgens mij is dit wel met elke van je genoemde taal mogelijk. Kies dan een taal die jij, of je ontwikkel team, het meest machtig is. De kans een goed werkend programma is dan groter.

[ Voor 13% gewijzigd door Verwijderd op 21-12-2004 13:42 ]

[Alarmnummer]

Verwijderd schreef op dinsdag 21 december 2004 @ 13:40:
Vandaar dat je het ook kunt omdraaien, zorg dat de server berichten stuurt naar actieve clients. in dat geval wordt de keuze misschien al makkelijker.

Dus jij stelt een callback voor van de server naar de client? En hoe moet de server dan bepalen of de client nog geldig is? Voor het standaard pollen zou ik toch echt kijken naar een client server call ipv een callback. Als zo`n event minder vaak voorkomt en je wilt wel heel tijdig reageren, dan zou ik pas kijken naar een callback.

Je kunt verder ook kijken naar Flash remoting -> Java (er zijn wel opensource implementaties). AMF is minder groot (en duur) dan XML (het is een binair formaat) en valt uitstekend aan te sluiten op java. (We hebben er een tijdje geleden een 'realtime' internet veiling mee gemaakt.

[Verwijderd]

Alarmnummer schreef op dinsdag 21 december 2004 @ 13:45:
Dus jij stelt een callback voor van de server naar de client? En hoe moet de server dan bepalen of de client nog geldig is?

Desnoods stuurt elke client om de minuut een "active" signaal. Dus domweg een message driven achtig protocol.

[ Voor 13% gewijzigd door Verwijderd op 21-12-2004 13:51 ]

[MisterData]

Je kunt natuurlijk ook gewoon (X)HTML met Javascript en XMLHTTP gebruiken. Werkt in IE, Mozilla en (half) in Opera/Konqueror/Safari. Onder andere wordt het door GMail gebruikt Deze is ook interessant: http://serversideguy.blog...le-suggest-dissected.html

[Janoz]

Met xmlsocket kun je gewoon een verbinding open houden en zodra daar wat binnen komt dit verwerken via een event. Het heet inderdaad xml socket, maar dat komt omdat het oorspronkelijk gebruikt zou moeten worden in combinatie met de verschillende xml functies in action script. Je kunt echter de binnengekomen string ook rechtstreeks uitlezen.

Voordeel van deze verbinding is dat de snelheid waarmee berichten binnenkomen ongeveer gelijk is aan de ping. Snel genoeg dus.

Nadeel is misschien dat er een verbinding open moet blijven en dit misschien belastend voor de server kan zijn waneer veel clients tegelijk verbinden.

[Verwijderd]

markvleth geeft een hele goeie tip Ik maak vrees ik namelijk een denk fout. Elke keer als een client "pollt" is er geen nieuwe data, het kan best voorkomen dat pas na 10 sec er nieuwe data is. Maar de client moet wel direct op de hoogte zijn van deze nieuwe data. Dus hoe sneller je polt hoe sneller de client kan detecteren dat er nieuwe data is.

Dat klopt allemaal wel, maar een callback mechanisme maakt het hele poll gedoe overbodig. Client registreert gewoon een object IkWilInfo bij de server, als de server nieuwe info heeft dan loopt ie alle IkWilInfo objecten af en roept de server IkWilInfo.hierisjeinfo() functie aan. RMI heeft hier volgens mij een kant en klare oplossing voor.

Ik heb even naar flash remoting gekeken:
http://www.onjava.com/lpt/a/3254
en dat ziet er zeker leuk uit, geen xml maar binary, openamf implementatie, ziet er een beetje uit als xml-rcp maar dan niet mbv xml maar binary. Maar wat ik nog niet heb kunnen vinden is of het callbacks ondersteund. Weet iemand dat zo?

Mm, als xmlsocket ook gewoon data kan ontvangen is het pollen ook niet meer nodig. Dan is flash weer een optie! Alleen de sockets die open blijven staan (overigens ook bij java/rmi e.d.) ik ben me niet zeker welke inpact dat heeft op de server. Daar ga ik eens een test programmatje voor maken.

Kennen jullie over JMS? Zou dat hier een oplossing kunnen bieden. Ik ben nog bezig met de jms tutorial door te spitten:
http://java.sun.com/produ.../doc/jms_tutorialTOC.html
Dat is nog best ingewikkelde materie, maar wel leuk

Zodadelijk ook nog naar xmlhttp kijken want daar heb ik ook nog nooit van gehoord.

[Verwijderd]

Mensen, ik ben eruit Het word een multi tier structuur:
tier 1: clients
tier 2: load balancer
tier 3: meedere rmi servers (load balancer kiest degene met de minste load)
tier 4: jms "Topic"
tier 5: sender

"sender" stuurt nieuwe berichten naar "jms", de servers van tier3 zijn geabonneerd op jms en ontvangen dus ook het bericht. Een rmi server in tier3 roept vervolgens via een callback functie de client weer aan.

Het mooie van deze structuur is dat je redelijk gemakkelijk ook soap, flash, email, enz clients kan ondersteunen. En het is allemaal mooi uitbreidbaar, je moet met gemak 10.000 clients kunnen halen

Hoe vinden jullie hem?

[ Voor 15% gewijzigd door Verwijderd op 22-12-2004 12:30 ]

[Janoz]

Structuur is inderdaad mooi en jms is inderdaad ideaal hiervoor. Bedenk echter dat je er niet omheen komt om constant een verbinding met de clients open te houden. Waneer je probeert een server een verbinding te laten openen naar een client loop je heel snel tegen beveiligingen en andere ristricties aan (firewalls, en sandboxes). De enige werkbare methode is om de clinet een verbinding met de server op te laten zetten. Dat is ook wat er gebeurt bij flash (XMLSocket en OpemAMF), en (afaik) bij Applets.

XmlHttp blijft een poll techniek, steek daar maar niet teveel tijd in.

[ Voor 7% gewijzigd door Janoz op 22-12-2004 12:33 ]

[Alarmnummer]

Verwijderd schreef op woensdag 22 december 2004 @ 12:27:
Mensen, ik ben eruit Het word een multi tier structuur:
tier 1: clients
tier 2: load balancer
tier 3: meedere rmi servers (load balancer kiest degene met de minste load)
tier 4: jms "Topic"
tier 5: sender

"sender" stuurt nieuwe berichten naar "jms", de servers van tier3 zijn geabonneerd op jms en ontvangen dus ook het bericht. Een rmi server in tier3 roept vervolgens via een callback functie de client weer aan.

Het mooie van deze structuur is dat je redelijk gemakkelijk ook soap, flash, email, enz clients kan ondersteunen. En het is allemaal mooi uitbreidbaar, je moet met gemak 10.000 clients kunnen halen

Hoe vinden jullie hem?

Ik weet niet wat je hele app moet doen, maar dit lijkt me nogal een overkill app. Als jij gewoon zorgt dat jij op de server n keer per seconde een nieuw pakket aanmaakt dan kan een client als die pollt dat pakket meekrijgen. Heb je meteen geen gezeur meer met concurrency control (aangezien er maar 1 hoofdthread in de app actief is). Ik zie verder de toegevoegde waarde van het hele jms gebeuren niet. Ik snap dat jij messages + topics wilt.. daar ben je geen jms voor nodig. Jms is in principe geschikt voor de wat zwaardere toepassingen doordat de meeste jms services remote draaien en acid eigenschappen ondersteunen.

Ik zou persoonlijk gaan voor:

flashclient -> java server.

De java server heeft voor het pollen altijd synchronisatie pakketten klaarliggen (en ja.. je kunt een synchronisatie pakket krijgen die een heel klein beetje out dated is). Eventueel zet je per topic een synchronisatie bouwsteen klaar die alle clients voor x tijdeenheden krijgen.

Het afhandelen van specifieke aanroepen naar functionaliteit zou ik misschien via een Reactor laten plaatsvinden.

Ik zou dus niet zo snel gaan pielen met een hele lading loadbalancing services, en server/server/server calls aangezien dat ook wat overhead met zich meebrengt.

Server/server calls is een orde van grote duurder dan normale calls.

[edit]
Als jij wilt dat jij om de n tijdseenheden een nieuw package in je systeem krijgt en jij wilt absoluut geen gezeik met concurrency, dan zou je een timerthread kunnen maken die om de x-tijdseenheden een message in de message queue zet die de reactor dan afwerkt. -> 0.0 concurrency problemen in je hele systeem.

Je kunt natuurlijk wel allerlei variaties hierop bedenken als je weet dat bepaalde subsystemen redelijk onafhankelijk in je systeem werken. Je zou dan bv een reactor per subsysteem kunnen maken.

[ Voor 16% gewijzigd door Alarmnummer op 22-12-2004 13:03 ]

[Alarmnummer]

Wat heb je trouwens gekozen voor oplossing?

[Verwijderd]

Ik heb nog niks gehoord, met al die feestdagen gebeurd er overigens nooit veel en zeker niet met contacten e.d. Maar een rapportje met alle oplossingen en mogelijke structuren is verstuurd. Daar gaan ze waarschijnlijk weer een paar weken over vergaderen. Ben ik blij dat ik daar niet bij hoeft te zitten Nou maar hopen dat ze de goede overwegingen maken en dat ik een leuke nieuwe technieken kan gaan gebruiken. Maar ik mag niet klagen, nu ben ik namelijk bezig met online conversie van grafische documenten (kleur profielen, cmyk, property formats, blabla). Over diversiteit is niet te klagen!

[Alarmnummer]

Ik snap dat het leuk is om veel met nieuwe technieken aan de slag te gaan. Maar ik ben voornamelijk geinteresseerd in de meest eenvoudige oplossing die deze opdracht goed kan afronden Ik hou namelijk van zo weinig mogelijk complexiteit Dus keep us informed zou ik zeggen.

[Verwijderd]

De eenvoudigste versie was de oplossing die jij gaf, een socket openen aan de clientside naar bijvoorbeeld een servlet, socket open houden en de servlet kan dan door de open socket data sturen. Nadeel hiervan is wel dat je een aardige goede server moet hebben. Maar ja, later bleek weer dat men toch "mogelijk" zeker van moest zijn dat elk bericht wat een server verzond wel echt bij de client aan zou komen. Dus alleen tcp en sockets kan afvallen en dan komt JMS en soortgelijke technieken om de hoek kijken, maar dan zit je weer met firewall issues en dan zijn die ook weer op te lossen door bepaalde technieken. Ik hou ook van KISS maar als men een aantal buzz woorden hoort kan men vreemde sprongen gaan maken, waarvan je denk "hoe komen ze daar nu weer bij?"

[ Voor 4% gewijzigd door Verwijderd op 30-12-2004 22:13 ]

[Alarmnummer]

Verwijderd schreef op donderdag 30 december 2004 @ 22:12:
Maar ja, later bleek weer dat men toch "mogelijk" zeker van moest zijn dat elk bericht wat een server verzond wel echt bij de client aan zou komen.

Een pakketje zal wel aankomen, het kan alleen gebeuren dat ze misschien een wat verouderd pakketje krijgen. Maarja.. je hebt via het internet toch altijd bepaalde latencies, dus tja.. de vraag is hoe erg dat allemaal is. En ik snapt dat de klant geen kaas ervan heeft gegeten en hoort bij 'verouderde' pakketten meteen denkt aan een paket dat al een maand overtijd is. Maar dat hoeft helemaal niet zo te zijn.

Een groot voordeel van de aanpak met een centrale bericht afhandeling queue is dat je 0.0 problemen meer hebt met concurrency. Er is 1 centrale queue waar alle message (commando) terecht komen. En achter die queue zit 1 thread (slapend op een semafoor) te wachten totdat er een bericht in de queue zit.

Alle users plaatsen hun niet-synchronisatie-requests in de queue. En verder knikkerd een timer om de x tijd eenheden een bouw-nieuw-synchronisatie-bouwsteen in de queue (waardoor er een nieuwe synchronisatie bouwsteen klaar staat die alle clients voor een tijdje krijgen voorgeschoteld. Voor deze synchronisatie bouwsteen hoeft de client dus geen message in de queue te zetten. Hierdoor hoeft je hoofdthread dus niets anders te doen dan voor de clients de niet-synchronisatie-messages af te handelen..en voor de timer in de x tijd eenheden een nieuw synchronisatie-bouwsteen op te bouwen.

Een systeem schrijven waarin alleen concurrency al goed is geregeld is complex, en de oplossing die ik hierboven heb beschreven is erg eenvoudig te realiseren.

Als ze verder willen dat hun niet-synchronisatie-requests onder een transactie verlopen, kan je voor dat gedeelte van de logica altijd nog kijken naar een JMS-server.... maar ik zou het kiss principe zo veel mogelijk in mijn achterhoofd proberen te houden.. en de klant niet altijd geven wat ze vragen.. maar wat ze nodig hebben..

Ik hou ook van KISS maar als men een aantal buzz woorden hoort kan men vreemde sprongen gaan maken, waarvan je denk "hoe komen ze daar nu weer bij?"

Yep.. maar kan jij toch mooi vertellen dat jullie systeem gebruik maakt van snelle configuratie bestanden met echte stukjes XML en etc etc.

[ Voor 20% gewijzigd door Alarmnummer op 30-12-2004 22:40 ]

[Verwijderd]

Ik weet niet of ik te laat ben, maar ik heb laatste samen met iemand een idee ontwikkeld waar je misschien gebruik van kunt maken.

Het zou in princiepe met html/javascript/xml moeten werken.

Client laad HTML en javascript roept XML pagina op liveRequest.php?reg=0

alle data word terug gestuurd naar de client en krijg ook mee welke request nummer (timestamp) hij de volgende keer moet vragen ( kom hier zo op ).

javascript vraag weer xml op liveRequest.php?reg={timestamp}, de server kijkt nu welke data geupdate moet worden, sinds die timestamp (het kan zijn dat het een langzame verbinding is).

en de client word weer geupdate...


het kan voorkomen dat de client een request doet na een seconde of 3 pas, dat er al heel wat dingen zijn geupdate, dan moet de server sinds die request nieuwe data aanleveren + een nieuwe timestamp teruggeven....

EDIT: je kunt zo een verbinding status opbouwen, die bijhoud of er minimaal 2/3 keer per seconden word geupdate...

maja, ik weet niet of het allemaal wel snel genoeg is..

[ Voor 10% gewijzigd door Verwijderd op 30-12-2004 22:39 ]