Eigener Spieleserver sinnvoll? Viele Nutzer mit wenig Daten

SG1

Anders formuliert: Sicher ist es sinnvoll, einen Plan für die nächsten 2-3 Schritte zu haben. Du machst aber gerade den 10. Schritt vor dem ersten.

rapso schrieb:

Das wichtigste bei onlinespielen ist nicht einen plan zu haben fuer 1Mio spieler, sondern skalierbar zu sein.
jedes onlinespiel skaliert mit der userzahl, dein plan muss also sein eine architektur zu programmieren die sowohl 10 als auch 1000 spieler vertraegt. naeherst du dich den 500, wirst du pruefen ob dein spiel 10k spieler vertraegt und die noetigen tasks machen damit das klappt.

Das mit der Skalierbarkeit ist ein guter Punkt. Aber was wäre die erste Spieleranzahl bei der man Änderungen machen müsste? Bei normalen Onlinespielen wären das vielleicht die 10, 1000 bzw. 500. Die brauchen aber idR auch mehr Ressourcen. Mein Spiel wäre von der Server Interaktion jedoch weit weniger komplex. Von der Rechenleistung/Speicher wäen 200.000 Spieler gleichzeitig kein Problem. Ab einer gewissen Zahl wird es dann aber auch für einen Server zu aufwenidig, dann wäre Skalierbarkeit gefragt. Dies würde aber das Spiel viel kompliziert machen und die Server I/O sprunghaft erhöhen.

Frage ist also die erste Höhe der Spieleranzahl, die ein Server schaffen würde.

Aber ich denke ein Prototyp ohne extras und Grafik ist recht schnell machbar. Da könnte man die Leistungsfähigkeit des Servers testen. Spieler könnt man auch emulieren. Nur Frage, ob es dann einen Unterschied macht, wenn diese alle von der selben IP kommen, statt von unterschiedlichen.

TyRoXx

Ein TCP-Socket wird auf gängigen Betriebssystemen mindestens einige KB Speicher im Kernel belegen. Für SSL kommt noch einmal einiges im Userspace dazu. Dann brauchst du noch Datenstrukturen, um Matches und Spieler zu verwalten. Auch das wird weit über deinen geschätzten 50 Bytes pro Match liegen.

IP, TCP und SSL haben Protokolloverhead, der deine zwei Byte pro Sekunde um ein Vielfaches übersteigt.

Deine Schätzung von "100 CPU-Instruktionen" ist so daneben, dass ich mich frage, ob das hier ein aufwendiger Trolling-Versuch ist.

Wenn man 200.000 Spieler gleichzeitig hat, hat man völlig andere Sorgen als die Anzahl der Server, die man unterhält. Fang erstmal an Programmieren zu lernen. Mit der Zeit wirst du dann selber merken wie sinnlos deine Überlegungen waren.

rapso

B.Nutzer schrieb:

Aber was wäre die erste Spieleranzahl bei der man Änderungen machen müsste?

Darueber kann man entweder philosophieren, oder es messen.
(beim ersteren wird dir jeder eine andere zahl nennen). Das einfachste ist also, dass du das spiel zum laufen bringst und dann testest, wieviele connections du aufbauen kannst, und wie es laeuft.
Wenn es scheinbar dein erster gehversuch damit ist, ist die chance sehr gross, dass die limitierung nicht das ist, was du dir hier denkst, sondern was ganz anderes. (es ist ein erfahrungswert). Deswegen ist es am besten wenn du das messen wuerdest.

Von der Rechenleistung/Speicher wäen 200.000 Spieler gleichzeitig kein Problem. Ab einer gewissen Zahl wird es dann aber auch für einen Server zu aufwenidig, dann wäre Skalierbarkeit gefragt. Dies würde aber das Spiel viel kompliziert machen und die Server I/O sprunghaft erhöhen.

Frage ist also die erste Höhe der Spieleranzahl, die ein Server schaffen würde.

Die frage hast du ja quasi selbst beantwortet. 200k ist das limit, du misst wie schnell die nutzerzahl steigt, daran kannst du einschaetzen wieviel zeit du hast das anzugehen, dann schaetz du ein wieviel zu aendern ist und wieviel zeit das kostet.

wenn Arbeitszeit * 2 > (Nutzerlimit-Nutzerzahl)/Steigerungsrate, dann hast du keinen stress beim projekt.
(*2, weil du sichergehen solltest)

Aber ich denke ein Prototyp ohne extras und Grafik ist recht schnell machbar. Da könnte man die Leistungsfähigkeit des Servers testen. Spieler könnt man auch emulieren. Nur Frage, ob es dann einen Unterschied macht, wenn diese alle von der selben IP kommen, statt von unterschiedlichen.

mit der zeit wirst du lernen welche messdaten wie zu interpretieren sind. Wenn der prototyp schnell zu machen ist, waere das echt die beste investition deiner zeit!

Mechanics

200.000 Spieler gleichzeitig halte ich für völlig unrealistisch, das dürfte kein Server packen. Wie TyRoXx geschrieben hat, allein der Overhead von TCP/IP ist um Größenordnungen höher, als das was du dir vorstellst.

Ich glaube, in der c´t gabs mal einen Artikel über einen Betreiber von einem Schachserver. Ist schon Jahre her, kann mich kaum an was konkretes erinnern. Aber das war glaub ich jedenfalls so, dass sie auch mit nur einem Server auskommen wollten und das damals auch geschafft haben. Dafür mussten sie einiges selber programmieren.
Und das waren glaub ich nicht wahnsinnig viele Spiele, die sie gleichzeitig verwalten mussten, evtl. um die tausend. Schach ist einerseits komplexer, weil der Server zumindest die Gültigkeit der Züge überprüfen muss, und das schafft man nicht innerhalb von 100 Instruktionen. Andererseits ist da aber auch nicht sooo viel zu tun, deswegen war die Verwaltung der Sockets und Sessions vermutlich immer noch der limitierende Faktor.

Nicht 100 Instruktionen insgesammt, sondern pro Sekunde pro Match.
Dazu kommen (wie geschrieben) noch diese, die für den Datenaustausch zuständig sind. Die für Matchsuche habe ich aber tatsächlich vergessen. Wenn das dann 100.000 wären, wären das bei 5min Match im Schnitt 33 mehr pro Sekunde.
Arbeitsspeicher für Matchsuche auch vergessen, wärn dann ca. 100MB mehr.

Das mit dem Schach war guter Vergleich. Serverseitig ist meins aber noch ein ganzes Stück leichter.

Habe mal eine Single-Player version (ohne extras und Gafik) getestet. Wenn man allein die Rechenkapazitäten zur Spielzugführung betrachtet, könnte mein PC gleichzeitig über 100Millionen Spielzüge/Matches abarbeiten. Der Rechenaufwand für das Spiel selbst (auf dem Server) sollte also nicht das Problem darstellen.

Soweit ich gelesen habe ist UDP weniger teuer als TCP und reicht auch. Werde versuchen dies zu verwenden. Gesicherte Verbindung hat auch sein Vorteile, aber da werden keine sensiblen Daten gesendet. Cheaten kann man auch nicht. Höchstens unter falscher Idendität könnte man spielen. Da muss ich mir noch was einfallen lassen.

scrontch

B.Nutzer schrieb:

Soweit ich gelesen habe ist UDP weniger teuer als TCP und reicht auch. Werde versuchen dies zu verwenden. Gesicherte Verbindung hat auch sein Vorteile, aber da werden keine sensiblen Daten gesendet. Cheaten kann man auch nicht. Höchstens unter falscher Idendität könnte man spielen. Da muss ich mir noch was einfallen lassen.

Die "Gesicherte Verbindung" bei TCP bezieht sich weniger auf Cybersicherheit als darauf dass deine App sich keinen Kopf machen muss um sicherzustellen dass auch alles (und in der richtigen Reihenfolge) beim gegenüber angekommen ist.
(Das musst du sonst bei UDP nunmal irgenwie behandeln und coden)
Insofern benutze TCP! Es sei denn Du hast Realtime Anforderungen.

scrontch schrieb:

Die "Gesicherte Verbindung" bei TCP bezieht sich weniger auf Cybersicherheit als darauf dass deine App sich keinen Kopf machen muss um sicherzustellen dass auch alles (und in der richtigen Reihenfolge) beim gegenüber angekommen ist.
(Das musst du sonst bei UDP nunmal irgenwie behandeln und coden)
Insofern benutze TCP! Es sei denn Du hast Realtime Anforderungen.

Ich meinte nicht TCP direkt, sondern das auch genannte Secure Sockets Layer (SSL) oder heute eher Transport Layer Security (TLS) genannt.
Die Reihenfolge ist kein Problem, da nur aller 5 Sekunden ein Signal kommt (höchstens bei sehr schlechter Internetverbindung). Höchstens das eventuelle Ausbleiben der Nachricht kann Probleme machen.

rapso

Fang mit TCP an, bis alles funzt, danach UDP einzubauen ist nicht viel code. UDP ist nicht schwierig, aber kann viel debugzeit sein bis man alle seltenen faelle gefixt hat. fuer den prototypen waere das imho ein risikofaktor ohne vorteile.

spaeter macht natuerlich nur UDP sinn, damit kannst du selbst die packete/verbindungen verwalten und brauchst nicht den OS overhead.

Das Spiel ist recht datensparsam (für den Server). I.d.R. müssen pro Spieler nur etwa aller 5 Sekunden 2 Byte Informationen gesendet/empfangen werden. Pro Match (5min) einmal auch etwa 10-50 Byte. Pi mal Daumen kommt man dann im Schnitt auf:
-1Byte pro Sekunde je Match I/O.
-Arbeitsspeichernutzung je Match: ~50 Byte
-CPU-Insturuktionen je Match: <100 pro Sekunde (+Instuktionen für Datenempfang und senden)
-Festplattenspeicher je Spieler: 10 Byte
-Ping fast egal: <1sec

Was glaubt wieviele Leute da auf einer Maschine gleichzeitig spielen können?

1. die CPU-Instruktions-Angabe ist totaler Quatsch und absolut unrealistisch
- doch ein Trollversuch?

2. wenn du keine Erfahrung mit TCP/IP Server Implementierung hast kannst du problemlos einen miserabel skalierenden Server bauen - absolut problemlos
-Thread per Client - skaliert nicht sonderlich gut
-Proactor Pattern (z.B. wie bei Boost/Asio)
-Multiprocessing (nicht nur Multithreading)

3. wenn deine Kommunikation wirklich so trivial ist würde ich einfach mal
eine kleine Lösung bauen die mit 1000 Fake Clients testen und schauen ob alles ausreichend gut funktioniert, wenn du dann die 100.000 Marke sprengst schreibst du den ganzen Kommunikations-Code einfach in 1-2 Tagen um oder passt ihn an und fertig ist

4. wenn du schon so zahlen auf den Tisch legst wäre es schon mal ganz interessant was deine Test-Strategie für 100-200.000 Clients wäre, also ohne
echte 100.000 Clients oder mehr? Falls du da keinen Plan hast würde ich einfach mal Anfangen was zu machen - der TCP/IP-Server dafür wird mit Boost/Asio ca. 2-3h Zeit brauchen dann kannst du testen

definitiv wird eine einfach zu implementierende 100-1000 Client-Lösung nicht mit einer 200.000 Client Anforderung klar kommen - weil die ganz anders aufgebaut sein muss

SeppJ

Gast3 schrieb:

1. die CPU-Instruktions-Angabe ist totaler Quatsch und absolut unrealistisch
- doch ein Trollversuch?

Der Thread geht darum, dass jemand mit seinem selbstgeschriebenen Brettspiel mehrere hunderttausend Spieler gleichzeitig(!) erwartet¹. Was denkst du?

¹: Mehrere hunderttausend weltweit gleichzeitig ist zum Beispiel eine typische Zahl für solch kleine Nischentitel wie World of Warcraft.

rapso

wenn ihr helfen wollt, dann helft, wenn nicht, dann muesst ihr nichts schreiben. Aber worst case ist, falls ein troll einen forumsbereich vom thema abbringen will und hier jemand einen meta-chat ala "ist es ein troll?" anfaengt, denn: 100% beweisen koennen wir es nicht, einem legitimen user fahren wir an und ein troll haette seine genugtuung. Also nur hilfreich zum Thema antworten, bitte.

Sooo.., ich habe mal einen Prototypen mit UDP gemacht.

Durch Fehlerkorrekturen und Dinge, die ich noch vergessen hatte, sind, wie ihr schon vermutet habt, noch ein paar Instruktionen und Speicher hinzugekommen. Hält sich jedoch noch in Grenzen.
Jedoch, konnte ich leider nur bis etwa 28.000 Clienten testen. Da mir dann die Ports ausgingen und kein freier mehr gefunden werden konnte.

Dabei braucht der Server maximal 16.3MB Arbeitsspeicher und hat meist <1% CPU-Auslastung (beides Werte vom System-monitor). Höchste CPU-Wert, den ich gesehen habe war 2%. Ein Ranksystem für alle Spieler ist noch nicht mit drin.

Die 200.000 warn tatsächlich bisschen hoch gegriffen. War nur der worst bzw best-case. Und das auch nur um zu sagen, dass selbst dann die CPU/Speicher-Auslastung verschwindet gering wäre. Aber selbst, wenn die oben gennanten Werte 10 mal so groß wären, wäre das immer noch sehr wenig.

Mit 2 Spielern braucht es 14.1MB Speicher. Macht also ca. 80 Byte je Client (2.2MB mehr für 28.000). Bei 200.000 wärn das also insgesammt ca. 30MB Speicher. Da war meine Schätzung zwar 60% und 100% daneben aber trotzdem gar nicht mal so schlecht (50Byte und 15MB). Ich verwende jetzt schon, falls möglich sparsame Datentypen wie char und Co. Optimierung ist aber bestimmt noch drin.
Die Punkteliste/Rang von allen Spielern ist jedoch noch nicht mit drin. Auch die Suche nach gleichguten Gegner nicht. Dies wird an den Zahlen aber nicht groß was ändern.

Bleibt also bei der Frage, ob es auch Angebote für weniger ressourcenhungrige Server gibt. 28.000 Clienten für einen Server scheinen zumindest möglich.