Tests Serveur Falcon BMS

[Markus]

Bonjour,

Au Normandie-Niemen, nous cherchons des volontaires pour des vols test sur la version 4.33.U2.
En effet, nous savons que la version 4.33.U2 dispose d'une librairie Raknet pour gérer le code Multiplayer, au détriment de la libraire Etnet qui etait celle de la 4.33.U1.
Il semblerait qu'il y ait eu un rétro-pédalage sur le code réseau de Falcon BMS 4.33.U2, mais dans le bon sens.

Maintenant, nous avons plus de certitudes concernant les modes P2P et CS, et nous avons des normes pour savoir si nous devons nous connecter en P2P ou CS.
Ces modifications sont applicables dans le fichier : C:\Falcon BMS 4.33.U1\User\Config\falcon bms.cfg , avec la ligne de commande suivante pour passer avec le "1" en "CS", et le "0" en "P2P" : set g_bClientServerConnection 1 // Force CS connection

Ensuite, nous nous sommes intéressé au "Player Bump Time", qui est localisé à cet endroit : C:\Falcon BMS 4.33\Data\Campaign\Save\atc (Pour Korea (KTO) campaign par exemple).
Ce fichier contient une limite de 50 minutes pour tout appareil non pris en charge (I.A / Humain) dans le 3D, qui serait ensuite basculé passé 50 minutes en 2D.
Voici ce que l'on peut lire dans ce fichier :

"[ATC]
;This is the amount of time in minutes the player has from the
;time he enters the sim to get off the ground or get bumped back
;to the UI. (Note: regardless of this value the player is always
;given at least 1 minute past his scheduled takeoff time)
PlayerBumpTime = 50

;At what amount of time in minutes past their scheduled takeoff
;time is an AI plane yanked out of the sim (i.e. cancelled)
AIPullTime = 10

;How long in seconds the flight behind you will wait before going around
AIPatience = 120

;After a flight is this late (in seconds), and the flight behind it is
;also late, ATC will give the flight behind you clearance to takeoff,
;and tell you to wait.
ATCPatience = 180"

Nous avons dans l'idée de changer les paramètres de ce "Player Bump Time", sur une donnée qui permettrait à un "avion serveur" de rester en faction dans le 3D bien plus longtemps que 50 minutes. La valeur serait de 180, au lieu de 50 par exemple.

Ensuite, nous voulons tester les commandes suivantes :

set g_nRemoteControlSurfacesInterval 0 (position de surface de commande désactivé / sauf ops de support réglé sur une valeur par défaut de 200)
set g_bHostAllowsDubiousConnections 0 (pour désactiver les connexions douteuses)
set g_nForceMinClientBwSetting 2048 (ou 1024) (pour contraindre les clients à un réglage de bp convenu dans Falcon BMS.cfg)

Pour ces raisons de tests, nous serions contents que des pilotes puissent venir en nombre pour des tests en connexions importantes du coté clients.
Nous commençons ces tests le lundi 7 novembre à 21h.
Nous avons aussi le mercredi 9 novembre à 21h.
Le but n'etant pas de se disperser, afin d'avoir un maximum de clients en une seule soirée.
Merci de vous faire connaître, et nous vous enverrons les modalités de rencontre par MP.

Merci de votre aide.

@+Markus

[l3crusader]

En effet, nous savons que la version 4.33.U2 dispose d'une librairie Raknet pour gérer le code Multiplayer, au détriment de la libraire Etnet qui etait celle de la 4.33.U1.
Il semblerait qu'il y ait eu un rétro-pédalage sur le code réseau de Falcon BMS 4.33.U2, mais dans le bon sens.

Faux. Aucune version releasée de BMS n'a eu autre chose que Raknet. Et c'est pas Etnet, c'est Enet.

set g_nRemoteControlSurfacesInterval 0 (position de surface de commande désactivé / sauf ops de support réglé sur une valeur par défaut de 200)

Cf BMS-Manual, section finale.

set g_bHostAllowsDubiousConnections 0 (pour désactiver les connexions douteuses)

Simple ... tout ce que ca fait, c'est empêcher un joueur de se connecter si son port de connection est arbitrairement redirigé par sa box. Parce que c'est ca, une "connection douteuse" au sens de BMS... et c'est généralement signe de routeur pas fiable.

set g_nForceMinClientBwSetting 2048 (ou 1024) (pour contraindre les clients à un réglage de bp convenu dans Falcon BMS.cfg)

Cf BMS Manual... tout ce que ca fait, c'est empêcher un joueur de se connecter si sa BW indiquée est inférieure a la valeur donnée.

[Markus]

Merci pour ta réponse l3Crusader,

Alors d'après toi, quels sont les bons paramètres à utiliser au niveau du serveur, et clients ?

@+Markus

[PePe]

Merci pour les éclaircissements de Cruz...

C'était la question que je me posais en lisant le post de Markus : cela me donnait l'impression d'une campagne d'exploration d'une boite noire, alors que ceux qui codent le mode MP de BMS sont on ne peut plus accessibles pour répondre aux questions...

[l3crusader]

ceux qui codent le mode MP de BMS sont on ne peut plus accessibles pour répondre aux questions...

J'ai pas la prétention de "coder le MP" Mais j'ai une idée de comment ca fonctionne quand même.


A mon sens, voila ce qu'il y a à savoir sur le MP. Je fais un grand récapitulatif, donc il est possible qu'il y ait de la redite par rapport a ce que vous savez déja.
1/ Le serveur gèrera les IAs,
Donc ce sera a lui d'envoyer le trafic correspondant aux autres joueurs. Du coup, plus il y a d'IA, plus le serveur a intérêt à avoir un gros upload.

2/ Pour avoir le trafic typique par joueur ou par IA, et en situation de TE ou de campagne typique, cf BMS-Manual, section finale.

3/ Il y a 2 modes de connections possibles. P2P et CS.
En P2P, chaque joueur est chargé d'envoyer son propre trafic réseau a chaque autre joueur en P2P. Ca implique les choses suivantes :
- les ports des joueurs en P2P doivent être correctement routés. C'est indispensable pour que les autres joueur P2P puisse établir une connection sur vous, pour qu'ils puissent vous envoyer leur trafic directement.
- si il y a N joueurs en P2P (serveur compris), il faut que chaque joueur ait, en upload, (N-1)*trafic requis par joueur. S'il y a un grand nombre de joueurs en P2P, ca peut aisément dépasser les capacités d'un ADSL typique.
C'est le mode par défaut.

En CS, les joueurs ne se connectent qu'au serveur. Ca implique :
- pas nécessairement besoin de router les ports. Et c'est aussi un bon mode "secours" si jamais votre box fait chier, ouvre mal les ports, ou les redirigent arbitrairement (cf connection douteuse plus haut).
- demande d'upload réduite coté joueur CS, mais augmentée d'autant coté serveur. Normal, vous ne vous chargez plus de votre trafic vous-même, vous l'envoyez au serveur qui est chargé de le propager au reste.
Ce mode peut être mis via la ligne suivante a mettre dans [Install]User/Config/"falcon bms.cfg" :
set g_bClientServerConnection 1
Pas le plus pratique, je vous l'accorde, mais zut :p

Je précise également qu'il est possible que 2 joueurs se connectent en P2P, mais se voient mutuellement en CS sur le chat - et voient les autres correctement en P2P. Ca veut simplement dire que vous n'avez pas pu établir de connection entre vous 2 parce que... reasons. (Port mal routé, firewall qui fait chier, un lutin sur la ligne, que sait-je). Auquel cas le trafic allant de l'un vers l'autre passera par le serveur. La connection avec les autres joueurs que vous voyez en P2P normalement n'est pas affectée.


Ces généralités dites, il en découle les pratiques suivantes :
1/ Si vous envisagez de vous connecter a une partie quelconque en tant que joueur, posez vous la question : est ce que, vu le nombre de joueurs attendus, mon upload me le permet en P2P ? Ou est il plus sage de passer CS si le serveur peut le supporter ?
2/ Coté serveur, posez vous la question : est ce que mon upload me permet de gérer le traffic IA a envoyer a tout le monde, + ceux qui se connecteront en CS ?
Pour mettre des chiffres la dessus, allez voir dans le BMS - Manual En utilisation normale, pour le joueur, avoir 60-100 kbits par joueur P2P est une bonne valeur a prendre. Pour l'IA, c'est dans les 15 kbits par truc qui bouge (avion, char) . Les véhicules immobiles ont très peu de traffic.

En règle générale, pour des petits TEs et qq joueurs, les connections ADSL tiennent sans aucun souci. Si vous avez plein de joueurs, ou un gros TE/campagne, la ca vaut le coup de se poser la question.

Concernant le réglage Bandwidth, il faut savoir que s'il faut la renseigner, et que c'est une valeur unique, parce que F4 de l'époque se faisait sur des connections symmétriques (ie : pas ADSL) et que les librairies réseaux de l'époque était pas aussi perfectionnées que maintenant. Et que F4 (et BMS) bouffe pas mal de réseau :p
Du coup ce réglage est employé chez chaque joueur pour limiter ce qu'il envoie, et coté serveur pour limiter ce qu'il envoie a chaque joueur. Et je suis d'accord, atuellement, c'est pas un système optimal du tout du tout.
Du coup, je vous conseille d'adopter la pratique suivante :
- regardez votre upload en kbits. Valeur U.
- regardez ce que le serveur risque de vous envoyer, compte tenu de la situation. En gros, pour un TE sans trop d'unité au sol qui bougent, comptez 500. Pour une campagne standard ou un TE chargé, comptez 1000. Pour une grosse campagne ou un TE vraiment chargé, comptez 2000. Valeur N.
- renseignez le max entre U et N.

[eutoposWildcat]

Superbe résumé ! Est-ce que ça t'embête si je le copie en sujet de discussion épinglé ?

[Markus]

Oui, merci pour ce résumé Sir Lannister.

@+Markus

[l3crusader]

Superbe résumé ! Est-ce que ça t'embête si je le copie en sujet de discussion épinglé ?

Pas de souci

[eutoposWildcat]

Nickel, je fais ça de suite.

[Markus]

Pour ceux qui le peuvent,

Une participation de test est la bienvenue.
En effet, nous sommes le plus souvent entre 15 et 25 à voler régulièrement, et nous ne trouvons pas d'équivalent sur les forums (à par FOL qui malheureusement ne fonctionne plus depuis la 4.33.U1), pour avoir des retours sur la façon de gérer les paramètres serveur et clients sur des vols > 15 clients.
C'est pourquoi nous sommes désireux d'effectuer des tests grandeur nature, afin d'être sur des données concrètes pour une utilisation supérieure à un minimum de 12 clients.

Bien évidemment, les conseils donnés par I3Crusader seront appliqués.

Nous sommes en test ce lundi 7 novembre à 21h.
Faites vous connaitre par MP ou ici même.

Merci.

@+Markus