Bandbreite und Stabilität BMS

  • Ich habe in den letzten Wochen viele Tests zum Thema Serverstabilität und insbesondere Bandbreitennutzung von BMS gemacht. Nun möchte ich Euch meine Erkenntnisse schildern und ich darf alle gleich warnen: dies wird ein langer und sehr technischer Thread und falls jemand nicht alles durchliest, bin ich nicht böse 8) .
    Was ich Euch im Weiteren schildern möchte, basiert auf Messungen in meinem LAN, einzelnen Beobachtungen während Hot-Missions und den Ausführungen im BMS-Manual ab Seite 280. Die folgenden Zeilen sind zum Teil Annahmen meinerseits und falls sich jemand mit der Materie noch besser auskennt, bin ich immer offen für eine Diskussion.


    Multiplayer-Session


    Als erstes möchte ich erklären, wie eine Multiplayer-Session aufgebaut wird.


    Zuerst eröffnet der Host eine Multiplayer-Session und danach verbinden sich die Klienten zum Host. Sobald sich ein neuer Klient zum Host verbindet, schaut der Host, wer schon alles verbunden ist und weist den neuen Klienten an, selber Verbindungen zu den anderen Klienten aufzubauen. Er übergibt ihm dazu alle bekannten IP-Adressen und Ports für die Verbindungen. Der neue Klient versucht nun, zu allen anderen Klienten eine direkte Verbindung aufzubauen und wenn diese Verbindung zu Stande kommt, wird dies im COMMS-Fenster mit P2P angezeigt. Wenn die Verbindung zu einem Klienten nicht zu Stande kommt, wird CS hinter dem entsprechenden Namen angezeigt. Gründe für ein CS können verschiedene sein: Das Port-Forwarding beim anderen Klienten funktioniert nicht (IPv6, oder Firewall im Router bzw. beim ISP-Gateway blockieren, etc.) oder der Verbindungsversuch endet in einem Timeout, weil zum Beispiel die Leitung zum anderen Klienten gestört oder langsam ist, oder der andere Klient vielleicht zu beschäftigt ist (weil sich gerade alle Klienten untereinander zu verbinden versuchen). Es kann also durchaus sein, dass mal ein CS da steht und beim nächsten Versuch kommt dann doch ein P2P zu Stande.
    Und übrigens: IPv6 heisst nicht automatisch CS. Denn je nach Internet-Provider kann es nämlich durchaus sein, dass die Port-Weiterleitung bei der Peer-to-Peer Verbindung zu einem IPv6-Klienten funktioniert. Bestes Beispiel hierfür ist Bumerang. Er ist bei mir immer als P2P aufgeführt, obwohl er in einem IPv6-Netz ist.


    Wenn also alles geklappt hat, dann hat jeder P2P-Klient eine Verbindung zum Host und zusätzlich eine Verbindung zu allen anderen Klienten gemacht.
    CS-Klienten haben nur eine Verbindung zum Host.


    Im Spiel werden nun über die Verbindung zwischen Klient und Host hauptsächlich Objektdaten zwischen den beiden Rechnern ausgetauscht. Der Klient schickt seine Positionsupdates (Position des eigenen Flugzeugs) zum Host und der Host sendet dem Klienten alle Positionsupdates der von ihm (Host) gerechneten Objekte, also zum Beispiel einer KI-Mig-29 oder einem Lastwagen am Boden etc.
    Über die Verbindung zwischen den einzelnen P2P-Klienten werden praktisch nur die Positionsupdates der einzelnen Klientenflugzeuge ausgetauscht. Dieser Austausch ist besonders für die Formationsfliegerei wichtig.
    Bei CS-Klienten machen diese Positionsdaten immer den Umweg über den Host.


    Eine kleine Ausnahme zu diesen Regeln bildet das Air to Air Refuelling. Sobald ein Klient beim AAR „cleared pre-contact“ ist, übergibt der Host den Tanker an den jeweiligen Klienten. Das heisst, ab sofort rechnet nicht mehr der Host die Position des Tankers, sondern der PC des Klienten rechnet den Tanker und dieser tauscht diese Informationen direkt mit den anderen Klienten über die P2P-Verbindung aus. Dies hat natürlich den Vorteil, dass die Positionen des Tankers und des Betankten auf demselben PC gerechnet werden und so die Spielstabilität beim AAR erhöht wird.


    Bandbreite


    Nachdem ich nun verstanden hatte, wie die Multiplayer-Architektur in BMS aussieht, stellte sich mir natürlich die Frage nach der Bandbreitennutzung, insbesondere hinsichtlich Stabilität eines Online-Games.


    Die meisten Klienten haben beim Internetprovider genügend Download-Bandbreite und der kritischere Faktor ist wohl eher die zur Verfügung gestellte Upload-Bandbreite. Deshalb war bei meinen Messungen und auch bei den folgenden Ausführungen der Schwerpunkt bei der Upload-Bandbreite.


    Meine Messungen ergaben, dass die Positionsupdates zu einem anderen Klienten über die P2P-Verbindung im Normalfall zwischen 20 und 25 kbit/s im Up- und im Download betragen. Wenn also 4 Spieler in einer Online-Session miteinander verbunden sind, dann braucht jeder Spieler ca. 75 kbit/s im Upload Bandbreite für die P2P-Verbindungen zu den anderen Klienten.


    Bei der Verbindung Host-Klient (= Upload des Hosts) konnte ich bei einer „leeren“ TE (nur eine „human“ F-16 im Spiel) einen Grund-Upload vom Host zum Klienten von ca. 34 kbit/s beobachten. Der Klient übermittelte umgekehrt ca. 25 kbit/s Upload-Daten zum Host.
    Für jedes zusätzliche Objekt, welches der Host gerechnet hatte, stieg der Upload um ca. 15 kbit/s. Dieser Wert deckt sich mit den Ausführungen im BMS Manual ab Seite 280. Als Objekt kommt hier so ziemlich alles in Frage: KI-Flugzeuge (inkl. Tanker), Missiles, Chaffs und Flares, etc. Interessant sind hier natürlich die Chaffs und Flares, welche bei intensivem Gebrauch die Server-Upload-Bandbreite in die Höhe schnellen lassen können.
    Die gerechneten Objektdaten werden übrigens nur an die Klienten übermittelt, wenn sie innerhalb eines 50NM-Bubble zu einem anderen, allen bekannten Objekt sind. Zum Beispiel: Wenn ein SEAD dem Strike 20 NM voraus fliegt, so wird die Position der SAM-Stellung erst an den Strike übermittelt, sobald der SEAD ca. 50NM Distanz zur SAM hat. Dies erklärt auch, warum im TacView-Tape gewisse Objekte nicht oder erst später auftauchen oder wieder verschwinden. Die Tape-Daten spiegeln quasi nur die vom Host und den anderen Klienten übermittelten Daten wider.


    Ein kleines Rechenbeispiel:
    Eine TE ist für vier human F-16 gebaut. Geflogen wird ein Air to Air gegen 2 KI-Mig-29 mit Unterstützung eines KI-AWACS.
    Auf Seite Klienten braucht es im Upload total ca. 100 kbit/s, nämlich ca. 75 kbit/s für die Positionsupdates zu den anderen Klienten (P2P) und ca. 25 kbit/s für die Updates zum Host.
    Beim Host werden in der ersten Phase des Luftkampfs pro Klient ca. 80 kbit/s Upload gebraucht (35 Grundlast, 2x15 für die Migs und 15 für das AWACS_Flugzeug) und mit vier Klienten im Gesamten also 320 kbit/s auf der Leitung gebraucht. Wenn dann die F-16 zwei AIM-120 und die Migs ebenfalls 2 AA-12 abfeuern, dann steigt der Gesamtbedarf im Upload bereits auf 560 kbit/s (140 kbit/s pro Klient).


    Es zeigt sich also, dass die Bandbreitennutzung hauptsächlich abhängig von der Komplexität einer TE und der Anzahl Klienten ist.


    Meiner Meinung nach ist die schwächste Stelle in einer Online-Session die Upload-Kapazität des Host. Wenn zum Beispiel eine TE mit vielen Objekten einen Upload von sagen wir mal 800 kbit/s generiert, so würde das bei 4 Klienten einen Server-Upload von ca. 3200 kbit/s erzeugen. Wenn nun dieselbe TE mit 10 Piloten geflogen würde, dann steigt der Uploadbedarf auf 8000 kbit/s und wäre bei meinem Server bereits am Limit meiner Leitung.


    Noch ein Beispiel, damit man sich ungefähr vorstellen kann, wieviel Bandbreite eine komplexe TE benötigt. Die fantastisch gebaute TE „Claw of Death“ erzeugte mit 9 Klienten einen maximalen Upload beim Server von ca. 7200 kbit/s.


    Bei komplexen TEs kann man übrigens mit einer einfachen Rechnung berechnen, wieviel Bandbreite beim Host Upload ungefähr entstehen könnte. Dabei gehe ich davon aus, dass die TE so komplex ist, bzw. so viele Objekte hat, dass diese Objekte mehr als 700 kbit/s generieren.


    Man rechnet einfach die Anzahl Klienten mal 800 kbit/s.


    Woher kommen diese 800 kbit/s?
    Wir stellen ja beim Verbinden immer die Bandbreite 1024 kbit/s ein. Nun vermute ich, dass BMS bei diesem eingestellten Wert den Datenstrom bei ca. 800 kbit/s begrenzt. Diese Begrenzung kann natürlich bereits Auswirkungen auf die Stabilität einer sehr komplexen TE haben. Ich vermute nun weiter, dass diese 800 kbit-Begrenzung den Server nicht zum Absturz bringen, sondern höchstens Lags im Spiel produzieren und die meistens Crashs wohl eher auf einen zu hohen Server Upload zurückzuführen sind. Im Falle meines Servers wäre das bei ca. 9000 bis 10000 kbit/s.


    Übrigens, die oben angegebenen kbit-Werte variieren zum Teil bei den Klienten. So gibt es gewisse Mitspieler unserer Staffel, bei denen sind die Werte aus mir unerklärlichen Gründen höher als bei anderen. Ich persönlich habe zum Beispiel bei einer Verbindung zu meinem Server häufig einen um ca. 20 kbit/s höheren Server-Upload als die anderen. Da ich aber im selben LAN wie der Server bin, spielt meine Bandbreitenbelastung keine Rolle. Auf der anderen Seite gibt es auch Klienten mit „sehr guten“ Werten, sprich mit tiefer Bandbreitennutzung, und das kann durchaus auch ein IPv6-Klient sein. So hat zum Beispiel Bumerang immer eine der tiefsten Server-Uploads.


    Selbstverständlich ist der Server-Upload bei CS-Klienten immer höher als bei den anderen Klienten und macht in der Regel ca. 40 kbit/s mehr Upload aus. Diese Mehrbelastung ist logischerweise abhängig von der Anzahl beteiligter Klienten. Je mehr andere Klienten, desto mehr Daten muss der Host dem CS-Klienten bereitstellen.
    CS-Klienten haben hingegen auch einen Vorteil: Wenn ihre Verbindung abreisst, so hat das in der Regel nur wenig Auswirkungen auf die gesamte Spielstabilität, da nur die eine Verbindung zum Host verloren geht. Ausnahme ist auch hier wieder das AAR. Wenn natürlich der CS-Klient den Tanker rechnet und dann die Verbindung zusammenbricht, kann das Auswirkungen auf die Stabilität haben.


    Falls nun jemand andere oder zusätzliche Erfahrungen in diesem Bereich hat, so darf er diese natürlich gerne hier mit mir teilen.


    Gruss
    Pitbull

  • Hi,


    (erstmal an Pitbull: Danke für diese Analysen!)


    mein letzter Stand (das habe ich nicht selber gemessen, sondern durch Hörensagen) war, daß stehende Einheiten/Fahrzeuge keine Bandbreite beanspruchen, sondern nur fahrende.


    Dies ist wohl darin begründet, daß stehende Einheiten keine Positionsupdates notwendig haben, und der BMS-Code diese dann auch (glücklicherweise) unterlässt.

  • gerade bei der 49th gefunden:


    Zitat

    Falcon Online hat was interessantes herausgefunden, außersem machen die dort die Tage einen Coop server auf.


    Zitat Zitat von Archer:
    First off i'd like to express my gratitude to everyone who attended the public meeting today. So as we discussed i will host the Korea Strong server tomorrow from 1600 GMT. Please note if you would like to fly block your port 2935 TCP and UDP from your Windows firewall.


    A little back ground for the guys who missed it today. By blocking this port you will connect as CS not P2P. This will give the server clear line to every connected client. No more data being exchanged between clients, everybody talk to the server since we all have always more download then upload.


    Interessanter Ansatz....

    Yippieayee...


    Viper
    C/O 47th VFS



    dragonfighters_sig_viper.jpg
    Intel® Core i7-6700K | ASUS Z170 PRO GAMING Mainboard | 32 GB DDR4-2133 |AMD Radeon RX6800XT Red Dragon 16GB DDR6 | Win 10 Pro |
    Displays: 1x Samsung 40" / 3 x 10" TFT / 1x 4,3" TFT / 1x 7" TFT | HOTAS Cougar FSSB-R1 | Simped Vario Pedals | 9 x Arcaze USB | 2 Arcaze LED Driver | AIC | Arduino Uno

  • Persönlich halte ich das Ports blocken um eine CS-Verbindung zu forcen für kompletten Nonsense.


    Worin soll der Sinn liegen die Standard-MP-Verbindung von P2P zu umgehen und auf das "Notprogramm" CS zu switchen. Der einzelne Client ist vielleicht etwas vom Upload entlastet, dafür knalle ich den Server mit Daten voll.


    Bin schon gespannt was bei dem Test rauskommt, ich sage mal ein Scheitern mit Pauken und Trompeten voraus ... 8)