Sollte ein Socket-Server und ein Game-Server getrennte Prozesse sein?

Nehmen wir ein einfaches Standard-Client / Server-Spiel an. Lohnt es sich für den Server, einen separaten Prozess zu haben, der auf Verbindungen und Nachrichten von Clients wartet und die Daten über lokale Sockets oder stdin an einen anderen Prozess sendet, auf dem der eigentliche Spieleserver ausgeführt wird?

Die andere Option wäre, beide Dinge in einem einzigen Prozess erledigen zu lassen. Eingehende Nachrichten in die Warteschlange zu stellen und in der richtigen Reihenfolge auszuführen, sollte kein störendes Problem darstellen.

Ich frage mich, ob sich die zusätzlichen Ressourcen zur Trennung der beiden "Aktivitäten" tatsächlich lohnen. Wie soll ich mich entscheiden? Ich würde gerne Vor- und Nachteile hören.

Aus Sicht des API-Designs stellt sich bei der Entscheidung, ob mehrere separate Kommunikationsprogramme oder nur ein Programm erstellt werden sollen, die Frage: Kann jedes Programm ohne die anderen sinnvoll funktionieren? Die Antwort hängt von Ihrem Projekt und Ihren Vorlieben ab.

Wenn sie nicht können , lohnt es sich nicht darüber nachzudenken. Offensichtlich sind sie so stark miteinander verbunden, dass sie keine wirklich getrennten Prozesse sind.

Wenn sie können ist und Sie sich vorstellen , dass Sie verschiedene Komponenten einsetzen möchten, um diese in Zukunft zu ersetzen, kann eine vom Betriebssystem bereitgestellte Prozessabstraktion hilfreich sein.

Wie viel es hilft, hängt jedoch vom Rest Ihres Tech-Stacks ab. Beispielsweise modelliert Erlang Dinge bereits intern als Prozesse, sodass Sie keinen großen konzeptionellen Nutzen daraus ziehen, wenn Sie sie auch in OS-Prozesse aufteilen. Es sei denn, Sie möchten diese Teile des Servers in einer anderen Sprache neu schreiben. Die internen Komponenten eines C ++ - Programms sind in der Regel viel enger miteinander verbunden und daher schwerer auszutauschen. Wenn Sie sie in verschiedene Betriebssystemprozesse aufteilen, können Sie später viel Arbeit sparen, wenn Sie solche Umstellungen vorhersehen können.

lohnt es sich, einen separaten Prozess zu haben, der auf Verbindungen und Nachrichten von Clients wartet und die Daten über lokale Sockets oder stdin an einen anderen Prozess sendet, auf dem der eigentliche Spieleserver ausgeführt wird?

Um zu beantworten, ob es sich lohnt, müssen Sie sich zunächst fragen, welches Problem Sie durch Hinzufügen eines speziellen Warteschlangendienstes lösen möchten. Wenn es dieses Problem löst, lohnt es sich; Wenn es ein Problem nicht löst oder wenn Sie von Anfang an kein Problem haben, dann ist es wahrscheinlich nicht.

Sehen wir uns einige Gründe an, warum einige Server eine mehrschichtige Architektur verwenden:

1. Lastenausgleich - Der Lastenausgleich ist sinnvoll, wenn Sie Ihre Arbeitslast auf mehrere Arbeitscomputer verteilen möchten. Wenn Ihr Programm Engpässe aufweist, die Sie einfach dadurch beheben möchten, dass mehrere Worker-Prozesse gleichzeitig auf demselben Computer ausgeführt werden, ist es auf lange Sicht am besten, den Engpass tatsächlich zu beheben. Als kurzfristige Problemumgehung kann es jedoch sinnvoll sein, Worker-Prozesse zu erstellen.
2. Privilegientrennung - Möglicherweise möchten Sie keine Sicherheitslücke in Ihrem Chat-Server, um automatisch auf Ihren Game-Server zuzugreifen, oder umgekehrt. Wenn Ihr Spieleserver von Ihrem In-Game-Chat-Server getrennt ist, können Sie Ihren Spieleserver und Ihren Chat-Server so konfigurieren, dass sie in einer separaten Sicherheitsdomäne leben (z. B. als unterschiedlicher Benutzer, mit unterschiedlichen Zugriffsrechten, unterschiedlichen Prozessbeschränkungen usw.).
3. Upgrade ohne Ausfallzeiten - Wenn Sie ein Upgrade ohne Ausfallzeiten erzielen möchten, müssen Sie mehrere Ebenen haben und das System so konfigurieren, dass beim Herunterfahren eines Servers für die Wartung dessen Anforderungen an die anderen Server in derselben Ebene weitergeleitet werden, um eine kontinuierliche Aktualisierung zu gewährleisten Bedienung.
4. Grenzwertüberschreitung - Wenn Sie das Socket-Limit, das Dateideskriptor-Limit, eine globale Interpretersperre usw. erreichen, können Sie dieses Limit möglicherweise umgehen, indem Sie mehrere Prozesse ausführen. Eine andere Möglichkeit, dieses Problem zu lösen, besteht darin, das Limit zu ändern. Dies ist jedoch nicht immer einfach, da der Kernel möglicherweise neu kompiliert werden muss oder Sicherheits- oder Leistungsprobleme auftreten können.
5. Begrenzung des Ressourcenverlusts - Sie möchten Software schreiben, bei der keine Ressourcen verloren gehen. Aber selbst in Sprachen mit vollständiger Garbage-Verwaltung ist dies in langlebigen Prozessen äußerst schwierig und in einer Entwicklungsumgebung nur schwer zu replizieren. Mit einer mehrschichtigen Architektur können Sie die Spielserver nach einer bestimmten Zeit oder Anzahl von Anforderungen abschalten und neu starten, um die Schäden durch Ressourcenlecks zu begrenzen, ohne den Dienst zu unterbrechen.

Ich bin mit Ratschenfreak einverstanden. Solange Sie einen einzelnen Gameserver haben, lohnt sich der Aufwand nicht.

Diese Architektur kann sich jedoch als nützlich erweisen, wenn Sie horizontal skalieren müssen. Wenn ein Gameserver nicht mehr ausreicht und Sie Ihr Spiel aus Performancegründen auf mehrere Gameserver verteilen müssen, kann die "Socket Server" -Architektur sehr einfach angepasst werden, um den Socket Server in einen Load Balancer zu verwandeln, der automatisch Verbindungen zu einem von vielen Backends weiterleitet Server.

Wenn Sie sich jedoch nicht sicher sind, ob Sie dies jemals brauchen werden, ist es wahrscheinlich, dass Sie zu diesem Zeitpunkt zwei separate Serveranwendungen entwickeln.

Dies ist wahrscheinlich nicht der Fall. Die meisten Sprachen verfügen über asynchrone Sockets, mit denen Sie mehrere Verbindungen gleichzeitig verwenden können, ohne zu blockieren, während Daten warten. Dies verschiebt den "Socket-Server" -Teil auf das Betriebssystem / den Kernel.

Bei einem expliziten Socket-Server fallen einige zusätzliche Kopien an, wenn Sie die Daten über den lokalen Socket übertragen. Eine Sache, die die Skalierbarkeit zunichte macht, sind zusätzliche Kopien, die Sie nicht benötigen.