HowToCode: Reverse AJAX / Http-Push / "Comet" – Kann der Server Clients aktiv infomieren?
Durch eine Problemstellung bei Kollegen bin ich auf ein interessantes Thema gestoßen: HTTP Push/Reverse Ajax. Bei einem normalen Einsatz von AJAX schickt der Client (Browser) einen Request zum Server und dieser Antwortet – asynchron natürlich. Doch gibt es eine Möglichkeit dass auch der Server den Client informiert – ohne Polling? Hat jemand bereits in diesem Gebiet (mit .NET “Integration” ) Erfahrung gesammelt?
HTTP – Request & Response
Die Kommunikation über HTTP geht nur, wenn ein Client einen Request zum Server sendet. Dieser schickt daraufhin eine Response. Bei AJAX passiert dies ganze asynchron. In bestimmten Szenarien ist es aber wichtig, dass die Clients quasi in Real Time benachrichtig werden.
Szenarien
Typisches Beispiel dafür ist z.B. eine Aktienkurs Anwendung, ein Chat oder ein Multiplayer Spiel. Google Mail / Talk / Docs oder Meebo ist dies z.B. in der Realität zu sehen.
Das Problem bei normalen AJAX
Durch die Natur von HTTP muss die Kommunikation vom Client aus erfolgen, d.h. im einfachsten Fall macht man vom Client aus ein Polling am Server – das ist allerdings alles andere als nett für den Server (Skalierbarkeit) und zudem hat man da wieder eine bestimmte Wartezeit (je nachdem wieoft gepollt wird).
“Comet”
“Comet” ist im Prinzip eine Herangehensweise um durch kleine Hacks HTTP eine “Two-Way” Kommunikation zu ermöglichen. Im Grunde gibt es wohl (das basiert alles auf gesundem Halbwissen) 2 Möglichkeiten:
- “Long Polling”: Client setzt einen AJAX Request ab und der Server hält die Verbindung sehr lange bis irgendein “Event” eintritt. Dann antwortet der Server und der Client bekommt das Ergebnis. Danach wird sofort wieder ein neuer AJAX Request gemacht und das Spiel beginnt von vorn.
- “Streaming”: Hierbei wird ständig eine Verbindung offen gehalten… mehr gibt leider mein Halbwissen nicht mehr her
Der Vorteil bei beiden Varianten ist, dass man nicht ständig den Server fragt, was es neues gibt, sondern man hat eine Art “Events”.
Zukunft: HTML5
In HTML5 Macher grübeln auch über diese Anwendungsfälle. Mittels WebSockets soll sowas mal möglich sein – ist aber wie gesagt Zukunft. Hier ein netter Artikel über HTML5 WebSockets vs. Comet
Alternativ: Flash?
Flash soll wohl auch Socket-Programmierung erlauben. Damit könnte man ebenfalls solch eine Kommunikation machen.
Skalierbarkeit
Bei beiden Varianten muss der Client eine Verbindung zum Webserver offen halten. Für den normalen IIS & Apachen ist dies nicht gut, denn irgendwann gehen den Webservern die Threads aus. Daher werden spezielle Server benötigt. Lightstreamer soll z.B. solch ein Server sein. Diese Server sollen speziell auf diese Sachen ausgerichtet sein und sollen auch über 10.000 Connections offenhalten können.
Erfahrungen?
Hat bereits jemand mit diesen Techniken im Zusammenhang mit .NET Erfahrung gesammelt? Ab wann macht das “Sinn” und kann man das relativ einfach managen oder gibt es irgendwas mit dem man mal schnell rumspielen kann? 
Weitere Informationen
Auf SlideShare habe ich einige interessante Präsentatationen zu dem Thema gefunden:
ASP.NET & Comet
Auf meiner Suche bin ich auch auf flogende Blogposts gestoßen (und über diese auf den Lightstreamer Server) :
Deutsch
Englisch
Manuel Wenk sagt
am 22. Oktober 2009 @ 09:30
Hi,
ich hab vor ca. 7-8 Jahren mal ein Produkt entwickelt das Long-Polling verwendete (damals haben wir es aber nicht Long-Polling genannt, dachten wir hätten es selber erfunden und damals war AJAX bei uns auch noch nicht unter AJAX bekannt…).
Das war eine ASP.net 1.1 Website Applikation die die Steuerung eines Telefons ermöglichen sollte. Nun muss in der Seite aber auch signalisiert werden wenn es klingelt. Wir haben einen asynchronen Request gemacht mit einem clientseitigen Timeout von 60 Sekunden. Nach 30 Sekunden lieferte der Server einfach ein false zurück und das Spiel lief von vorne (true bedeutete Reload der Page durchführen).
Serverseitig haben wir einfach ein Thread.Sleep(100) in einer Loop gemacht die entweder nach 30 Sekunden verlassen wurde, oder sofort wenn ein bestimmtes Event auftrat, das war extrem schnell und simpel. Wir hatten aber auch nie mehr als 5 User.
Wenn die Menge der Request für den Server wirklich ein Problem darstellt würde ich vermutlich eher einen eigenen kleinen HTTP Server schreiben der nur die Polling-Requests verarbeitet und intern per TCP mit der Webapplikation kommuniziert. Mit asp.net vom IIS zu einem anderen Server zu switchen wäre vermutlich ein höherer Aufwand.
mgri sagt
am 22. Oktober 2009 @ 20:03
Also ich schaetze da gibt es jede Menge Probleme zu loesen.
Workerthreads hattest Du schon gesagt, Sockets sind auch begrenzt. Ein effizientes Backend zum Spezial-Webserver ist nicht so einfach – auch da geht wohl 1 Thread pro Client nicht lange gut.
Aber der Killer sind Proxies und vielleicht das Netzwerk an sich (Stichwort Dial on Demand): Du musst den Proxy ueberzeugen die langlebigen Verbindungen offenzuhalten, potentiell sehr viele davon (selbes Problem wie beim Webserver). Die meisten Proxies duerften die Anzahl und Lebensdauer von Verbindungen heutzutage strikt begrenzen, aus Selbsterhaltungstrieb.
Dabei helfen dann vermutlich Keep-Alives, “chunked” Transfer-Encoding oder gleich HTTP CONNECT – das geht dann aber oft nur zum SSL-Port.
Am Ende ist im LAN mit relativ wenigen Usern Polling einfacher (aber Push relativ leicht machbar) und im Internet HTTP-Push etwas was man freiwillig nicht implementieren will.