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 ;) </ul>
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) :
