Netzwerk-Arten bei Spielen
-
Warum nicht?
Okay, wqenn alle 500 gleichzeitig arbeiten, gibts nen Problem. Gehts aber um zeitweise Datenpakete, sollte das relativ glatt laufen..Es kommt aber auch auf das Datenvolumen pro User an..
-
Aber was nützt euch geteilter Traffic, wenn der Datenaustausch dadurch um so schwieriger wird ? Mal ein kleines Beispiel: Was passiert in einem P2P Netz wenn einer der Spieler das Geschehen asynchron werden lässt (durch welche Gründe auch immer) ? Wer hat dann das sagen, das die anderen warten sollen ? Was passiert, wenn sogar mehrere async. verursachen ? Angenommen man löst das durch einen "Super-P2P Client" der zwischendurch mal die Aufseher-Rolle einnimmt - Wer ist dann dafür zuständig wenn dieser ausfällt oder er selbst der langsamste ist ?
Es ist doch viel schwieriger viele kleine "quasi autonome" Stationen zu koordinieren als wenn ein zentraler die Führung übernimmt.
Ich würde sagen, nen guten Server mieten und den klassischen Weg gehen ist das beste. "Die grossen" machen es ja nicht anders
-
Cpp_Junky schrieb:
Es ist doch viel schwieriger viele kleine "quasi autonome" Stationen zu koordinieren als wenn ein zentraler die Führung übernimmt.
Ich habe nichts anderes behauptet.
-
Erstmal Danke für die vielen Meldungen.
DocJunioR schrieb:
Warum nicht?
Okay, wqenn alle 500 gleichzeitig arbeiten, gibts nen Problem. Gehts aber um zeitweise Datenpakete, sollte das relativ glatt laufen..Ich habe das ganze nicht umsonst in das Grafik/Spiele Forum geschrieben,
es sollen alle 500 gleichzeitig Arbeiten und ca 30-60 Byte 30 mal die Sekunde versenden.
Da bin ich mit meinen 128kbps Upstream echt am A****.
Da ich weder Geld noch nerv habe mir für 50€ im Monat einen Server zu mieten werd ich wohl auf so was wie einen p2p lösung zurückgreifen müssen.
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. An diese sendet er dann das ganze Zeug und empfängt es auch (Koordinaten ua.).
Wenn ein Client ein Verbindungsproblem hat, sendet er eine Meldung an den Server.
Dieser guckt ob das mehrere Clienten melden und entfernt den Defekten Clienten aus der Liste.Über die ja schon geöffnete Verbindung zu den Clienten schickt er dann entweder die gesamte Liste oder halt nur die veränderten Teile neu.
Meint ihr, dass könnte Funktionieren?
MfG RoaN;
PS.: Tschuldigung für dir Rechtschreibung...
-
Ich hab auch 'ne Idee: Lass es und bau dir statt dessen einen Hubschrauber.
Bye, TGGC (Pipe my World.)
-
Oder einen Zug
http://www.infoboard.org/fun/pics/roofletrain.gif
-
Dann aber keinen Chihawk (oder wie man das Ding schreibt).
Aber mal im Ernst, wieso sollte das nicht funktionieren?
MfG RoaN;
-
roan312 schrieb:
Aber mal im Ernst, wieso sollte das nicht funktionieren?
Wegen dir.
Bye, TGGC (Pipe my World.)
-
TGGC for President!!!
//EDIT: konnte ich ja nicht so stehen lassen...
-
-
Gut gut, werds nochmal editieren.
Aber immerhin weiß ich jetzt wieso alle auf dir rumhacken. :p
-
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.
