P2P oder CS

Zitat

von Nik

Auf der Buchenau LAN gab es ein großes Problem mit dem Netztwerk, dass sich ständig nicht alle Clients gesehen haben. Ob es mit der neuen Version U3 zusammenhängt, wurde bis jetzt nicht klar. Erst ein Zufall brachte die Lösung, indem man von der P2P zur CS Netztwerkarchitektur umschwenkte.

Als Laie kann man nur Mutmaßungen anstellen, aber eines ist klar, wenn die P2P Verbindung, wie beim letzten Einsatz Leviathan 9 nicht funktioniert, muss eine Lösung her. Eine Möglichkeit wäre eine CS Verbindung, ob sie letztendlich praktikabel ist, müsste ein Test ergeben. Die andere Möglichkeit, zurück zu U2.

Weil die Diskussion im Debriefing deplaziert ist, habe ich sie hierher verschoben. Mal sehen, wie sich das Problem lösen läßt.

Nik

CsO/ret 47th NRF

Alles anzeigen

nik

Wenn ich das richtig verstanden habe braucht es bei der CS Variante deutlich mehr Bandbreite bei jedem Nutzer, weil er aktiv jeden anderen Flieger Daten schicken muss im Gegensatz wenn bei PtP der Server das erledigt. Auf einer LAN kein Problem, aber über Internet....

Achja... Stimmt was Nik da schreibt... Da hatte ich den selben Denkfehler wie Bumi.

Peer 2 Peer wird von BMS angestrebt.

Wenn das bei zwei Rechnern nicht klappt sehen sich diese beiden "nur" über die Server-Verbindung. (was grundsätzlich auch funktionieren sollte).

Jedenfalls war das ein verblüffendes Problemchen - und ich war wirklich heilfroh als es dann mit dem CS-Trick doch noch gefixt werden konnte.

ICEMAN

Wichtig zu beachten ist, daß bei einer reinen CS-Verbindungs-Topologie:

a.: der Server (bzw sein Internetanschluss) ein vielfaches der Bandbreiten-Last schultern muss als bei P2P.

b.: jede Übermittlung von Daten tendenziell doppelte Latenz hat als bei P2P.

In einer LAN-Umgebung mit Bandbreiten im Gigabit-Maßstab und Latenzen in einer Größenordung von <1ms machen beide obigen Punkte a.: und b.: überhaupt keine Probleme, einfach weil die Infrastruktur sackschnell und latenzarm ist. Da lacht die Netzwerkkarte vom Server drüber, und die Switches im Flur ebenfalls.

Online, übers Internet sieht die Sache anders aus. Hier sind die Latenzen in der Größenordnung einiger dutzend Millisekunden und Bandbreite ist auch nicht im gleichen Überfluss vorhanden wie im LAN.

Die Verdoppelung von Latenzen ist spürbar - etwa im Fingertip oder beim Formationsstart, wenn es einem z.B scheinbar nie gelingen will, den Heben gleichzeitig und synchron auf den Tisch zu legen, oder vernünftig in Fingertip zu fliegen.

Die Server-Bandbreite kann zeitweise, intermittierend, manchmal scheinbar rätselhaft willkürlich, zum Problem werden, wenn zu viele Spieler gleichzeitig connecten, zu viele Objects gleichzeitig in der Luft sind (jedes Flugzeug, ausgelöste Waffe, Flare, Chaff, fahrendes Vehicle kostet Bandbreite und diese Anzahl kann jederzeit extrem variabel sein) und natürlich gleichzeitig das Internet ja auch in der Bandbreite schwankt (je nach Auslastung).

Wenn ein- oder zwei Spieler CS-connected sind, macht das in der Tat oft keine Probleme, weil vermutlich genügend Bandwidth-Reserven auf Serverseite da sind. Ein Problem kann es dagegen werden, wenn man diese Reserven aufbraucht, indem ALLE Spieler auf CS wechseln. Das ist eine gänzlich andere Situation für den Server.

Ich sage mal, Tests mit allen Spielern im CS kann man ruhig mal machen (und das KANN auch gutgehen, abgesehen von der verlängerten Latenz, die ist dann halt so), dann aber bitte richtig: Die Anzahl gleichzeitig bewegter Objekte muss in der Test-TE vernünftig dimensioniert werden, damit man eine konkrete Aussage machen kann, wie weit man gehen kann. Und dann muss man auch vernünftig nachher prüfen, ob und welche Objects verloren gehen, oder laggen.

Ich glaube auch, dass für eine stabile Verbindung gar nicht mal so sehr die Bandbreite sondern vielmehr die Latenz eine Rolle spielt und die hängt halt auch von der Entfernung ab (und die damit verbundenen Hopps in der Netzwerk Infrastruktur).

Und da liegt der Unterschied zwischen z.B. Nik <-> Hummer und nIk <-> Server <-> Hummer bei Faktor 3 - nicht zu Vergessen die verlorenen Millisekunden durch die zusätzliche Verarbeitung auf dem Server selbst.

Ich werde bei den kommenden Missionen wieder vermehrt die Werte beim Server während der Mission beobachten. Am besten gelingt das, wenn ich als AWACS/ATC im Einsatz bin.

Gruss

Pitbull

Und jetzt kommt der große Mindfuck.

Auf der LAN hatte ich ein kurzes Gespräch mit Dunc über dieses Thema.

Disclaimer: Ich bin absolut kein Netzwerkguy und kenn mich mit dem Zeug nicht aus.

Auf jeden Fall hat Dunc mir erzählt das BMS physikalisch gesehen sowieso nur CS kann und P2P bei BMS eine reine Softwaregeschichte ist.

Ob das jetzt wirklich die Bandbreite und Latenz mehr belastet wenn alle CS anstatt P2P nutzen müsste daher denke ich einfach faktenbasiert getestet werden. Wie gesagt muss getestet werden und auskennen tu ich mich nicht, aber wenn das echt nur softwareseitige Unterschiede hat und keine tatsächlichen physikalischen, dann könnte die ganze Diskussion hier evtl. total sinnlos sein.

Nur um das zu verstehen,

Wir hatten doch bisher keine Probleme diesbezüglich. Warum ist das jetzt plötzlich ein Thema?

So war das nicht gemeint.

Ist das eventuell etwas das mit U3 zu tun haben kann?

Bisher (U2) hatten wir dieses Thema ja nicht.

Die Vermutung mit U3 hab ich auch schon in Verdacht gehabt.....

Lasst uns heute abend beim Flug mal systematisch vorgehen und beim Server joinen mit kurzen Abständen reingehen. Dadurch vermeiden wir daß bei gleichzeitigem Einsteigen die CS-Issues entstehen.

Also: Einer joint, sieht Anzahl Spieler (1).

Nächster Spieler kommt, sieht sich und den anderen, Anzahl gesamt: (2). Jeder, der was anderes sieht, meldet sich.

Dritter Spieler kommt rein, sie sich und die zwei anderen, Anzahl gesamt (3). Jeder, der was anderes sieht, meldet sich.

Damit die Tests aussagefähig sind. prüft jeder bitte vor dem Flug, und vor dem Online-Test, ob er an seinem Heimrouter (FritzBox) auch alle Portfreigaben noch so drin stehen hat, wie es soll. Daß der BMS-PC auch nach dem wiederanschließen daheim nach Buchenau noch die richtige IP-Adresse im Heimnetz hat, auf die die Portfreigaben verweisen. Daß alle bms-config Settings wieder so sind wie in der Staffelversion vorgesehen - alle Buchenau-Änderungen also wieder entfernt worden sind. Das die Windows Firewall entweder aus ist, oder für TS, IVC, BMS die notwendigen Freigaben auch wirklich drinstehen. Daß alle Hardware sauber funktioniert und Server Rejoins vermieden werden können

Wenn der IVC Verdacht gleich mit verfolgt werden soll, dann starten wir einfach den ganzen Test zusätzlich einmal vollständig ohne IVC diesen Test. Ich möchte allerdings die Erwartungen dämpfen. Ich hatte in Buchenau - mit den unmodifizierten-IVC-Client - die dortigen Probleme ebenfalls.

Zitat von nik

Und null Ahnung, ob die von den meisten installierte neue "IVC.exe" eine Auswirkung hat???

Kann ich mir nicht vorstellen. Da die neue Version ja netzwerktechnisch kompatibel mit der alten Version ist, sollte es hier also keine nennenswerten Änderungen gegeben haben. Glaube auch eher dass es dann an U3 selbst liegt.

An der liegts mit sehr sehr großer Sicherheit nicht. Kam in Buchenau ja erst zum Ende der Woche flächendeckend zum Einsatz, die Netzwerkprobleme hatten wir zu Anfang.