{"id":513,"date":"2008-12-15T18:25:00","date_gmt":"2008-12-15T17:25:00","guid":{"rendered":"http:\/\/ollmetzer\/?p=513"},"modified":"2010-06-21T19:05:12","modified_gmt":"2010-06-21T17:05:12","slug":"comet-%e2%80%93-server-push-auf-den-browser","status":"publish","type":"post","link":"https:\/\/www.ollmetzer.com\/?p=513","title":{"rendered":"Comet \u2013 Server Push auf den Browser"},"content":{"rendered":"

Spiele waren schon immer die K\u00f6nigsdisziplin der Softwareentwicklung: Man ben\u00f6tigt eine gute Story, tolle Grafik, knackigen Sound, und fl\u00fcssige Animationen. Die Programmierung geht dabei meistens bis an die Grenze des technisch machbaren. Letzte Woche habe ich mich \u00fcber den aktuellen Stand bei Browsergames informiert und einen Blick auf einige Projekte von Bigpoint, Gamesforge und Konsorten geworfen. Browsergames – sind Multiuserspiele, die ohne Softwareinstallation gespielt werden k\u00f6nnen, da sie nur einen aktuellen Webbrowser voraussetzen. Die Rede ist hier aber nicht von irgendwelchen 5min-zwischendurch-Flash-Spielchen, sondern von ausgewachsenen Strategie- oder Simulationsspielen. Das ist \u00fcbrigens eines der wenigen Felder, wo Deutsche Entwickler seit Beginn an ganz an der Spitze mitmachen.<\/p>\n

Das letzte Mal, als ich mir dieses Genre bewusst angesehen habe, war so ungef\u00e4hr 2002, als ich auf der Suche nach einem neuen Bet\u00e4tigungsfeld war. Damals hatten die Spiele noch ungef\u00e4hr den Charme einer aufgeborten Excel-Tabelle. Sie waren damals auch fast ohne Ausnahme Hobbyprojekte. Die alten Spiele waren alle rundenbasiert. Das bedeutet, die Spieler geben alle ihre Spielz\u00fcge ein und der Server berechnet dann nach einer bestimmten Zeit den neuen Spielzustand. Diese sogenannten „Ticks“ konnten wenige Minuten oder auch mehrere Stunden dauern. Das ist im Vergleich zu normalen Computerspielen zwar sehr ungew\u00f6hnlich, f\u00fcr Strategiespiele oder Wirtschaftssimulationen aber v\u00f6llig O.K. <\/p>\n

Mittlerweile sieht man die Professionalisierung der Branche sehr deutlich. Die Spiele, die ich neulich sah, hatten nicht nur gute (2D-) Grafiken und Animationen, sondern verbl\u00fcfften mich dadurch, da\u00df ich die Raumschiffe mehrerer Spieler gleichzeitig durch das All fliegen sah – ganz wie bei normalen Spielen.
\n„Ja und? Was ist daran so aussergew\u00f6hnlich?“ mag jetzt der Eine oder die Andere fragen.<\/p>\n

WOW – oder: Der Ausbruch aus dem HTTP Frage-Antwort-Schema<\/strong><\/p>\n

Die Beschr\u00e4nkung der alten Spiele auf rundenbasierte Spieltypen hatte einen guten Grund: Die Beschr\u00e4nkung der Browser auf das Hyper Text Transfer Protocol (http). Dieses sehr einfache Protokoll wurde Anfang der 90er Jahre urspr\u00fcnglich nur dazu entwickelt, Dokumente – meist HTML-Seiten – zu \u00fcbertragen. Dementsprechend simpel funktioniert es. Etwas vereinfacht: <\/p>\n

Der Browser \u00f6ffnet eine Verbindung zum Server, schickt die Anfrage nach einem bestimmten Dokument, der Server schickt das Dokument zur\u00fcck und schlie\u00dft die Verbindung – Ende.<\/p>\n

An diesem grundlegenden Verfahren \u00e4ndert auch das in den letzten Jahren gehypte AJAX nichts. Der einzige Unterschied liegt darin, da\u00df nun nicht mehr das gesamte Dokument auf einmal angefragt wird, sondern nur einige zu \u00e4ndernde Teile quasi im Hintergrund. Das Prinzip „Browser fragt, Server antwortet, Ende der Kommunikation“ bleibt dabei bestehen. Das f\u00fchrt zu einer einfachen Frage: <\/p>\n

How to push: „Wie kann der Server den Browser \u00fcber eine Zustands\u00e4nderung unterrichten?“<\/strong><\/p>\n

Wenn Mitspieler Ihre Raumschiffe bewegen, \u00e4ndert sich der Spielzustand. Dar\u00fcber m\u00fcssen nun alle Beteiligten m\u00f6glichst ohne (sp\u00fcrbare) Verz\u00f6gerung unterrichtet werden. Wie geht das aber, wenn die Anfragen immer vom Browser ausgehen? Der Browser weiss ja nichts davon, da\u00df eine neue Nachricht f\u00fcr ihn bereitliegt. Eine theoretische M\u00f6glichkeit liegt darin, da\u00df die Browser in sehr kurzen Zeitabst\u00e4nden den Spielstand abfragen. Das ist in der Praxis allerdings keine gute Idee. Einerseits w\u00fcrden auf diese Art bereits wenige Spieler ausreichen um den Server in die Knie zu zwingen und zweitens w\u00e4ren die Verz\u00f6gerungen noch immer deutlich sp\u00fcrbar. Es wird eine Art Server-Push ben\u00f6tigt.<\/p>\n

Alte Handwerkerregel: Was nicht passt wird passend gemacht.<\/strong><\/p>\n

In der Spiel-Programmierung gibt es einen alten Trick: Wenn etwas technisch nicht geht, mach etwas anderes, das genauso aussieht. ;-)<\/p>\n

Wir wollen, da\u00df der Server den Browser genau zum richtigen Zeitpunkt eine Nachricht sendet. Wenn der Server nun den Browser nicht von sich aus ansprechen kann, machen wir es eben genau andersherum. Der Browser fragt nach dem neuen Spielzustand und der Server l\u00e4sst sich mit der Antwort genau solange Zeit, bis der neue Spielzustand erreicht ist. Da\u00df das theoretisch m\u00f6glich ist, wusste ich zwar schon l\u00e4nger, und da\u00df zumindest Bigpoint so etwas bereits programmiert hat auch. Zum ersten Mal die konkrete Umsetzung zu sehen hat aber schon etwas. Und weil ich ein neugieriger<\/s> interessierter Mensch bin, m\u00f6chte ich auch wissen, wie man so etwas macht. Dabei bin ich heute \u00fcber den Befriff „Comet“ f\u00fcr diese Technik gestolpert und musste auch gleich mal ein bischen rumprobieren. <\/p>\n

Dem interessierten Leser kann ich zum Einstieg die folgenden Websites empfehlen:<\/p>\n