HTTP push ipv pull ? Events vanaf webserver?

[Verwijderd]

Zoals waarschijnlijk bij velen bekend is, is het HTTP protocol zo opgezet dat de server geen verbinding houd met de client als deze de data van een request eenmaal heeft ontvangen.

Stel je ontwikkeld een systeem voor een Nederlands race team zodat tijdens de 24 uur van Lemans de telemetri gegevens van de auto direct en up to date online beschikbaar staan. Denk aan snelheid, positie op het circuit enz. enz.
Deze info wijzigt zeer regelmatig (meerdere keren per minuut) en eigenlijk is de enige methode om deze info up to date te houden bij een website bezoeker die deze info bekijkt, om de hele telemetri webpagina om de X seconden te laten refreshen zodat de nieuwe info opgehaald wordt.

De server kan namelijk geen bericht sturen naar de client omdat hij standaard eigenlijk niet weet welke clients er zijn.

Nu zijn er oplossingen te bedenken om het wel mogelijk te maken dat de server berichten stuurt naar de client alleen kom ik er dan snel op uit dat de client hiervoor een activex plugin nodig heeft of een java applet moet laden.

Ik ben benieuwd of jullie ook mogelijkheden zien om zonder extra client installaties of java toestanden bovenstaande te realiseren.

[raoulduke]

Het enige dat ik kan bedenken is een getimede refresh aan de clientzijde Je hebt toch echt een programmeertechniek nodig om zoiets te maken, bijvoorbeeld Java. HTML is een opmaaktaal, geen programmeertaal.

[Verwijderd]

Zo op het eerste gezicht is dit ook zo, maar moet toch meer mogelijk zijn.

[MaxxRide]

Ik denk niet dat dit je lukt. Je kunt de server volgens mij niet echt laten pushen. Misschien kun je wel iets doen met een iframe (kleintje) die je af en toe laat refreshen zodat de server niet al te zwaar belast wordt.

[Rataplan]

Kort en goed: nee, dat is per definitie onmogelijk.

HTTP is een stateless protocol (toch?), dus een server weet niet welke clients wel/niet zijn blijven hangen, en bovendien is een browser geen server die een poortje open kan zetten om daarop te luisteren. Zoals je zegt: een applet/servlet combo of een activex-oplossing zijn de enige mogelijkheden, als je ervanuit gaat dat pollen (dus elke X seconden verversen, desnoods maar een heel klein (i)frame'pje om het bandbreedtegebruik te minimaliseren) geen nette oplossing is.

Maar pollen is zeker het makkelijkst te implementeren, en vergt geen speciale installs aan de clientside, itt java/activex-oplossingen. Ik zou activex sowieso niet gebruiken (want windows-only, correct me if I'm wrong), en java valt ook al niet mee: als je gaat [google=pushlet] kom je d'r snel genoeg achter dat ook zulke oplossingen via clientside polling werken, heel flauw Het werkt wel maar gebruikt niet minder traffic dan een gewone (i)frame-refresh zoals Pinda ook al suggereert.

Alleen als je applet een verbinding met de server openhoudt ([google=rmi] is een mogelijkheid, je kan ook zelf socket connections gaan proggen, dat maakt dan ook niks meer uit ) krijg je een echte push-oplossing. En dat heeft idd niks meer met HTTP te maken. Je krijgt dan trouwens ook problemen met firewalls (als highport access dichtstaat ben je in feite al de l*l).

Tenzij je van stevig programmeren en een hele hoop serverconfiguratie houdt, en als je het risico dat een bezoeker geen java heeft, of achter een firewall zit, of allebei, niet voor lief wil nemen: pollen en nog eens pollen

[Xandrios]

Ik zou inderdaad een page elke x seconden laten refreshen, en de data ophalen.

Wat -mischien- mogelijk is, is een (eigenlijk wel een beetje vies) truucje: Je zet een IRC verbinding op dmv Javascript. Zoals die standaard JS irc-applets, welke je enigzins aanpast.

Dan kun je je data in een IRC kanaal spuwen, en alle bezoekers ontvangen dat dan

[Gomez12]

Of je kan een hidden iframe aanmaken welke je ververst om de 1sec. aan de hand van deze data update je met dom je mainscreen.

[Verwijderd]

Xandrios schreef op 28 mei 2004 @ 19:43:
Ik zou inderdaad een page elke x seconden laten refreshen, en de data ophalen.

Wat -mischien- mogelijk is, is een (eigenlijk wel een beetje vies) truucje: Je zet een IRC verbinding op dmv Javascript. Zoals die standaard JS irc-applets, welke je enigzins aanpast.

Dan kun je je data in een IRC kanaal spuwen, en alle bezoekers ontvangen dat dan

Ik zou absoluut niet weten waarom je iets met het IRC protocol zou moeten doen. En hoe het met Javascript zou moeten is mij en raadsel. Als je dan toch Java bedoelt, dan kun je beter een eigen simpel protocol maken of een ObjectStream of iets dergelijks gebruiken. Maar dan krijg je dus te maken met firewalls en dergelijke, wat Rataplan hierboven al uitlegt.

[Rataplan]

Xandrios schreef op 28 mei 2004 @ 19:43:
Wat -mischien- mogelijk is, is een (eigenlijk wel een beetje vies) truucje: Je zet een IRC verbinding op dmv Javascript. Zoals die standaard JS irc-applets, welke je enigzins aanpast.

Dan kun je je data in een IRC kanaal spuwen, en alle bezoekers ontvangen dat dan

Volgens mij heeft dat weinig met javascript, en alles met java van doen

Ik neem tenminste aan dat je iets als irc.tweakers.net bedoelt. Zo niet, hou ik me aanbevolen voor voorbeelden maar volgens mij kan je beter zelf applets/servlets gaan schrijven.

edit:
@ snel roofdier

[ Voor 6% gewijzigd door Rataplan op 28-05-2004 19:52 ]

[__madmax__]

misschien is het ook een optie om flash en xml te gebruiken;

je laad via flash om de zoveel seconden opnieuw de XML in. Dit kan daar neer gezet zijn door de server zel (statische XML) of je haalt het uit een db, en maakt daar een mooi xml-etje van... Beetje hetzelfde idee als een applet denk ik.. alleen is flash iets gangbaarder op internet (97% penetratie??)

suc6
Matthijs

[Rataplan]

__madmax__ schreef op 28 mei 2004 @ 19:52:
misschien is het ook een optie om flash en xml te gebruiken;

je laad via flash om de zoveel seconden opnieuw de XML in. Dit kan daar neer gezet zijn door de server zel (statische XML) of je haalt het uit een db, en maakt daar een mooi xml-etje van... Beetje hetzelfde idee als een applet denk ik.. alleen is flash iets gangbaarder op internet (97% penetratie??)

De lol van java is dat je clientside een object met een method 'refresh' kan aanmaken, waar je vanaf de server - uitsluitend wanneer dat nodig is - een call naar kan doen, zodat overbodig bandbreedtegebruik niet voorkomt. Flash en XML bieden geen enkel voordeel boven pollen(edit: sterker nog: ook dit *is* pollen), behalve dat je die 3? procent non-flash-gebruikers uitsluit

Flash is iig volstrekt niet vergelijkbaar met java, vooral omdat flash een clientside ding is. Voor push-technologie zal je toch echt iets aan de serverkant moeten doen

[ Voor 18% gewijzigd door Rataplan op 28-05-2004 20:00 ]

[Olaf van der Spek]

De browser showed de page toch al voordat deze compleet binnen is?
Kun je de HTTP link niet open houden en als er een update is een blokje JS opsturen dat de browser vertelt de page te refreshen?

[Obliterator]

Je kunt de server een animated gif laten bouwen die nooit klaar is.
De browser laat dan die animated gif frame voor frame zien. Echt lekker is de oplossing alleen niet.

[Gert]

De meeste browsers blijven niet oneindig lang een plaatje laden, dan zeggen ze gewoon plaatje bestaat niet.

[Rataplan]

Gert schreef op 28 mei 2004 @ 20:20:
De meeste browsers blijven niet oneindig lang een plaatje laden, dan zeggen ze gewoon plaatje bestaat niet.

Je *mag* er ook niet vanuit gaan dat het werkt ('t is in geen enkele standaard vastgelegd), en bovendien zal je rekening moeten gaan houden met cache en proxy - een beetje standaard PHP-config kapt verder na 30 seconden met scripts uitvoeren, daar zal je ook omheen moeten werken. Bovendien vreet deze oplossing webserver-resources, je zal heel rap tegen het maximaal aantal connecties aanlopen; vooral als de server blijft verzenden naar afwezige (want bijvoorbeeld gecrashte) clients.

Zowel met plaatjes als met html is deze manier van connecties openhouden de road to hell, and doubly so als je geen rootrechten hebt. Dan liever een javascriptje en/of een simpele metatag.

[frickY]

Ik zou in een hidden-frame elke 30seconden een pagina laden herladen. Deze pagina genereerd een javascriptje met nieuwe content welke dit zelf naar de andere frames schijft.

Flash is misschien een netter systeem, een goed voorbeeld is hierboven al ergens gegeven. Heb zelf ook eens een real-time flashapp gemaakt welke elke 5sec een nieuw txt-bestandje met gegevens inlaadde.

[MBV]

je kan ook met javascript xml-gegevens ophalen, volgens mij zelfs via SOAP. Het grote voordeel is dat je via XML alleen de gegevens hoeft te vragen, zodat je veel minder traffic hebt. Je maakt een centrale pagina die maar 1 keer geladen hoeft te worden, vervolgens update javascript alleen de gegevens. Ik kan de titel van een boek opzoeken dat daarover gaat, ligt op mijn werk.
* MBV heeft er geen ervaring mee, maar vond het in het boek leuk uitgelegd staan:)

[rollebol]

Ik zou inderdaad in een iframe een stukje JavaScript in de <body onLoad> gooien, die op de pagina waarin die iframe staat de nieuwe 'stand' zet en na een bepaalde timeout de pagina ververst. Ik heb dit wel eens voor een andere toepassing gebruikt en het werkt vrij aardig.

De meeste webservers en alle gangbare HTTP-clients ondersteunen zogenaamde 'keep-alive' connecties, waardoor niet elke keer een nieuwe TCP-connectie hoeft te worden opgebouwd. Ik geloof dat dit standaard áán staat, en zonee dan werkt het nog steeds prima, iedere 10 seconden een update moet geen probleem zijn.

xmlhttp werkt op de nieuwere grafische browsers ook, maar qua dataverkeer en complexiteit van de code ben je niet echt goedkoper uit dan met zo'n iframe.

[ Voor 15% gewijzigd door rollebol op 28-05-2004 21:26 . Reden: xmlhttp ]

[Verwijderd]

Lijkt er inderdaad op dat een refresh om de x seconden de beste optie is (en dan iets van een iframe die geen overbodige info ophaald). Of zijn er nog andere ideeen?

[GlowMouse]

CGI:IRC is een CGI script wat gewoon constant verbinding houdt met de client. Op de website staat een link naar een demo. Nadeel is dat dit volgens mij vrij veel server resources vreet.

[Bosmonster]

Dan is het nog 100x efficienter om iedere 10 seconden een miniscuul bestandje op te halen met een refresh dan met iedere client constant een connectie open te houden.

De refresh is niet alleen een oplossing van 'het kan niet anders', het is in dit geval ook een zeer efficiente oplossing. Zeker als je weet dat je data constant wijzigt (als dat niet zo is wordt het iets minder efficient natuurlijk ).

[Soultaker]

rollebol schreef op 28 mei 2004 @ 21:24:
De meeste webservers en alle gangbare HTTP-clients ondersteunen zogenaamde 'keep-alive' connecties, waardoor niet elke keer een nieuwe TCP-connectie hoeft te worden opgebouwd. Ik geloof dat dit standaard áán staat, en zonee dan werkt het nog steeds prima, iedere 10 seconden een update moet geen probleem zijn.

Keep-alive is absoluut niet bedoelt om een socket secondenlang open te houden. Dat kost de server veel te veel resources. Een keep-alive connectie wordt gebruikt om meerdere HTTP-requests direct na elkaar te kunnen doen, als je meerdere resources nodig hebt op hetzelfde moment. Een typische situatie is een request voor een HTML pagina die gevold wordt door een aantal requests voor de plaatjes, scripts, stylesheets enzovoorts die op die pagina voorkomen.

Het is echter niet de bedoeling om de connectie met de server open te houden omdat je op een later tijdstip nog wel eens een ander request zou willen doen. Dan maak je maar mooi een nieuwe verbinding, dan kan de server z'n geheugen en file descriptors voor een andere client gebruiken. Een HTTP verbinding die niet gebruikt wordt openlaten is zonde.

[NetRipper]

Moet je morgen eens op de site van Roland Gaross kijken. Op de scoreboard wordt continu realtime bijgewerkt. Momenteel zijn er geen wedstrijden, maar morgenmiddag vast wel.

http://www.rolandgarros.com/en_FR/scores/index.html

Hoe doen ze dat dan? Als ik moet gokken, denk ik dat een javascript op de achtergrond steeds de server pollt en kijkt voor veranderingen en voert die door als dat nodig is. Je ziet in de statusbalk van IE in ieder geval niets gebeuren, bij IFrames zie je meestal wel wat dat een blauw balkje verschijnt (of knippert, als het snel gaat ).

[PipoDeClown]

NetRipper schreef op 29 mei 2004 @ 01:43:
Moet je morgen eens op de site van Roland Gaross kijken. Op de scoreboard wordt continu realtime bijgewerkt. Momenteel zijn er geen wedstrijden, maar morgenmiddag vast wel.

http://www.rolandgarros.com/en_FR/scores/index.html

Hoe doen ze dat dan? Als ik moet gokken, denk ik dat een javascript op de achtergrond steeds de server pollt en kijkt voor veranderingen en voert die door als dat nodig is. Je ziet in de statusbalk van IE in ieder geval niets gebeuren, bij IFrames zie je meestal wel wat dat een blauw balkje verschijnt (of knippert, als het snel gaat ).

java, geen javascript

[.oisyn]

HTML:

<applet code="MessageListener.class" codebase="http://scoreboard.rolandgarros.com/en_FR/ibmrealtime/"
 name="MessageListener" id="MessageListener" archive="Listener.jar" width="1" height="1" mayscript>
    <param name="mode" value="pub/sub">
    <param name="lang" value="en_FR">
</applet>

een Java applet dus
(hun javascript is trouwens echt ranzig, overal eval's terwijl ze helemaal niet nodig zijn )

[ Voor 3% gewijzigd door .oisyn op 29-05-2004 01:59 ]

[Soultaker]

Ja, maar hun JavaScript code is wel gepatenteerd; excuus, er is patent voor ingediend.

[ Voor 36% gewijzigd door Soultaker op 29-05-2004 02:04 ]

[Rataplan]

NetRipper schreef op 29 mei 2004 @ 01:43:
Hoe doen ze dat dan? Als ik moet gokken, denk ik dat een javascript op de achtergrond steeds de server pollt en kijkt voor veranderingen en voert die door als dat nodig is. Je ziet in de statusbalk van IE in ieder geval niets gebeuren, bij IFrames zie je meestal wel wat dat een blauw balkje verschijnt (of knippert, als het snel gaat ).

De tekst "Applet MessageListener started" in de statusbalk spreekt boekdelen

Dit is een java-applet, en dit is een prachtig voorbeeld van push-techniek aan het werk Op de server draait een programma (servlet) dat weet dat dit applet gestart is, en elke keer dat iemand een punt scoort dat van belang is voor jouw pagina, stuurt de servlet een seintje - en de score - naar het applet. Dat applet start vervolgens allerlei javascriptjes die de pagina dynamisch aanpassen.

Voordeel is de besparing op bandbreedte (alleen traffic wanneer 100% nodig), nadeel is dat je meer servercapaciteit nodig hebt (die servlets gebruiken geheugen en rekentijd gedurende veel langere tijd dan bij gewone http-requests). Reken zelf maar uit waar het breekpunt ligt

[.oisyn]

Rataplan schreef op 29 mei 2004 @ 02:05:
(die servlets gebruiken geheugen en rekentijd gedurende veel langere tijd dan bij gewone http-requests). Reken zelf maar uit waar het breekpunt ligt

Dat valt ook nog wel weer mee. Een idle maar open TCP connectie kost niet zoveel resources. Nou weet ik niet hoe de servlet zelf werkt (daar zit natuurlijk ook weer een push danwel pull techniek achter om de scores weer ergens anders vandaan te halen), maar in principe hoeft ie alleen maar alle clients te updaten als er een score veranderd is. Voor de rest doet ie niets met de clients, dus ik denk dat het kwa resources beter in elkaar zit dan allemaal clients die continu lopen te pollen

[Skinkie]

in html -> kijken met js of een bestandje is veranderd (kun je maken met de standaard preloading van plaatjes scriptjes) in javascript initialiseer je dan een verandering op de pagina

in flash -> xml socket openen... en luisteren maar

[Verwijderd]

Welke optie minder recourses vreet, is lijkt me inderdaad afhankelijk van wat de impact van een grote hoeveelheid open TCP connecties op een server. Als die impact minimaal is, dan is deze methode al snel efficienter.
Hoeveel open TCP connecties kan een machine gemiddels hebben? Lijkt me dat dit er toch behoorlijk zijn zonder problemen of zijn hier andere ervaringen mee?

[Verwijderd]

Je kunt ook javascript gebruiken. De client doet maar 1 request en mbv. document.write's aan het einde van de html roep je javascript functies aan waarmee je de pagina update. De request van de client is dan dus nooit afgelopen, maar blijft die document.write's ontvangen. Het is wel wat lastig om dit op iedere browser werkend te krijgen, maar het is zeker mogelijk voor IE en mozilla.

[Verwijderd]

Verwijderd schreef op 29 mei 2004 @ 11:15:
Je kunt ook javascript gebruiken. De client doet maar 1 request en mbv. document.write's aan het einde van de html roep je javascript functies aan waarmee je de pagina update. De request van de client is dan dus nooit afgelopen, maar blijft die document.write's ontvangen. Het is wel wat lastig om dit op iedere browser werkend te krijgen, maar het is zeker mogelijk voor IE en mozilla.

Alleen na een aantal minuten (of uren) zal het geheugen van de client compleet in gebruik zijn door je browser. Waarna ie waarschijnlijk je HD verder als geheugen gaat aanspreken. Of mis iets?

[MaxxRide]

Het lijkt mij nog steeds het beste om een refresh te doen. Wil je dit niet dan kun je simpelweg het beste gaan voor een applet oid. Ik denk dat er nu een oplossing wordt gezocht in een gebied (html) waar dat betreffende gebied simpelweg niet voor geschikt is. Kortweg: Applet gebruiken of refreshen.

[Verwijderd]

Tsja, geen idee. Het lijkt me dat dat wel mee zal vallen. Tenzij je bij elke update heel veel KB's verstuurd. De updates zijn natuurlijk alleen maar wat getallen/namen? Om het zo efficient mogelijk te maken, stop je alle statische data in de javascript (die maar 1x wordt verstuurd).
Stel een 2KB per minuut, 120 KB per uur. Laat de browser lekker inefficient zijn en dat 1MB kosten. Zou je toch wat uurtjes vooruit moeten kunnen.

Maar goed, je zou het moeten testen. Ik heb het alleen gebruikt voor iets dat binnen een paar minuten tot een uur klaar is.

@pinda: een refresh kost wel meer bandbreedte, ook voor de server. Voor clients kan dit ook vervelend zijn omdat de refresh even duurt.


Ow, Ik zeg trouwens document.write maar ik kijk even en wat ik doe is steeds een <script>functieaanroep(10,20,30, etc);</script> schrijven totdat de server klaar is.

Trouwens, zou je niet sowieso de verbinding naar een client na enige tijd willen 'killen' ? Kost jou namelijk wel resources. Dit hangt natuurlijk erg van de toepassing af, kan ook iets vriendelijkers zijn als een keep-alive link voor de gebruiker die hij eens per x uur moet klikken, timeout popupje etc.

[ Voor 43% gewijzigd door Verwijderd op 29-05-2004 11:52 ]

[MaxxRide]

@elbosmogg: Je kunt een iframe of voor mijn part een div maken met hier in heel sumier de data. Als je alleen deze laat refreshen valt dit mee, ik denk dat je dan op dezelfde hoeveelheid data uitkomt als de manier die jij voorstelt. (of zie ik iets over het hoofd?)

[Verwijderd]

Pinda schreef op 29 mei 2004 @ 11:58:
@elbosmogg: Je kunt een iframe of voor mijn part een div maken met hier in heel sumier de data. Als je alleen deze laat refreshen valt dit mee, ik denk dat je dan op dezelfde hoeveelheid data uitkomt als de manier die jij voorstelt. (of zie ik iets over het hoofd?)

Ja zou kunnen. Alleen, kreeg ik iets dergelijks toen niet werkend in mozilla
Ik weet even niet meer precies waarom.

Mozilla is sowieso het lastigst, waarschijnlijk omdat deze zich beter aan de standaarden houdt en deze oplossingen op z'n best grensgevallen zijn.

[Verwijderd]

Persoonlijk ben ik geen fan van refreshen in een pagina. De reden hiervoor is simpel - veel mensen hebben dat tikkende geluidje aan staan die je hoort bij het laden, dus ook het reloaden, van een pagina. Ik heb deze "techniek" eerder gezien op websites, en heb het altijd als irritant ervaren. Vooral als ik muziek aan heb staan. Da's dan ook de reden dat ik mijn WinXP omgeving inmiddels op "shut up!" stand heb gezet

Maar de gemiddelde gebruiker kan dit onderdeel van Windows niet vinden en zijn al blij als ze de website voor zich krijgen.

Dus dan heb je Java. Het hoeft nieteens visueel een Java omgeving te zijn. De applet hoeft eigenlijk alleen maar HTML dynamisch (roep javascript functies aan wellicht?) te veranderen, wat de gebruikers-vriendelijkheid ten goede komt (copy/paste van de resultaten e.d.) en het geheel ook flexibeler maakt, een tabel kun je met percentages makkelijker resizen dan een applet die naar mijn (beperkte) ervaring toch snel lastig aan te passen is grafisch gezien.

Dan heb je ook nog flash, wat tegenwoordig erg makkelijk met XML kan werken. De XML zou je zo in kunnen stellen dat deze een timestamp bewaart van de nieuwste aanwezige data. De flash applicatie vergelijkt deze gegevens met een locale variabele met zijn eigen "laatste data", en als deze verschillen, gaat hij een request doen voor meer informatie die dan automatisch wordt weergegeven. Als je hier een interval van 10 seconden aan hangt lijkt me dat "live" genoeg, toch?

Maar ik denk dat ik me verder zou moeten verdiepen in Java voor de beste methode. Ik denk nieteens dat Flash zo'n slecht idee is.

[PommeFritz]

Ik heb niemand nog zien verwijzen naar Netscape's multipart/x-mixed-replace ...

[The - DDD]

http://www.formula1.com/race/livetiming/720.html

Ook een leuke java applet. Tijdens de race alle informatie bijna realtime op je scherm. Je moet beschikken over een Sun JRE.

[Grijze Vos]

Flash kan redelijk mooi en onopvallend elke 5 seconden (bijv.) een nieuw data-pakketje van de server halen. Lijkt me een van de meest eenvoudige oplossingen.

[Verwijderd]

Met flash is er ook de mogelijkheid om sockets te gebruiken (zoals iemand hier al eerder genoemd heeft). Denk dat dit welleens een goed oplossing zou kunnen zijn.

http://www.tupps.com/flash/faq/xml-v1-0-0.html#6a

[Verwijderd]

Ben inmiddels bezig geweest me te verdiepen in de mogelijkheden van flash. Flash heeft naar de socket oplossing ook de voorkeur omdat we met allerlei grafieken e.d. moeten werken en dit er gewoon profi uit komt te zien in flash. (en nee, ik zal niet de persoon zijn die de flash maakt want dan kunnen we net zo goed gelijk ermee ophouden).

Het is mogelijk om een server voor flash te ontwikkelen waar de verschillende gebruikers die de flashmovie draaien verbinding mee kunnen maken. De bestaande oplossingen was ik niet erg gecharmeerd van en ben me daarom aan het verdiepen in de mogelijkheden om zelf een eenvoudige server te schrijven.

Gebruik makende in eerste instantie het Winsock control in VB6 of (als de planning het toelaat) C#.

Weet iemand hoeveel connecties een winsock control (of eigenlijk druk meerdere winsock controls) kan hebben voordat er problemen onstaan? Over iedere connectie zal om de paar seconden een XML sting verstuurd worden van een paar regels.

ps: syntaxis: weer gearriveerd in nederland begrijp ik?

[Verwijderd]

Verwijderd schreef op 31 mei 2004 @ 16:32:
ps: syntaxis: weer gearriveerd in nederland begrijp ik?

Lichtbruin en moe als een hond, maar lekker thuis, ja Nog eventjes de laatste vrije dag opmaken en morgen weer aan de bak.

Ik ben trouwens wel benieuwd naar je Flash oplossing, heb je er al mee begonnen?

[Verwijderd]

Nee met flash nog niet. Ga ik ook zeker niet zelf aan beginnen
Heb wel een VB6 server en client die met winsock communiceren. De server kan meerdere clients aan weet alleen nog niet waar de grens precies ligt.

[Verwijderd]

Een uitermate mooie oplossing is XML Sockets (beschikbaar vanaf Flash 5), ik heb hier al eens eerder mee gewerkt en het is echt een geweldige techniek

Telemetri gegevens van een auto wil je eigenlijk direct zien, en niet met een vertraging van 10 sec. dus een stream is hiervoor het beste.

[Skinkie]

Ik heb dus eerder zoiets ontwikkeld met XML sockets via Ming (Flash-in-PHP). En ik wil binnenkort een RRDTool replacement gaan maken die ook op zo'n XML manier werkt en eventueel SQLite aan de andere kant er achter.
Dus je hoeft niet persee een Macromedia geek te zijn om wat mooie Flash met Actionscript te combineren

[Verwijderd]

Das ook toevallig, ik heb laatst precies dezelfde afweging moeten maken (nou ja, niet precies dezelfde..). Ik heb toen ook de mogelijkheden van xmlsocket in flash i.s.m. een socketserver bekeken. Conclusie destijds; socket is the way to go, alleen goeie (goedkope) socketservers voor flash zijn er niet en die zul je zelf moeten schrijven. In Java betekend dat een classje of 3 (kale functionaliteit), dus dat valt mee.
Ik heb er onlangs eentje in elkaar geprakt en succesvol getest tot 99 verbindingen. Ik heb zowel een flashclient als een appletclient t.b.v. beschikbaarheid. Voordeel boven het z.g.n. "pollen" is dat er alleen een verbinding is op het moment dat jou server een broadcast naar alle clients verstuurd. “Pollen, alsof je je eigen dos attack op je eigen server organiseert “

Succes ermee!

[Verwijderd]

Verwijderd schreef op 01 juni 2004 @ 02:24:
“Pollen, alsof je je eigen dos attack op je eigen server organiseert “

Inderdaad. Gekkenwerk.
Denk er trouwens aan om de socket server in .net (c#) te ontwikkelen. Verwacht hier ook nog enige snelheids winst ten opzichte van java te behalen.

[ Voor 26% gewijzigd door Verwijderd op 01-06-2004 11:01 ]