wie funktionieren NEtzwerkspiele?
-
Hallo Leute ,
Mich würde mal interessieren mit welchen Netzwerkprotokollen
und Lösungen bei der Software von Netzwerkspielen gearbeitet wird.
Wenn man zB diverse Poker-Netze sieht sind dort mehrere tausend
Spieler angemeldet und man merkt kaum große Zeitverzögerung.
Oder bei Online-Spielen müssen ja eine Menge von Informationen
über das NEtzwerkprotokeoll ausgetauscht werden.
Wer weis wie das funktioniert?
Mit Sockets und TCP/IP oder gibt es da etwas anderes?
Mehrere Server?Gruß Linus
-
Naja ich denke mal TCP eher weniger, da es für so etwas relativ langsam ist. Meistens dürfte wohl UDP verwendet werden. Ob es mehrere Server gibt hängt halt vom Spiel ab. Wenn es ein großes über die Welt verbreitetes Spiel ist, dann werden da bestimmt mehrere Server eingesetzt, alleine schon wegen der unterschiedlichen Latenzzeiten.
-
Worin besteht denn der eigentliche Unterschied zwischen UDP und TCP?
-
-
Also wenn ich das richtig verstehe sind die Daten bei UDP nicht
gesichert.Dann stellt sich mir aber doch die Frage bei zB wie
vorher gefragt bei Pokerspielen das Protokoll aussieht , denn dort
denke ich müssen die Daten gesichert ankommen. Aber auch dort nehmen
ja bis zu 10.000 Spieler an einem Spiel (Turnier) teil.
Oder ist die Wahrscheinlichkeit der Fehler so gering, dass diese einfach
in Kauf genommen werden?Edit:
Hängt die Sicherheit der Daten vielleicht von der Größe / Menge der Pakete
ab?
-
Naja es ist ja nicht so, dass man einfach nur pur UDP verwendet, man baut sich natürlich schon sein eigenes an das Spiel angepasste Protokoll basierend auf UDP auf, d.h. man kann natürlich durchaus reagieren wenn man igendwo merkt dass was verloren ging. Manche Anwendungen sind natürlich aber auch tolerant gegenüber Paketverlusten. Hängt immer davon ab. Es ist ja auch nicht so, dass kein Spiel TCP verwendet; nur verwenden die meisten halt schon UDP. Übrigens ich hab noch nie ein Netzwerkspiel oder so programmiert und kenn mich damit auch nicht wirklich aus... aber von TCP/UDP allgemein hab ich schon bisschen Ahnung. Gibt bestimmt Leute hier, die dir konkret näheres sagen können.
Oder ist die Wahrscheinlichkeit der Fehler so gering, dass diese einfach
in Kauf genommen werden?Die Wahrscheinlichkeit dass was verloren geht kann man so nicht bestimmen. Sicher ist es nicht so, dass z.B. jedes 2.te Paket verloren geht, aber es ist sicher auch nicht so, dass man sich darauf verlassen kann, dass so gut wie alles ankommt.
Hängt die Sicherheit der Daten vielleicht von der Größe / Menge der Pakete
ab?Natürlich... je mehr Pakete du verschickst, desto höher ist verständlicherweise auch die Wahrscheinlichkeit, dass mal eines verloren geht. Andererseits: Wenn du nur wenige eher große Pakete verschickst, dann musst du natürlich bei einem Paketverlust auch so ein großes Paket nochmals verschicken.
-
Egal ob du nun TCP oder UDP verwendest, im Endeffekt werden immer nur Packets versendet, und die müssen nicht immer ankommen -- kann keiner garantieren. Bei TCP kümmert sich halt der Netzwerkstack darum dass Packets die verloren gegangen sind neu übertragen werden und das alles. Bloss wenn die Verbindung wirklich ganz schrecklich mies ist, dann kann auch eine TCP Verbindung "zusammenbrechen" obwohl die Gegenstelle eigentlich noch da wäre. Nach einer gewissen Anzahl von Wiederholungen entscheidet der Netzwerkstack eben einfach "da geht nixmehr" und gibt auf -- die Verbindung ist dann tot.
Bei UDP muss man sehr viel "zu Fuss" programmieren, die ganzen Bestätigungen schicken, Packets neu übertragen etc., dafür kann man auch selbst entscheiden wie oft und wie lange man es neu versuchen will wenn eben Packets nicht durchgehen.
Alle Netzwerklibs für Spiele bieten aber eigentlich die Möglichkeit Daten "reliable" zu übertragen, also so dass sichergestellt ist dass die auch ankommen. Oder eben man programmiert es sich wirklich selber.
Für sowas wie ein Pokerspiel wäre es allerdings u.U. auch möglich einfach TCP zu verwenden -- ich denke mal das kommt einfach nur darauf an wie viele Connections man gleichzeitig offen haben will.
-
Danke für die Antworten.
Wenn man jetzt davon ausgeht, dass man 10.000 Connections hat.
Diese wird der Server wahrscheinlich nicht alle nacheindander abfragen
um dann darauf zu reagieren. Das würde das Spiel denke ich zu träge machen.
Wie organisiert man das denn dann.
Werden die Spieler dann in Gruppen eingeteilt und diese in einem separaten
Thread behandelt?
Und was passiert , wenn ein Spieler (Connection) von einer Gruppe in die
andere wechselt? Wie wird die Verbindung (Socket) von einem Thread zum anderen
übergeben?
Sorry die vielen Fragen. Aber bevor ich anfange so etwas zu proggen will ich
erst einmal wissen wie das Konzept aussehen soll.
-
Wenn man jetzt davon ausgeht, dass man 10.000 Connections hat.
Diese wird der Server wahrscheinlich nicht alle nacheindander abfragen um dann darauf zu reagieren. Das würde das Spiel denke ich zu träge machen. Wie organisiert man das denn dann.Warum sollte er die ueberhaupt abfragen? Es waer doch viel logischer wenn die Clients sich melden, sobald's was neues gibt (push statt pull). Kommt aber logisch auf das Spiel drauf an.
Werden die Spieler dann in Gruppen eingeteilt und diese in einem separaten Thread behandelt?
Und was passiert , wenn ein Spieler (Connection) von einer Gruppe in die andere wechselt? Wie wird die Verbindung (Socket) von einem Thread zum anderen
übergeben?Im Normalfall waer's Wahnsinn, alle Verbindungen in einem Thread zu behandeln. Denn dann muss der Server alle einkommenden Daten nacheinander behandeln, d.h. zu Stosszeiten waer er viel zu langsam. Gleichzeitig ist 1 Thread je Verbindung zu viel wenn es wirklich 10.000 Spieler gibt, da waer der Server ja fast nur noch am Thread-Umschalten.
Ob es sich lohnt / bzw. ueberhaupt Sinn macht, die einzelnen Verbindungen so einzuteilen, dass zusammengehoerige Verbindungen im gleichen Thread laufen, kommt auf das Spiel drauf an
Aber bevor ich anfange so etwas zu proggen will ich erst einmal wissen wie das Konzept aussehen soll.
Oft hilfts, wenn du dir einfach einen Prototypen schreibst, und damit herumexperimentierst, dann siehst du, wie du's machen kannst und worauf du achten solltest.
P. S. Bitte ueberdenk die Zeilenumbrueche in deinen Postings!
-
[quote="Blue-Tiger"]
Aber bevor ich anfange so etwas zu proggen will ich erst einmal wissen wie das Konzept aussehen soll.
Oft hilfts, wenn du dir einfach einen Prototypen schreibst, und damit herumexperimentierst, dann siehst du, wie du's machen kannst und worauf du achten solltest.
Das kann ich nur unterschreiben. Wenn du sowas verteiltes programmieren willst, dann solltest du das in kleinen Schritten machen und immer vom sehr einfachen bis zum schweren. Das Problem ist halt, dass bei sowas die Fehlerfindung extrem schwer ist und du auch nicht einfach mal so wie normal debuggen kannst. Also immer schön Schritt für Schritt vorgehen
-
linus schrieb:
Danke für die Antworten.
Wenn man jetzt davon ausgeht, dass man 10.000 Connections hat.
Diese wird der Server wahrscheinlich nicht alle nacheindander abfragen
um dann darauf zu reagieren. Das würde das Spiel denke ich zu träge machen.
Wie organisiert man das denn dann.
Werden die Spieler dann in Gruppen eingeteilt und diese in einem separaten
Thread behandelt?
Und was passiert , wenn ein Spieler (Connection) von einer Gruppe in die
andere wechselt? Wie wird die Verbindung (Socket) von einem Thread zum anderen
übergeben?
Sorry die vielen Fragen. Aber bevor ich anfange so etwas zu proggen will ich
erst einmal wissen wie das Konzept aussehen soll.Bei UDP z.B. kann der Server recvfrom verwenden um auf das nächste Packet zu warten, egal von welchem Client es kommt. Du kannst dann z.B. mit einen Thread arbeiten, der immer bloss recvfrom aufruft, und das eingehende Packet sofort in eine Queue steckt, die dann von diversen Worker Threads abgearbeitet wird.
So müssen dann nicht 10.000 Verbindungen abgefragt werden...
-
Ich hatte schon einmal einen kleinen chat geschrieben(TCP) .Dort habe ich
die Sockets in einer For-Schleife abgefragt.
Ich denke ich sollte das noch einmal überarbeiten.Danke erst einmal für Eure Hilfe
Gruß Linus
