Comet

Hallo,
mich würde mal interessieren, wie viele von euch setzen bereits Comet in ihren Spielen ein? Mit Comet (oder auch mit Flash/Java oder pollen) ist es möglich, dass den Inhalt von Seiten zu aktualisieren, wenn die Dargestellten Daten sich geändert haben, ohne das der Spieler ständig den "Neuladen"-Knopf seines Browsers drücken muss. Wofür setzt ihr so etwas schon ein? Für was werdet ihr es einsetzen? Oder auch, warum setzt Ihr es nicht ein?
mfg Todi

Ich setze es unter Rails für sämtliche Live-Updates an Spieler ein. Dafür hab ich ein alternatives Rails-Plugin für den Juggernaut-Server geschrieben. http://juggernaut.rubyforge.org Das erlaubt es, zusätzlich zu dem normalen Aufruf

 render :action => :do_something_with_the_dom

 (was beispielsweise ein RJS-Template ist), auch so Späße zu machen wie

 render_to_channel :channel_name, :action => :do_something_with_the_dom

 oder auch:

 render_to_all :js => 'alert("Hi, diese Alertbox wurde dir per Server-Push zugeschickt")'

Aufrufe dieser Art könnten überall in einem Controller gemacht werden und gehen automatisch an alle, die gerade im Spiel online sind. Das wird natürlich für den Chat eingesetzt, als auch für jede Art von Notifikationen. Alles in allem eine ziemlich geile Sache. Werde das Plugin vielleicht mal auf github stellen.

Das ist interessant! Leider braucht Juggernaut ja Flash. Bei Financial-Rumors wurden alle Informationen via Comet dargestellt und da die meisten Informationen (alle außer der Chat) in der Datenbank standen, habe ich die Informationen direkt bei ActiveRecord abgegriffen. Der Action code selbst hat nur, wie üblich mit ActiveRecord Änderungen an der Datenbank gemacht. An anderer Stelle wurden dann Sichten auf die Datenbank beschrieben. Hier z.B. der Lagerinhalt für ein Produkt eines Unternehmens in einer Stadt:

	AppObserver::add_observer(
		AppObserver::View.new('storedprod', 'store_owner',
				 'store_location', 'product'),
		AppObserver::SQLReader.new(
			:tables => 'stored_products',
			:default => {
				'amount' => 0, 
				'market_amount' => 0, 
				'average_price' => 0.0 }),
		AppObserver::Updates.new(StoredProduct)
	)

Client-Seitig konnte man sich dann mit dem Namen 'storedprod' unter Angabe der drei Parameter 'store_owner', 'store_location' und 'product' auf genau diese Sicht beziehen und es wurde dort dann ein call back aufgerufen, wenn sich die Daten geändert haben. 

Comet ist doch so ein Schlagwort für alles, ähnlich Ajax, oder nicht? Womit hast du den Code oben realisiert? Mit nem Gem? Ist der Code unabhängig von Rails?

Empfinde Flash im Gegensatz zu vielen anderen Meinungen nicht als K.O.-Kriterium.

Ja, Comet is ein Schlagwort für die Möglichkeit, vom Server aus Nachrichten an bestimmte Clients zu schicken. Flash ist nur eine Möglichkeit, ist einfach implementiert, hat aber den Nachteil, dass Flash benötigt wird ;-) Ich versuche mir gerade einen Überblick zu verschaffen, was es für Server es gibt und welche Techniken da eingesetzt werden. Ab Mitte des Jahres habe ich hoffentlich etwas mehr Zeit und überlege gerade, ob ich selbst einen Comet-Server schreiben möchte.

Das da oben ist handgeschriebener Code. Der basiert auf ActiveRecords, dass ist das Persistenz-Framework, dass mit Rails daher kommt, sich aber auch ohne Rails benutzen läßt. Das ist eher ein einfaches Beispiel wenn Du mehr sehen möchtest, mußt Du mal nach subjects.rb in robitzki.de/fr.zip suchen.

Dass das da oben ActiveRecord ist, hast du ja geschrieben. Aber ich meine, wie sieht bei dir die Kommunikation zwischen Client und Server aus? Rails kann ja keine persistenten Verbindungen von Haus aus.

Als Server hatte ich anfänglich einen modifizierten WEBrick verwendet. Das skalierte aber nicht besonders gut, weil das komplett single threaded war. Im zweiten Anlauf habe ich dann einen modifizierten Mongrel genommen, der die Push-Verbindungen hielt und die Rails-Posts an einen zweiten, unmodifizierten Mongrel-Server weiter geleitet hat.

Die größere Lösung sollte eigentlich ein eigener in C++ geschriebener Server werden (Code-Name: Sioux), aber das war zeitlich zu aufwändig. Der zweite Ansatz mit dem Mongrel lief auf jeden Fall deutlich besser. Vielleicht implementiere ich den Sioux aber noch mal, wenn ich wieder etwas Zeit für Hobby-Projekte habe.

Krasse Sache....

Mir wäre eine Lösung ohne Flash auch lieber, mag aber den von mir in meinem ersten Post beschriebenen Ansatz. Kann man sowas auch mit einem Webrick oder Mongrel realisieren?

Man kann es mit einem modifizierten Mongrel implementieren. In den Sourcen von Financial-Rumors findest Du in mangrel_patch.rb eine geänderte Hauptschleife, die in einer thread local variable den Socket speichert und über einen an den Socket gehängten bool abfragt, ob der Socket am Ende geschlossen werden soll. In keep_socket.rb ist TCPSocket um diesen bool erweitert. Was Du machst, ist ja offensichtlich JavaScript an die Clients zu schicken und dort wahrscheinlich mit eval() auszuführen. Das mit einer HTTP Verbindung natürlich auch. Bei Financial-Rumors habe ich z.B. nur den zum Start nötigen JavaScript-Code vom Client geladen. Der anfänglich nicht benötigte Code, wurde später nachgeladen und mit eval() in Client gebracht.

Da gibt's aber keine Möglichkeit, in der Action eines anderen Requests, Code an andere Clients zu senden, außer man geht den Weg über die Datenbank.

Bei Financial-Rumors ist es so, dass ich zu jeder Zeit, server-seitig den Inhalt eines Subjects ändern kann. Clients subscriben sich auf beliebige Subjects und bekommen alle Änderungen an diesem Subject mit. Erst ein zweiter Layer sorgt dafür, dass ich ich nicht mit der Änderung von Datenobjekten immer wissen muss, in welchen Subjects die inhaltlich dargestellt werden. Dieser zweite Layer läßt sich umgehen und das ist auch Sinnvoll, wenn die Daten, wie beim Chat z.B. eben nicht in der Datenbank stehen. Der Chat ist in chat_controller.rb implementiert und ruft direkt PublicSubscribe.data_changed() auf.

Geile Sache :)

Schau ich mir mal an. Mehr Erfahrungen mit Comet hab ich leider nicht ^^

Wenn Du vor hast, selbst weiter was in der Richtung zu machen, kontaktiert mich mal. Wenn Du mit dem Server von Financial-Rumors rumprobieren möchtest, kann ich Dir sicher auch helfen den zum laufen zu bringen. Mich interessiert das Comet Thema gerade von der Server-Seite. Ich suche noch nach einer Anwendung, mit der man mal zeigen kann, was damit so möglich ist und nicht ganz so langweilig ist, wie aktualisierte Börsenkurse, aber auch nicht so aufwendig wie Google Wave ist.
'Keiner hier, der mal erzählen möchte, warum er _kein_ Comet einsetzt?

Ich wollte das Thema noch mal nach oben spülen. Gibt es mitlerweile mehr Einsatz/Interesse von/an Comet? Ich habe mich jetzt dazu entschieden einen eigenes Server zu schreiben. Auf dem Markt gibt es wohl mittlerweile auch 2-3 brauchbare Server, ich finde das aber so spannend, dass ich selbst einen schreiben möchte.

Ich befasse mich erst seit gestern mit dem Thema, kann also leider noch nichts superintelligentes dazu sagen. ;-) Das Thema finde ich aber sehr interessant.

Ich suche gerade nach einer Methode um Client-Client-Kommunikation zu simulieren. Das Einsatzgebiet soll sich nicht auf einen einfachen Chat beschränken, sondern "real-time" (in diesem Kontext aus der Sicht des Spielers, nicht des Spiels) - Interaktion ermöglichen. Als Beispiel: wenn es zu Kämpfen kommt, sollen zwei oder mehrere Spieler Figuren auf einem Spielfeld ziehen und Aktionen anderer Spieler direkt sehen. Der Delay zwischen zwei Spieleraktionen sollte dabei möglichst klein gehalten werden.

Ist so etwas mit Comet zu realisieren?

Ich bin außerdem noch nicht so sehr mit rails oder ActiveRecords vertraut. Webrick oder Mongrel sagen mir nichts. Ich schätze aber mal, dass sich PHP für eine Comet-Implementierung nicht so sehr eignet, oder? Habe heute ein bisschen im Netz dazu recherchiert aber Ansätze mit versteckten iframes scheinen mir da eher hacks zu sein.

Gibt es da von eurer Seite etwas neues zu berichten? Bzw kann einer von euch ein bisschen genauer erklären, wie Comet eingesetzt wird?

EDIT:

Habe gerade das APE-Project gefunden:

http://www.ape-project.org/

Hat damit schon einmal jemand gearbeitet? Wenn es wirklich so toll ist wie auf der Website versprochen, kann man sich das Schreiben eines eigenen Servers doch sparen, oder?

Ich meine im Grunde genommen ist das was du da machst nichts anderes als ein Chat, nur dass nicht Text verschickt wird, sondern Eventupdates (Figur läuft von A nach B). Ich habe das in meinem Spiel http://overwatch.de über einfaches Polling realisiert. Allerdings ist mein Anwendungsfall auch nur ein Schreiber und maximal 10 Leute, die als Observer das Spiel ansehen.

Wenn du es verschmerzen kannst, dass deine "Echtzeit" nur alle x Sekunden aktualisiert wird (und x ist irgendwas >= 10sekunden), dann wirst du damit vermutlich besser fahren, als mit momentanen Comet-Lösungen.

Aber mal zu deinem Problem...wie sieht denn Echtzeit auf deiner Karte aus? Ich nehme mal an, dass die Aussagen aus deinem anderen Thread hier auch gültig sind. Daher empfehle ic hdir folgendes:

Du unterteilst deine Karte in Interessensgebiete...diese können von der Grösse her mit den Regionen deines Fog of Wars übereinstimmen.

Jedes Interessensgebiet hält eine Liste von UpdateEvents. Bewegt Spieler A seine Figur 27634 von (123,3) nach (123,4), wird ein UpdateEvent in die Liste des entsprechenden Interessengebiets geschrieben.

Jeder Spieler pollt in gewissen abständen. Er weiss ja selbst, welche Region ihn interessiert. Eine Anfrage sieht also so aus: Gib mir alle Neuigkeiten für Regionen {(72,93),(72,94)}.  Diese Neuigkeiten sendest du ihm zu und der Clietn stellt sie dar....z.B. bekommt Spieler B das UpdateEvent Figur 27634 bewegt sich von (123,3) nach (123,4). Stellst du dabei ine Inkonsistenz fest (Figur steht an (123,8)) lädst du die ganze Szene neu...dann stehen wieder alle Figuren an der richtigen Stelle.

Die UpdateEvents versiehst du mit einem TimeStamp...alles was älter ist als 30 sekunden wirfst du weg...denn deine Clients pollen ja all 10 sekunden....somit verbrauchst du auch nicht zu viel Platz in deinem Cache. Updateevents müssen auch nicht persistiert werden, da es ja nur Updates sind...die "Wahrheit" steht ja immer in der Datenbank.

So oder so ähnlich würed ich das machen....was denkt ihr, bis wann man damit skalieren kann?

Maxx

also auf dem Video von Aves Engine, sagen die dass die bis zu 50 Clients getestet haben, weis aber nicht ob die es mit Comet oder DB umgesetzt haben.. aber die fragen ja auch jede sekunde nach um möglicht RealTime zu animieren.. schau mal das Video an auf youtube

MrMaxx,

lokale UpdateEvents sind eine gute Idee. Überhaupt macht es ja keinen Sinn Daten aktuell zu halten, die den Spieler nicht direkt betreffen. 10 Sekunden sind allerdings eine zu lange Zeitspanne für Aktualisierungen. Die Spielgeschwindigkeit soll mit Warcraft, Age-of-Empires etc. vergleichbar sein.

BlackScorp,

das Video ist ganz interessant. Wenn ich mich nicht täusche ist das Projekt aber schon über die Theke gegangen, oder?

Bezüglich der Skalierung: bei jeweils lokalen Updates und, sagen wir mal, 60 Events pro Spieler pro Sekunde und 1000 Spielern online kommt da ja eine Menge zusammen. Das Ape-project kommt aber ja laut Website ohne Probleme mit 100.000 Clients zurecht. Wie ist sowas zu bewerten?

ja dann musst du bei solchen geschwindkeitswünschen dann auf Flex ,AS oder Java umsteigen oder dein Spielkonzept so bearbeiten dass ein update garnicht nötig ist, es muss sich ja nicht die ganze zeit was auf der Map rumlaufen damit das spiel gut wird;) Ich lasse sowas zb bei mir weg, es reicht wenn ich meine eigene animation sehe und nach der animation weis, welche sachen sich auf meinem aktuellen feld befinden, mehr muss man nicht wissen:D

Das hängt sicherlich vom Spielkonzept ab. In meinem Spiel soll sich das Geschehen auf der Map abspielen, deshalb sind RealTime-Updates unumgänglich.

Wenn ich jedoch dafür darauf verzichten muss nur bei HTML und JavaScript zu bleiben kann ich das Konzept gleich vergessen. Es sei denn, es gäbe noch eine andere Technik die mir ermöglicht das zu realisieren was ich brauche. Aus diesem Grund schau ich mir ja gerade Comet an. ;-)

ansich ist das ne tolle idee mit dem Comet aber mein IE ist gerade bei der Demo abgestürzt , da stand auch eine warnung dass es laggen könnte weil canvas emuliert wird.. am besten du testest es aus und sagst uns ob das so gut läuft und ob da wirklich alles RT ist

Die Homepage-Demo von ape funktioniert auf jeden fall mit meinem aktuellen Browser (Chrome 9). Ich baue vielleicht erstmal eine kleine Demo-App und teste mal wie das mit der Performance und der Stabilität aussieht. Dann berichte ich hier.

am besten link posten und ein client counter reinsetzen damit wir auch wissen wieviele verbunden sind :D

Original von Progralixx

Die Homepage-Demo von ape funktioniert auf jeden fall mit meinem aktuellen Browser (Chrome 9). Ich baue vielleicht erstmal eine kleine Demo-App und teste mal wie das mit der Performance und der Stabilität aussieht. Dann berichte ich hier.

Wo du grade Chrome 9 erwähnst - für welche Browser soll das Ganze denn gedacht sein?

Bestimmte Comet Lösungen funktionieren nur auf bestimmten Browsern. Als neue Möglichkeit kommen grad auch die WebSockets auf, die in deinem Chrome schon drin sind. Allerdings läuft es dann nur auf den aktuellsten Browsern.

Das "Überlappen" der "Interessensgebiete" deiner Events mit den "Regionen" des Fog of Wars hat auch den Vorteil, dass du schnell und leicht bestimmen kannst, ob ein bestimmtes UpdateEvent überhaupt von dem Spieler "gesehen" wird, er es also überhaupt ausgeliefert bekommt.

So long...

Maxx

SurelyPlus,

natürlich soll es auf so vielen Browsern wir möglich laufen. Das ape-project zum Beispiel unterstützt WebSockets und fällt bei Bedarf auf Long Polling zurück. Welche Comet-Lösungen kennst du denn noch?

Hat sonst schon jemand einen Comet-Ansatz verwendet und kann berichten? Drängt sich sowas für Browsergames mit Echtzeitfunktionen nicht gerade auf?

Hatte nicht gesehen, dass das APE Framework auch eine clientseitige Komponente besitzt.

Mir ging es um die verschiedenen Basis-Techniken um auf Clientseite die Daten zu handlen. Wie z.B. WebSockets, "ForeverFrame", Mulitpart XHR (Streaming), Long Polling, ActiveX-HTMLFile, etc.

Da in APE schon ein Fallback eingebaut ist, musst du dich damit eh nicht mehr rumschlagen.

Edit: Hast du dir mal diese APE Demo angesehen?

http://www.ape-project.org/demos/7/mmorpg.html

Demo im Chrome 9 lief super, Firefox 3.6 war ok, IE 8 ist bei mir abgestürzt.

Original von Progralixx

Ich suche gerade nach einer Methode um Client-Client-Kommunikation zu simulieren.

Ist so etwas mit Comet zu realisieren?

Ja, grundsätzlich ist soetwas mit Comet zu realisieren. Den Server in der Mitte wirst Du dabei aber nicht umgehen können. Das Prinzip ist sehr ähnlich einem Chat, entspräche in etwa einem privaten Chat.

Bei dem Server, den ich gerade schreibe, subscribed sich ein Spieler dann, z.B. auf einen Knoten mit den Paramter type="schlachtfeld", id="122". Dann wird geprüft, ob es diesen Knoten gibt, und ob der Subscriber berechtigt ist, sich auf diesen Knoten zu subscriben. Dann bekommt der client (browser) einen Update mit den aktuellen Daten und der version der Daten und danach nur noch updates, wenn sich etwas an den Daten geändert hat.

Ich bin außerdem noch nicht so sehr mit rails oder ActiveRecords vertraut. Webrick oder Mongrel sagen mir nichts. Ich schätze aber mal, dass sich PHP für eine Comet-Implementierung nicht so sehr eignet, oder?

Generell hat so ein Comet-Server zwei API's. Eine für den Client, der ist in der Regel sinnvollerweise in JavaScript implementiert und eine API für den Server, diese kann sehr unterschiedlich sein. Mein Server wird zuerst eine C++ API haben und darauf dann Wrapper für Java/Scala, Ruby und evtl. PHP. CometD wäre für Dich vielleicht interessant, weil die Server-API über HTTP läuft und es bereits mindestens einen kommerziellen Server gibt, der das gleiche Protokoll spricht (Bayeux). Diese kommerzielle Implementierung, ist die einzige, die ich kenne, die direkt PHP unterstützt (WebSync).

Habe gerade das APE-Project gefunden:

http://www.ape-project.org/

Hat damit schon einmal jemand gearbeitet? Wenn es wirklich so toll ist wie auf der Website versprochen, kann man sich das Schreiben eines eigenen Servers doch sparen, oder?

So weit ich mir APE angeguckt habe, hat das auf der Server-Seite eine C-API, die müstest Du Dir dann wahrscheinlich nach PHP wrappen. Die Server unterscheiden sich auch häufig in den Protokollen, mit denen Sie die Verbindung zwischen Server und Client implementieren. Manche unterstützen z.B. nur Flash. Ich würde mir an Deiner Stelle CometD und WebSync angucken.

mfg Torsten

> Möglichkeit kommen grad auch die WebSockets auf, die in deinem Chrome schon drin sind.

WebSockets sind meines Wissens nach wegen Sicherheitsbedenken auf 'hold'.

TheUndeadable,

das stimmt, in der 10er-Version von Chrome wird es keine Unterstützung für WebSockets mehr geben.

Todi42,

danke, CometD hab ich mir gerade angeschaut. Ich glaube ich werde von dem Gedanken, das Spiel in PHP zu realisieren, vielleicht abrücken und statt dessen etwas in C zu schreiben. Oder eben Wrapper für PHP aber ich muss erstmal ein bisschen experimentieren um den Aufwand einschätzen zu können.

Warum entwickelst du trotz Alternativen deinen eigenen Server? Was hat er was andere nicht haben?

Original von Progralixx

Warum entwickelst du trotz Alternativen deinen eigenen Server? Was hat er was andere nicht haben?

 Ein Grund ist sicherlich, dass ich neben dem, wofür mich andere bezahlen, auch gerne mal etwas mache, was mir einfach Spaß macht. Auf der anderen Seite sehe ich bis jetzt nur 2 wirklich gut und kommerziel nutzbare Implementierungen (Lightstreamer und WebSync), da wäre also unter Umständen noch Platz für jemanden, dessen Lösung von vornhinein stark auf Performance und Skalierbarkeit (auf der Server-Seite) und auf Entwicklungskomfort (auf der Client-Seite) setzt.

Wenn die Entwicklung aber in dem Tempo weiter geht, bin ich eh nicht vor Ende des Jahres so weit, eine Prototypen-Applikation zu zeigen. Ende des Monats werde ich mal eine Woche am Stück Zeit haben, daran weiter zu arbeiten.

mfg Torsten