Hochlast-Java-Server für den Mehrspielermodus

Question

Ich mache ein Multiplayer-Spiel.Jetzt versuche ich, die Technologie auszuwählen, um die Android-Geräte mit dem Server zu verbinden.Die Clients laufen auf Android und das Spiel ist ein MMORPG.Ich möchte den Server in Java schreiben.Im Moment habe ich nur 3 Ideen dafür:

1) Erstellen einer Multithreading-Umgebung mit einfachem Java und Sockets.Auf diese Weise wird es einfacher, eine Vollduplex-Verbindung zwischen dem Spielclient und dem Server herzustellen.Aber ich habe folgende Bedenken:

1.1) Das Spiel ist ein MMORPG mit einer großen Anzahl von Objekten, und ich bin mir nicht sicher, wie solche Lösungen skaliert werden, wenn beispielsweise 5000 Personen gleichzeitig spielen.Wie viele Threads kann ich auf Java Machine ausführen?Wie kann ich das ungefähr berechnen?Für den Fall, dass 1 Thread für jeden Socket liest und 1 Thread in den Socket schreibt (also 2 Threads für 1 Spieler).

1.2) Wie kann ich mein selbst geschriebenes JAR-Archiv skalieren, um es auf mehrere Server zu verteilen, wenn die Anzahl der Spieler wächst?Vielleicht gibt es dafür einen besonderen Trick?

1.3) Viel Programmieraufwand – die Sockets-API ist recht niedrig.

2) Erstellen einer Servlet-Schnittstelle zur Bearbeitung von HTTP-Anfragen.

2.1) Einfache Steuerung der Sitzungen (und Autorisierung), solange jeder Spieler seine eigene Sitzung hat.

2.2) kann eine Verbindung zu Java EE EJB oder was auch immer herstellen – viele Komplikationen bei der Programmierung auf Systemebene entfallen.So kann ich mich auf das Schreiben von Geschäftslogik konzentrieren.

2.3) Kann alle Arten von Clients mit HTTP bedienen – mobile Geräte + Browser.

2.4) Hohe Geschwindigkeit – sogar ein Servlet-Container kann ein paar tausend Anfragen pro Sekunde bearbeiten, also ist es wirklich schnell.

2.4) Dieser Ansatz kann jedoch keine Vollduplex-Kommunikation ermöglichen.Ich muss jede Sekunde Anfragen senden, um nach Updates zu suchen.Eine Verzögerung von 1 Sekunde macht für das Spiel keinen großen Unterschied, da es rundenbasiert ist, erzeugt aber dennoch viel Verkehr.Ist es machbar, wenn viele Spieler spielen?Ich habe von einer COMET-Technologie gehört, aber es sieht so aus, als ob ich, wenn der Server viele Nachrichten hintereinander pushen muss, trotzdem jedes Mal Anfragen senden muss + diese Technologie ist noch nicht gut etabliert.

3) Sockets erstellen und über JMS mit dem Java EE-Server verbinden.

3.1) Cool, weil es eine Vollduplex-Kommunikation zwischen Clients und Server ermöglicht und alle coolen Funktionen von Java EE bietet.Später kann es über die Servlet-Schnittstelle auf den Browser erweitert werden.

3.2) Es scheint eine Art Overengineering zu sein.Ist es wirklich so, wie die Leute das tun würden?Ich meine, ist es überhaupt der richtige Weg?Würde irgendein vernünftiger Entwickler das so machen?

Ich möchte, dass Sie mir bei der Auswahl helfen.Ich habe nicht viel Erfahrung mit solchen Arbeiten.Und möchte mich an die Best Practices halten.

Answer 1

Warum umschreiben, was Sie von der Stange bekommen können?

Warum nicht verwenden? RedDwarf-Server (früher Projekt DarkStar)?

RedDwarf Server ist eine Open-Source-Middleware-Lösung für die serverseitige Entwicklung von Massively-Multiplayer-Online-Spielen.Es ist der offizielle Community-Fork von Project Darkstar, einem Open-Source-Projekt, das von Sun Microsystems unterstützt und verwaltet wird.- aus Wikipedia-Artikel von RedDwarf

Die Domain von RedDwarf scheint heute (12.06.2013) nicht erreichbar zu sein, aber es gibt immer noch eine Wiki, und sie migrieren zu a GitHub-Repo.

RedDward präsentiert seine Philosophie und Ziele wie folgt:

• Machen Sie serverseitigen Spielcode zuverlässig, skalierbar, beständig und fehlertolerant, und zwar auf eine Weise, die für den Spieleentwickler transparent ist.
• Präsentieren Sie dem Entwickler ein einfaches ereignisgesteuertes Single-Threaded-Programmiermodell.Der Code des Entwicklers sollte niemals aufgrund von Interaktionen zwischen Code, der verschiedene Ereignisse verarbeitet, ausfallen. (von dem RedDwarf-Tutorial)

Das bedeutet nicht, dass der Servercode Single-Threaded ist, sondern dass er aus der Sicht des Spieleentwicklers abstrahiert ist.Der RedDwarf-Tutorial Bietet viel mehr Informationen darüber, was RedDwarf tun kann, und erläutert viele seiner Designentscheidungen.

Ein Punkt, der Sie beunruhigt, war jedoch, dass die Multi-Node-Fähigkeit bei meiner letzten Überprüfung (ca.2011).

Von Grund auf neu

Das sollte Sie jedoch nicht davon abhalten, die meisten dieser Dinge von Grund auf zu versuchen, wenn Sie Wert auf die Lernerfahrung legen.Dies stellt jedoch einen großen Aufwand dar und wird ziemlich zeitaufwändig sein, und wie Sie in Ihrer Frage bemerkt haben, sind einige dieser Probleme im Tech-Stack eher auf niedriger Ebene zu lösen und werden die Komplexität Ihres Codes erheblich erhöhen Werde es beibehalten müssen.

Aber wie auch immer, was Ihre drei Optionen angeht, scheint mir Ihre erste die beste zu sein, wenn Sie sich für eine hausgemachte Implementierung entscheiden würden.Option 2 (Verwendung von HTTP-Servlets) scheint nur für einige Spiele geeignet zu sein, obwohl es meiner Meinung nach eine relativ gute Alternative sein könnte, etwas selbst zu implementieren und gleichzeitig an eine Middleware zu delegieren, und Sie könnten von vielen Webserver-Ergänzungen zur Bewältigung der Last profitieren ( Cache-Module usw.).Option 3 (mit JMS + JEE) scheint tatsächlich überentwickelt zu sein, aber es ist schwer, es genau zu wissen, ohne zu wissen, was Sie vorhaben.

Und wenn Sie hier sind, um zu lernen, dann deckt Option 1 offensichtlich einen weiten Bereich ab.Aber es wird ein ziemlich harter Kampf werden.

Answer 2

1.1) Sie können nicht in einem Thread pro Benutzer denken.Abhängig von der Maschinenkonfiguration können Sie jedoch Tausende von Threads laden, die Skalierung erfolgt jedoch nicht und es geht viel Zeit beim Thread-Kontextwechsel verloren.Stellen Sie sich besser ein NIO Netty-ähnliches Framework mit wenigen ein- und ausgehenden Thread-Pool-Executoren vor, die eingehende Nachrichten in Millisekunden ausführen.

1.2) Sie können einfach skalieren, indem Sie vor Ihrem Spieleserver eine Loadbalancer-Komponente platzieren, die eingehende Spieler entsprechend ihrer Auslastung an den richtigen Server weiterleiten kann

1.3) NIO kann Tausende bis Millionen Verbindungen auf einer einzigen Box verwalten.Machen Sie sich darüber keine Sorgen.

2.1) Verwalten Sie Ihre Player-Sitzungen und 2.2) bleiben Sie von der EJB-Architektur fern.Es verbraucht die gesamte Leistung Ihrer Box, anstatt die Leistung Ihrem Spiel zuzuweisen, was Ihr Ziel ist.

2.3) HTTP kann alle Clients bedienen, aber wenn Sie ein Echtzeitspiel ausführen, empfehle ich, Binär-Socket zu verwenden und HTTP nur für Lastausgleich, Anmeldung, Statistiken und Fallback beizubehalten, wenn keine Socket-Verbindung hergestellt werden kann.

2.4) Socket-basierter Server kann Hunderttausende eingehende Nachrichten pro Sekunde verarbeiten.Dies ist die Eigenschaft eines Systems mit geringer Latenz

Es ist zwar sehr interessant, in den Aufbau eines solchen Systems einzutauchen.Was ist dein Ziel?Lernen Sie, ein solches System aufzubauen oder Ihr Spiel erfolgreich zu machen?

Es gibt bereits viele Java-Multiplayer-Gameserver-Technologie-Frameworks.SmartFox Server, ElectroTank...

Wir haben unsere eigene Java-Hochlast Plattformübergreifender Multiplayer-Java-Spieleserver von Nuggeta das alle oben besprochenen Punkte und noch viel mehr anspricht.Wenn Sie es ausprobieren möchten, ist es kostenlos.

Wenn Ihr Ziel darin besteht, einen Spieleserver zu schreiben, ist das ein großartiges Unterfangen, das zwar viel Zeit in Anspruch nehmen kann, aber sehr spannend ist.Wenn Ihr Ziel darin besteht, Ihr Spiel erfolgreich zu gestalten.Nutzen Sie das bereits vorhandene Java-Gameserver-SDK.