Netzwerk-Arten bei Spielen
-
Wird das nicht zwangsläufig sogut wie immer auf Client-Server hinauslaufen ?
(Wie nennt man das noch ? "Stern-Topologie" ? )
Wenn du viele Rechner synchron halten und gleichzeitig mit Daten versorgen musst, wüsste ich nicht was man sonst verwenden könnte
-
roan312 schrieb:
Ich frage das da ich von meinem Computer wegen zu geringem Upstream schlecht die gesamte Datenlast eines 500Player Spieles auf mich nehmen kann.
Entweder dicken Server für 50 € / Monat mieten,
oder mit sowas wie edonkey klar kommen:
d.h. viele Server, die auch untereinander kommunizieren können, und jeweils Clients (die auch -> P2P untereinander kommunizieren können)...
-
also nen simpler Netzwerkserver der ne Liste von ca 500 Sockets verwaltet wäre nen Anfang, oder?
Die Sockes sind am Günstigsten public-Teil einer Klasse *Spieler* die sämtliche serverseitigen Funktionen abdeckt (inclusive Kommunikation unter den Clients)Aber programmieren werd ich's nicht
-
Mit dem zentralen Server ist das wohl am besten gelöst. Das hat den Vorteil, das es ein zentrales Organ gibt, das das ganze Chaos ordnen und Überwachen kann. P2P ist wiederlich zu programmieren - Hab vor kurzem einen kleinen LAN-Messenger geschrieben der auf P2P Basis arbeitet. Da tauchen wesentlich mehr Probleme auf, als bei einer "good-old" Client-To-Server Anwendung.
-
Cpp_Junky schrieb:
Mit dem zentralen Server ist das wohl am besten gelöst.
Aber eben nicht möglich bei 500 Leuten und regulärem DSL Uptraffic.
-
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.
