Netzwerk-Arten bei Spielen
-
Jaja, der Neid.
Bye, TGGC (Pipe my World.)
-
Jaja, so eine Ignoranz hätt ich auch gerne.
-
roan312 schrieb:
Jaja, so eine Ignoranz hätt ich auch gerne.
Hast du doch.
Bye, TGGC (Pipe my World.)
-
eine Frage: 30 bis 60 Byte 30 mal in der Sekunde.
Klingt für mich als ob da irgendein "Realgame" wäre wie ein 3D shooter.
Nur: für 500 Leute? Außerdem bezweifele ich dass ein p2p Netz das ganze schneller koordiniert bekommt (ok, die dafür nötige struktur will ich mir gar nicht vorstellen). Von technischem her sind 500 "standard" 4KB Threads für einen vernünftig programmierten Server kein Problem. Was den durchsatz angeht: ist es wirklich nötig soviele Daten 30 mal durchzujagen? Reichen da nicht schon 15 mal oder gar 5 (je nach dem was genau für eine art Spiel das ist).Mir fallen im Moment auch keine kommerziellen Spiele (ala 3d shooter) ein, die soviele Mitspieler unterstützen. Dann noch zu den 60 Bytes: ich nehme an das sind die positionsdaten.Wie wäre es denn statt immer komplett die Daten zu übermitteln nur die geänderten zu übermitteln? (Der zum vergleich nötige CPUmehraufwand hält sich wohl in Grenzen
wenn man das vernünftig realisiert dann müsste es ganz gut klappen aber man kann ja alle 1 bis 5 Sekunden das "Ganze" datenpacket rüberjagen - zur synchroniesierung so zu sagen. Wenn ich jetzt so rechne:
16 Byte änderungsdaten (X,Y,Z + Zustand) mal 15 mal 500 dann hab ich 120 kbps raus. Wenn man dann sagt: ok, es müssen doch 30 Bytes rübergejagd werden:
30 mal 10 mal 500 = 150 kbps.PS: was mir so einfällt: damit es auch sinn macht 30 mal in der Sekunde die Daten zu aktualisieren müsste man doch mindestping von 33ms haben und das ist außer bei LANs wohl eher unrealistischer Wert.Wenn man vom Durchschnittsping 60ms ausgeht (ok, ich als Modemer kann das eher vergessen
) dann macht es sinn maximal ca. 15 mal pro Sekunde Daten zu übertragen.
-
Ich finde es sowieso sinnlos sich an eine Spielerzahl zu halten, außer es soll ein Privatserver werden, für den sich alle erst mal ne Lizenz zum spielen holen müssen oder das Spiel is so scheiße, dass es nur 500 Leute spielen (sorry, aber 500 im Vergleich zu ungefähr 6 Milliarden auf der Welt lebenden Menschen is ein kleines Bisschen zu wenig und ich geh jetzt mal von nem Internetgame aus, da du von DSL geredet hast
). Das mit dem System kommt immer drauf an. Wenn ein einziges Spiel (also eine Partie, welche z.B. 30Min dauert) 500 Spieler hat, dann wirds kompliziert (zumindest bei Realtime), da das ein normaler Client nich hinbekommt. Desswegen kommt da P2P schonmal nich in Frage. Ein Server (sind normalerweise mehr...) is im Internet normalerweise notwendig, da dein Game sonst, um die Lobby anzuzeigen, per Broadcast das ganze Internet durchsuchen müsste, damit es weis, auf welcher IP Adresse das Spiel noch läuft. Das könnte dann einige Zeit dauern (mein LAN Chat braucht schon 20 Sekunden um einen einzigen Port zu scannen). Verabredungen werden so auch schwer, da man schließlich bei jedem Mal einloggen im Internet ne neue IP bekommt (DHCP*). Ein Server bekommt also von DHCP ne statische IP Adresse zugewiesen, an welche sich dann die Clients wenden, wenn sie in deinem Spiel die Multiplayer Funktion aktivieren. Sie tragen sich dann dort ein, es werden alle Daten vom Server überprüft (z.B. Passwort, etc.) und dann bekommt der Client vom Server die Liste an verfügbaren Spielen zugesendet. Diese Liste wird selbstverständlich immer aktualisiert (zumindest auf dem Server), deswegen gibt es die "Aktualisieren" Funktion bei Spielen, da diese Prozedur nicht nur für den Server, sondern auch für den Clienten länger dauern kann (Die Liste is relativ groß und bis alle Daten versendet werden, was vielleicht sogar mehrmals gleichzeitig funktionieren soll, dauerts ne Weile). Beim aktualisieren wird dem Server eben dein Wunsch zugeschickt und der sendet dir (dem Clienten) dann die Liste.So, jetzt nehmen wir mal an, die Lobby is leer, zwar schwer zu glauben, aber mal angenommen... Du machst ein Spiel auf, welches dann aber logischerweise nich über deinen PC läuft, sondern über den Server, in dem Fall bist du der Host. Du hast also sozusagen die Rechenkraft des Servers für die Dauer deines Spiels reserviert. Also hast du für diese Dauer Kontrolle darüber, was mit der Rechenkraft passiert, ob z.B. Leute gekickt werden, ob einer diese nur zum Snipern benutzt, etc.
Ok, das wäre also geklärt. Der Host ist also nur eine Art Repräsentation für die reservierte Rechenleistung des Servers. Er gibt der Leistung einen Namen und teilt ihr Aufgaben zu, auch wenn dies unbewusst (vom Spiel aus) passiert, aber es is so.
Am leichtesten machst du's dir, wenn der Server nur ALLES weiterleitet und nix selber macht (Alles läuft nur durch nen Filter, welcher, den Server betreffende, Befehle aussortiert und ausführt). Ein Praktisches Beispiel ist gerade das Spieler aus dem Spiel entfernen. Lass das nicht den Server machen, sondern den betroffenen Spieler selbst. Denn egal, ob der Spieler nun bösartig oder gutmütig ist, das interessiert dein Spiel nicht und wenn es den Befehl erhält, das aktuelle Spiel zu verlassen, dann sendet es noch kurz nen Abschiedsbrief an den Server und gut. Schon wäre der Spieler weg und der Server hat nur nen Brief davon bekommen, das dieser Spieler nicht mehr zu dem Spiel gehört und jetzt wo anders Unfug machen kann, was dem Server allerdings egal ist.
Ebenso is es beim connecten. Der Spieler klickt auf ein Spiel und sendet dadurch eine Nachricht an den Host. Dieser entscheidet dann ob der Client rein darf oder nich (vielleicht Spiel voll oder ähnliches). Bei Koordinaten, etc. funktionierts gleich: Der Server bekommt die Daten mit allen Adressen der Kunden (Clients), die diese Daten bekommen sollen und schickt sie an diese.
Über den Ping erfährt der Server einiges über die Verbindungsgeschwindigkeit des Clients, falls dieser also nicht antwortet, weiß der Server, dass der Client einen Verbindungsabbruch o.ä. hat und schickt das dem Host, welcher entscheidet, was damit passieren soll. Seine Entscheidung sendet er den Clients und die machen daraus dann mehr. Z.B. Lässt der Host dem Client noch ne Frist, falls er doch nochmal auftaucht oder er lässt abstimmen, ob der Client raus fliegt...
Dass das alles nicht von einem einzigen Server gemacht wird, is hoffentlich klar. Was da zwischen den einzelnen Spielern arbeitet sind ganze Rechenzentren, welche im Normalfall den Publishern des Spiels angehören, da die Entwickler sich das nicht Leisten können (wenn sie nich grad Valve heißen...).
Also... ich hoffe, dass nun klar ist, dass die Geschichte mit dem Internet komplizierter is, als es eigentlich aussieht und mit Spieleprogrammierung hat das schon gar nix mehr zu tun.
(Mit dem Thread hab ich eigentlich 2 Beiträge verdient!!!
)... Aber egal .Wer Rechtschreibfehler findet darf sie als Souvenier behalten und wer Sachliche Fehler findet, soll sie bitte posten...
//edit
Wegen dem DNS, war falsch
DNS is für eindeutige Namen zuständig, wie z.B. www.c-plusplus.net, o.ä.
* DHCP (anstatt DNS):
DHCP (Dynamic Host Configuration Protocol) erlaubt es einem Server dynamisch Daten an Clients zu verteilen. (In diesem Falle ist der Server noch viele Stufen über dem Server, über den ich geredet hab). Zu diesen Infos gehören unter anderen:
- IP Adresse
- Subnetzmaske
- Standard Gatewayedit//
MfG WirrWar2850.
-
Hab das mit dem Broadcast jetzt mal ausgerechnet, wenn man alle IP Adressen eines einzigen Ports scannt, bräuchte man 38Std und 25Min...
Währen dann ca. 4228250625 IP Adressen...MfG WirrWar2850.
-
roan312 schrieb:
Ich hab da folgende Idee(falls sie neu ist...) (...ist sie wahrscheinlich nicht):
Jeder Client wendet sich beim "Einloggen" erstmal an den Server, der übergibt eine gespeicherte Liste mit den Adressen aller Clienten an den "einloggenden" Clienten und trägt ihn in diese besagte Liste ein.Der Client benutzt diese Liste um mit jedem anderen Clienten eine TCP Socketverbindung aufzubauen.
Dir ist hoffentlich klar, daß sich Dein Traffic so im Vergleich zur C/S-Lösung vervielfacht!!?
Aber wer so mit TGGC umspringt, der weiß sicher bescheid... 
-
CDW schrieb:
Außerdem bezweifele ich dass ein p2p Netz das ganze schneller koordiniert bekommt
Ihr redet alle an der Problemstellung vorbei.
Der entscheidene Optimierungsfaktor ist SEIN UPTRAFFIC.
Sachlicher Fehler:
WirrWar2850 schrieb:
Ein Server bekommt also von DHCP ne statische IP Adresse zugewiesen,
Ich glaub', Du verwechselst da was...
-
Jo, stimmt
... DHCP is ja für Dynamische Sachen zuständig...
Der Server bekommt seine Adresse doch von DNS (soweit ich weiß)... denn damit ne eindeutige Adresse zustande kommt, braucht man auch ne statische IP und dafür is soweit ich weiß DNS zuständig...MfG WirrWar2850.
-
Das mit der Liste, mit der der Client dann selber die Verbindung aufbauen soll...
Wieso so kompliziert, wenn doch der Server das alles machen kann. Der Client selber nimmt mit den anderen Clients überhaupt keinen Kontakt auf, da der Server alles macht... z.B. sendet der Client dem anderen eine Nachricht, dann geht die über den Server, welcher, falls Probleme mit dem anderen Client auftauchen, eine Fehlermeldung zurückschickt...
Also wenn das Clientprogramm soviel arbeiten müsste, wie der Server, was in deiner Lösung notwendig wäre, dann könnte der selber nich mehr spielen (wenns überhaupt ginge)... das nennt sich dann Dedicated Server. Der gibt seine ganze Leistung dafür her, dass andere Leute spielen können, kanns dafür selbst nich mehr...
Anmerkung:
Selbst ein ded. Server is heutzutage über der Leistung eines normalen PCs, da er sonst viele Realtime Games nich packen würde. Und auf dem läuft im normalfall nur ein Spiel, auf den richtigen Spieleservern laufen mehrere tausend Games...MfG WirrWar2850.
-
WirrWar2850 schrieb:
Jo, stimmt
... DHCP is ja für Dynamische Sachen zuständig...
Der Server bekommt seine Adresse doch von DNS (soweit ich weiß)... denn damit ne eindeutige Adresse zustande kommt, braucht man auch ne statische IP und dafür is soweit ich weiß DNS zuständig...DNS macht aus "www.google.de" -> "65.57.123.34"
und DHCP vergibt gerade hochfahrenden Rechnern aus einem Pool (z.B. 192.168.0.51 - 192.168.0.100) eine feste IP -> z.B. 192.168.0.68
-
Sgt. Nukem schrieb:
DNS macht aus "www.google.de" -> "65.57.123.34"
Umgekehrt... 65.45.123.34 -> www.google.de
Sgt. Nukem schrieb:
und DHCP vergibt gerade hochfahrenden Rechnern aus einem Pool (z.B. 192.168.0.51 - 192.168.0.100) eine feste IP -> z.B. 192.168.0.68
Wenn das während dem hochfahren passieren würde, würde es ja im Netz Leute mit gleicher IP geben (währe nich auszuschließen) und dann könnte es derbe krachen... Das macht eher nen Server im Netz, der dir dann ne IP zuteilt
...(Ich geb keine Garantie auf die Antwort
)...MfG WirrWar2850.
-
1. Der DNS-Server ist für die Namensauflösung zuständig das heißt aus www.google.de -> 65.45.123.34
2. Entweder ein Rechner hat eine statische IP-Adresse oder er bekommt eine dynamische IP-Adresse vom DHCP-Server zugewiesen
-
Hallo nochmal und Danke für die enorme Beteiligung.
Sgt. Nukem hat recht, mein eigendliches Problem ist, dass ich mir wegen dem Upstream keine einfache Server<->Client Struktur erlauben kann,
desshalb muss ich auf irgendwas anderes umsteigen.[quote=CDW]15 mal 500 dann hab ich 120 kbps[/quote]
Jaja, das sind aber kilo byte, ich hab wohl nur ca. 128 o. 256 kilo bit upstream.Und das sind ja auch nur die Daten für einen Clienten der alles an 500 andere sendet!
Da ich aber 499 weitere habe würden die das ganze auch nochmal an 499 Clienten Senden.Und zu den 30-(60) Byte: 4 Byte als "Typ der gesendeten Daten" + 4 Byte als Frame + 12 Byte Als XYZ-Coords + 12 Byte als Pan,Tilt,Roll und da kommt bestimmt noch was wie eine Variable für Aktionen hinzu.
Bei der Methode, die ich mir überlegt hatte, hätte der Server eine minimale Datenlast.
Er sendet ja nur die "Client-IP-Liste" an neue Clienten.
Die Clienten müssten halt alles 499 mal senden.MfG RoaN;
-
roan312 schrieb:
Die Clienten müssten halt alles 499 mal senden.
hm, was glaubst du wer deine anwendung nutzt wenn du dein problem an jeden client weiterreichst?
-
steff schrieb:
roan312 schrieb:
Die Clienten müssten halt alles 499 mal senden.
hm, was glaubst du wer deine anwendung nutzt wenn du dein problem an jeden client weiterreichst?
Ich möchte nicht das Problem verschieben, sondern aufteilen.
Wenn ich das nun richtig verstanden habe müsste ein Server 500*499 packete senden.
Ein Client nur 499, also läge die Upload Last bei 0.2% von der des Servers.MfG RoaN;
-
WirrWar2850 schrieb:
Sgt. Nukem schrieb:
DNS macht aus "www.google.de" -> "65.57.123.34"
Umgekehrt... 65.45.123.34 -> www.google.de
Das wäre ja totaler Quatsch?!?
Ich verbessere Dich, weil ICH im Gegensatz zu DIR bescheid weiß...
WirrWar2850 schrieb:
Sgt. Nukem schrieb:
und DHCP vergibt gerade hochfahrenden Rechnern aus einem Pool (z.B. 192.168.0.51 - 192.168.0.100) eine feste IP -> z.B. 192.168.0.68
Wenn das während dem hochfahren passieren würde, würde es ja im Netz Leute mit gleicher IP geben (währe nich auszuschließen) und dann könnte es derbe krachen... Das macht eher nen Server im Netz, der dir dann ne IP zuteilt
...(Ich geb keine Garantie auf die Antwort
)...Natürlich macht das ein Server!! Der DHCP - Server!
WTF?
-
Achja:
So viele NW-Updates kannst Du Dir einfach nicht erlauben.Ausserdem würd' ich mir etwas wie Dead Reckoning angucken, um diese noch weiter runterzudrehen...
-
Sorry, aber mit Netzwerkarchitekturen beschäftige ich mich erst seit dieser Woche:
Was in aller Welt sin NW-Updates?
Und was ist Read Rekoning???
MfG RoaN;
-
NW = Netzwerk
Rest = google oder gamedev Seiten
