Softwarearchitektur - Meinungen und Ideen erwünscht

hallo,

Ich bin schon ziemlich lange am grübeln wie ich denn nun mein Browsergame am besten umsetze. Mittlerweile habe ich mich auf Java als Sprache festgelegt.

Die Softwarearchitektur sieht so aus das alle Komponenten per Socket-Verbindung mit dem zentralen Server kommunizieren. Dieser wird nur benötigt da es das xmlHttpRequestObject nicht ermöglicht auf verschiedene ports/domains zuzugreifen.

Dieses Konzept hat den Vorteil das man die einzelnen Komponenten auf verschiedene Server verteilen könnte.

Der zentrale Server soll dabei eine "persistente" Http-Verbindung zum Client offen halten.

Hat diese Architektur einen schwerwiegenden Haken oder habe ich irgendwas übersehen? Wie sieht es performance technisch aus?

Ob diese Architektur schwerwiegende Haken hat ist sehr schwer zu beurteilen, ohne mehr über das Geschäftsmodell des Spiels zu wissen. Wo werden die meisten Ressourcen benötigt?

Java als Plattform kann auf einem Server schon eine ganze Menge Concurrent User verarbeiten, immerhin ist es im Schnitt grad mal 4,6x langsamer als c++, da ist das Nadelöhr idR eher die zur Verfügung stehende Bandbreite. Wenn du nach Trennung von Engine, Datenbank und Ressourcenserver die bezahlbar verfügbaren 8GB DualCore 6000er noch ins Schwitzen bringst hast du zwischenzeitig vermutlich genug Zeit gehabt die beste Remotinglösung zu finden um Komponenten auszulagern.

Wenn du nicht öffentlich ins Detail gehen willst, dann mach dir doch mal selbst Gedanken nach folgenden Kriterien:

Wo steckt dein größter Ressourcenbedarf, und wie wächst er mit steigender Spielerzahl (linear, exponentiell)? Wie kannst du die hierfür nötigen Server skalieren, und welchen Mehraufwand im Datenaustausch und Synchronisation verursachst du dir damit?

Die interne Anbindung in einem Serverpool ist idR wesentlich besser als der öffentliche Zugriff, und häufig kostenlos, aber auch dies sind keine unbegrenzten Ressourcen.

Schlussendlich, wo liegt die Qualität in der Möglichkeit, die Komponenten auf verschiedene Server zu verteilen für dein System? Angesichts der erhöhten Komplexität, leistet es mehr als ein "ich könnte, wenn ich wollte"?

Gruß,

Stefan

Problem sehe ich vorallem darin, dass du mit dem xmlHttpRequestObject keine persitente Verbindung aufbauen kannst. Du kannst höchsten alle paar Sekunden pollen, und das kann ein bottleneck werden.

Alternative wäre da nur über ein mini Flash Objekt eine persitent Socket Verbindung aufzubauen ...

Original von 3TageBart

Der zentrale Server soll dabei eine "persistente" Http-Verbindung zum Client offen halten.

Das persistent bitte nicht allzu genau nehmen. (deshalb habe ich das auch in Anführungszeichen gesetzt ;) )

Ich möchte die Verbindung künstlich am Leben halten. Sollte sie durch irgendein timeout geschlossen werden wird sie einfach neu aufgebaut.  Wenn der Client Daten zum Server senden möchte muss das natürlich über eine andere Verbindung geschehen.

Original von BBana

Problem sehe ich vorallem darin, dass du mit dem xmlHttpRequestObject keine persitente Verbindung aufbauen kannst. Du kannst höchsten alle paar Sekunden pollen, und das kann ein bottleneck werden.

Doch, das geht. Financial-Rumors.de macht das so. So ist es möglich, updates vom Server an den Client zu schicken. Leider gibt es für die Technik keine (oder kaum) bestehende, funktionierende Lösungen auf der Server-Seite.

Das funktioniert zum Beispiel über "tricklen" der Html Antwort vom Server, ähnlich wie bei Teergruben für Spammail. Kann man implementieren, wie "sauber" man die Lösung findet sei mal dahingestellt.

Persistente Verbindung über Flash (zum beispiel über rtmp remoting) ist recht stabil realisierbar, damit würde sich auch die Ajax Einschränkung der gleichen Domäne lösen, zumindest derzeit noch ist das Flash ziemlich egal. Wenn man allerdings kein Flash verwenden will, dann ist echte persistenz aussen vor.

Zwei mögliche Alternativen zu pseudopersistenz wären ein "Heartbeat" der in festen Abständen generische Anfragen absetzt in denen zum Beispiel dem Client mitgeteilt wird, daß und wo neue Daten vorliegen, oder ein Prognose, zu welchem Zeitpunkt voraussichtlich mit neuen Daten zu rechnen ist. Ob und was von diesen Varianten praktikabel ist kann man nicht allgemeingültig beantworten, hier kommt es darauf an wieviel Realtime-Charakter der Spielablauf hat.

Echte Datenpushs vom Server sind sauber in solcher Konfiguration eher über Flash oder Java Clients zu realisieren.

Saludos,

Stefan

Persistente Verbindungen via XHR sind eigentlich relativ einfach, eine passende Serverlösung vorrausgesetzt. Alles was man tun muss, ist die XHR-Verbindung auf dem Server solange offen zu halten, bis neue Nachrichten zu verschicken sind. Wenn diese dann über die Verbindung verschickt werden macht der Client einfach die nächste Verbindung auf, welche dann in der Queue auf dem Server auf Nachrichten wartet. Man braucht dafür eben einen asynchronen Webserver, welcher es ermöglicht eine Verbindung, während sie inaktiv ist, vom verarbeitenden Thread oder Prozess abzulösen um selbigen für weitere Verbindungen frei zu machen. Ansonsten gehen einem ziemlich schnell die Threads/Prozesse auf dem Server aus.

Javaseitig unterstützen mittlerweile eigentlich die meisten gängigen Servletcontainer solche Features, "Continuations" bei Jetty oder der Comet-Support in Tomcat - was aber in beiden Fällen böse Hacks um eine strikt synchrone Servlet-API sind. Wenn man auf die Servlet-API nicht angewiesen ist bietet sich eine vollständig asynchrone Lösung wie z.B. http://www.simpleframework.org an. Da ist es dann auch ziemlich unerheblich ob gerade 10k oder 20k wartende Verbindungen in der Queue liegen weil die, ausser ein bisschen Kernel-Speicher für das Socket-Handle, keine Ressourcen verbrauchen.

Man braucht dafür eben einen asynchronen Webserver, welcher es ermöglicht eine Verbindung, während sie inaktiv ist, vom verarbeitenden Thread oder Prozess abzulösen

Ich dachte, dass dies Regel sei...

Original von Tron

Das funktioniert zum Beispiel über "tricklen" der Html Antwort vom Server, ähnlich wie bei Teergruben für Spammail. Kann man implementieren, wie "sauber" man die Lösung findet sei mal dahingestellt.

Du meinst wahrscheinlich http und nicht html. Bei Financial-Rumors.de ist die Antwort z.B. JSON. "Sauber" ist aus meiner Sicht kein Argument für oder gegen eine Lösung. Schon allein deswegen nicht, weil es keine saubere Definition von "sauber" gibt ;-)

Persistente Verbindung über Flash (zum beispiel über rtmp remoting) ist recht stabil realisierbar, damit würde sich auch die Ajax Einschränkung der gleichen Domäne lösen, zumindest derzeit noch ist das Flash ziemlich egal. Wenn man allerdings kein Flash verwenden will, dann ist echte persistenz aussen vor.

Dafür kommt man mit diesen Protokollen meist nicht durch firewalls, dass kann je nach Kundschaft ein show stopper sein.

Zwei mögliche Alternativen zu pseudopersistenz wären ein "Heartbeat" der in festen Abständen generische Anfragen absetzt in denen zum Beispiel dem Client mitgeteilt wird, daß und wo neue Daten vorliegen, oder ein Prognose, zu welchem Zeitpunkt voraussichtlich mit neuen Daten zu rechnen ist. ...

Wobei Ersteres nur eine komplizierte Form des pollens ist.

mfg Todi