Check-Six Forums

PePe a écrit :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.

Hop, sujet ouvert. Un grand merci.

Donc si j'ai 900 en upload, que je sois serveur ou client je peux mettre 900 en bandwidth ? Et pas d'histoire de upload -25% de meskouillenski ?

Ou j'ai toujours rien pigé ? ^^

ENFIN un post clair sur ces fameux réglages de BW , avec le pourquoi du comment...
J'étais resté, comme Didi, sur cette valeur d'Upload-25% sans comprendre
Merci Cruz

Très intéressant ce mode CS pour les joueurs avec une petite connexion et un serveur blindé en upload.

Merci.

l3crusader a écrit : - renseignez le max entre U et N.

Le max ou le min ?
En tant que client si j'ai une BW limitée (U) et que je souhaite participer à une TE/Campagne chargée (N), on aura N >> U, même si je me connecte en CS.

Si je met N en BW, que va-t-il se passer ? La connexion ne tiendra pas la cadence. Du coup ça va "lager" de mon coté ? Ça va "lager" au niveau du serveur ?

Est-ce qu'un prérequis est de dire que si U < N, c'est même pas la peine d'essayer participer en multi ?
Auquel cas, Il faut mettre N sachant qu'il faut avoir U > N.

Je conseille de ne pas mettre plus de 70% - 80% de ton upload max sachant que tu as besoin d'un peu de marge et IVC...

de toute façon, c'est 1024 minimum en upload pour que ça fonctionne... Les connexions avec peu de bande passante, il faut passer en CS obligatoirement.

l3crusader a écrit : En CS, les joueurs ne se connectent qu'au serveur. Ca implique :
...
... vous ne vous chargez plus de votre trafic vous-même, vous l'envoyez au serveur qui est chargé de le propager au reste.
...


Concernant le réglage Bandwidth
...
Du coup ce réglage est employé ... coté serveur pour limiter ce qu'il envoie a chaque joueur.

En combinant ces 2 points me vient une question complémentaire :

Est-ce que le trafic propagé par le serveur des informations des clients en CS est inclus dans la limitation BW (du serveur, qui provient de la plus petite BW renseignée par les clients ?

Je pense que la réponse est OUI.
Ce qui veut dire que la limitation du BW à renseigner par les clients doit bien se faire vis à vis de l'Up-Load disponible pour ceux qui sont en P2P, MAIS surtout pas pour ceux qui sont en CS, car sinon ils vont limiter inutilement le serveur (qui se calera sur leur BW faible) alors qu'ils auront de toute façon un trafic réel en UpLoad très faible (un seul trafic vers le serveur). La dernière vérification (ou la première) à faire, c'est que le l'UpLoad disponible pour un client est bien au-dessus de cet UpLoad mini (60-100 Kbits dans ce qui a été écrit plus haut).

Le lien ci-dessous est un fichier EXCEL permettant de simuler le comportement d'une partie Multiplayer en fonction :
- de ce qui est prévu en terme de présence IA lors de la partie (avions, unités mobiles, armement en vol + flare chaffs)
- du nombre et des configurations Internet des participants (DownLoad, UpLoad)
- des types de connexions prévus (Serveur, P2P ou CS)

Il est basé sur l'éclairage apporté par Crus sur P2P / CS et une relecture approfondie des pages 84-85 (Impact du réglage BW dans BMS) et 280 à 294 (valeur des quantités de données transmises par type d'objet en présence) du BMS Manual

Bon test

BandWidth Calculator

Merci Checkpoint pour ton fichier Excel, il est très intéressant.

J'attends qu'il soit validé par un membre de BMS, même si je n'ai pas de doute sur tes calculs.

Moi aussi j'ai une question, puisque j'ai le sentiment de poser des questions qui au final, intéressent nombre de nous, surtout sur une partie essentielle de notre simu préféré, à savoir se connecter ensemble.

Pourquoi BMS ne mentionne pas dans son Changelog ses changements relatifs au code MP (Raknet / Enet) ?
Pourquoi ces lignes de parametrage serveur et client nous etaient-t-elles inconnues jusqu'à aujourd'hui ?
Et pourquoi nous dire dans ce cas que BMS n'a pas touché au MP depuis La 4.32 ?

Nous avons dû à un moment poser les bonnes questions pour recevoir des conseils et lignes de parametrage, mais un peu de façon sauvage, 10 ans des Buzzards pour un vol de masse, mais nous c'est toutes les semaines les vols de masse.
Vous n'imaginez pas comment, avec La 4.33.U1 on a pû se prendre le choux, à tel point qu'on etait sur le point de rétro-pédaler sur la 4.32. Et c'est pour découvrir aujourd'hui que la 4.33.U2 contient la librairie Raknet, qui etait celle de la 4.32 en terme de gestion MP.
Alors dans le même temps, sur une confiance établie sur les reponses de BMS à savoir que BMS nous dit ne pas toucher au code réseau, il est en réalité que BMS effectue d'importante recherches d'une version à l'autre.

Maintenant, est-ce que BMS développe sans La pertinence du vol de masse (<20), et ne considère pas la nécessité de développer et valider une solution réseau de masse ?
Je sais savoir que FOL est une structure de vol de masse, qui a largement participé à redonner confiance aux simmers sur la stabilité de Falcon BMS, et a de nouveau contribué à maintenir Falcon BMS dans une longevité qui risque de devenir légendaire pour un simu de cet age.

J'ajoute que ce qui est le plus important pour nous au Normandie-Niemen, c'est la stabilité reseau.
En effet, considerant que le développement sur l'aspect cosmetique et d'éléments nouveaux (nouvelles armes / nouveaux sous-modes avioniques / améliorations generales et genneriques / etc.) est infini puisque l'on peut toujours améliorer l'aspect realisme et realité virtuelle, il est preferable pour nous du Neu-Neu d'avoir surtout une base solide sur le code reseau et sa stabilité. Nous ne rechignons pas un gramme sur toute valeur ajoutée à chaque nouvel update, mais si nous avions été bien informé sur la partie MP pour chaque nouvel update, nous aurions pû faire des choix de versions, en pertinence avec nos besoins premiers. Cela permet de hierarchiser ce qui est important pour chaque escadron, et si pour certain le nombre de client n'est pas le facteur premier, il peut l'être pour d'autre et inversement.

Maintenant, je ne me permettrai pas de m'imisser dans une politique qui ne me concerne pas, et dont je ne fais pas parti.
Ces questions, je me les poses, peut-être que d'autres aussi, et cela ne reste que des questions auxquelles vous avez le droit de ne pas y répondre, puisqu'elles sont relatives à votre politique de développement, et qu'elles n'ont rien à voir en terme de résultats.

J'insiste bien sur le fait que ces questions ne sont que simple curiosité, et je comprendrai que vous ne vouliez y donner réponse si telle était votre décision, encore une fois.

@+Markus

Comme déjà expliqué, il est très dur de mettre en place un code MP avec des joueurs dont la connexion est médiocre et aux 4 coins du monde donc de toute façon, il est fortement recommandé d'avoir un serveur qui hoste des clients d'une même plaque continentale.

FO est une initiative qui a eu énormément de chance de fonctionner ainsi en 4.32, peut-être que le format devrait changer un peu en durcissant les paramètres de connexion et d'uload des clients.

En tout cas, 24 sur un serveur 100M en france, ça passe nikel !


A+

MaxWaldorf a écrit :FO est une initiative qui a eu énormément de chance de fonctionner ainsi en 4.32

MaxWaldorf, je ne crois pas que dans un contexte purement binaire, la "chance" y soit programmée.
C'est mon avis, mais j'attends d'être pourquoi pas, convaincu par le facteur "chance" auquel tu fais référence... .

@+Markus

Markus a écrit :Pourquoi BMS ne mentionne pas dans son Changelog ses changements relatifs au code MP (Raknet / Enet) ?
Pourquoi ces lignes de parametrage serveur et client nous etaient-t-elles inconnues jusqu'à aujourd'hui ?
Et pourquoi nous dire dans ce cas que BMS n'a pas touché au MP depuis La 4.32 ?

Nous avons dû à un moment poser les bonnes questions pour recevoir des conseils et lignes de parametrage, mais un peu de façon sauvage, 10 ans des Buzzards pour un vol de masse, mais nous c'est toutes les semaines les vols de masse.
Vous n'imaginez pas comment, avec La 4.33.U1 on a pû se prendre le choux, à tel point qu'on etait sur le point de rétro-pédaler sur la 4.32. Et c'est pour découvrir aujourd'hui que la 4.33.U2 contient la librairie Raknet, qui etait celle de la 4.32 en terme de gestion MP.
Alors dans le même temps, sur une confiance établie sur les reponses de BMS à savoir que BMS nous dit ne pas toucher au code réseau, il est en réalité que BMS effectue d'importante recherches d'une version à l'autre.

Bon alors, encore une fois....

TOUTES LES VERSIONS PUBLIQUES DE BMS (enfin, depuis la 4.32) ont le code Raknet.

Ca veut dire :
- 4.32 -> Raknet
- 4.33 -> Raknet
- 4.33U1 -> Raknet
- 4.33U2 -> Raknet.

Clair maintenant ?

Et puisque cette histoire Raknet vs Enet a l'air d'en obséder certains, c'est simple : un peu après que la 4.32 soit releasé, des questions se sont posées vis-a-vis de Raknet, et un switch sur Enet s'est fait EN INTERNE. L'expérience n'a pas été concluante et on est revenu sur Raknet. Enfin, je dis on, j'étais pas dans la team a l'époque.

Et pour info, Raknet c'est juste envoi/réception des paquets. En gros c'est la poste. Mais c'est BMS qui se charge d'écrire et de lire les lettres.

Maintenant, oui, le code réseau il évolue et c'est bien normal. On ajoute des trucs, on règle des bugs, etc. Genre buddy lasing. Genre ajout de DOF en MP. Ce genre de chose. Donc oui ca évolue, et on teste, et on débuggue. Sauf que débuguer des sessions de MP c'est pas du tout évident, a fortiori quand le problème n'arrive qu'a grande échelle. Trouver et régler des problèmes sur des sessions de 30 personnes partout dans le monde qui n'ont qu'une soirée a consacrer de temps en temps c'est a peu près infaisable. Ajoutez a ca le fait que les mecs compétents, il y en a qui arrêtent le dev, d'autres arrivent et doivent se former sur le tas, et ca peut donner des soucis de stabilité a grande échelle.

M'enfin les soucis on bosse dessus et on essaye de les régler quand on a des infos correctes dessus. Et je rejoins Max : si la 4.32 marchait bien a grande échelle, c'était 1/ parce qu' elle avait passé des plombes en développement interne, et 2/ par chance. Oui, ca peut être purement du bol que des bugs un peu vicieux se faufilent pas sous le radar.


Ah, et avant que qq arrive en mode "mais pourquoi vous faites vos tests dans votre coin, pourquoi FO / mon escadron / mes potes peuvent pas aider" : parce que. Les mecs qui font dans la team, on a entière confiance en eux, ils font du bon beta test, et ils savent faire des bug reports valides. Un mec random qu'on connait pas, déja il est pas du tout garanti qu'il fasse du bon taf, et ensuite ca peut aussi être un connard nuisible. (Et oui, j'ai des exemples bien précis en tête).


Je passe sur la "relation de confiance", j'ai une furieuse envie de rebondir mais Ghost va raler si je le fais

NB : Je demande à tout le monde : 1° de rester courtois 2° de ne pas forcément soupçonner chez autrui le dédain ou la malveillance.
Ce sujet de discussion est très intéressant. Ce serait dommage qu'il ne le reste pas.

Voilà, vous pouvez reprendre le cours de vos activités. Merci de votre attention.

Oui oui...., ne t'inquiètes pas Wildcat, je ne prends que la réponse.
Je ne m'occupe pas du ton sur lequel elle est donnée, ni sur les sous entendu de pics qui résident dans les réponses de I3Crusader à mes questions.
On ne peut pas plaire à tout le monde, et pour ma part, je ne connais pas I3Crusader, donc je n'ai pas à formuler quoi que ce soit de façon agressive.
Après, c'est peut-être son mode de communication naturel..., alors je ne m'enflamme pas... .

Donc, merci I3Crusader pour ces réponses.
Elles sont instructives, et nous permettent de mieux comprendre pourquoi ce qui fonctionne sur une version, ne fonctionnera pas pour autant sur une autre version, et comment aborder certaines différences qui ne sont pas forcément inclues dans le Changelog.

Cependant, dans la réponse de I3Crusader, I3Crusader mentionne que Falcon dispose de "Raknet" depuis la 4.32

l3crusader a écrit :Bon alors, encore une fois....

TOUTES LES VERSIONS PUBLIQUES DE BMS (enfin, depuis la 4.32) ont le code Raknet.

Ca veut dire :
- 4.32 -> Raknet
- 4.33 -> Raknet
- 4.33U1 -> Raknet
- 4.33U2 -> Raknet.

Clair maintenant ?:

Alors que Mav-jp, dans ce post ici, parle bien de Enet en 4.33 et 4.33.U1.
Ce qui expliquerait les modulations de stabilité à la connection... .

J'avoue ne plus bien suivre les réponses provenant de la même source (BMS), et comment établir de confiance nos protocoles de connexions ainsi que la stabilité reseau, alors que nous avons des réponses différentes sur une même question.

Maintenant, absolument rien de grave, il suffit d'avoir la bonne réponse... .

Sujet très intéressant... .

Ensuite,

l3crusader a écrit :Ah, et avant que qq arrive en mode "mais pourquoi vous faites vos tests dans votre coin, pourquoi FO / mon escadron / mes potes peuvent pas aider" : parce que. Les mecs qui font dans la team, on a entière confiance en eux, ils font du bon beta test, et ils savent faire des bug reports valides. Un mec random qu'on connait pas, déja il est pas du tout garanti qu'il fasse du bon taf, et ensuite ca peut aussi être un connard nuisible. (Et oui, j'ai des exemples bien précis en tête).

Heuuuu...., je ne me sens pas visé par cette remarque qui semble-t-il ne fait pas partie du sujet, mais puisqu'elle est là en réponse à ma question, j'y réponds au nom du Normandie-Niemen.
Jamais nous n'avons fait de demande de beta-tests à BMS.
Et qui plus est, je ne crois pas que notre groupe soit interessé. Je peux toujours poser la question, mais cela m'étonnerai fort... .
Et donc, oui, entièrement d'accord sur les barrières "anti-connards" nuisibles, nous faisons de même pour des relations saines... .

@+Markus

Markus a écrit :Alors que Mav-jp, dans ce post ici, parle bien de Enet en 4.33 et 4.33.U1.
Ce qui expliquerait les modulations de stabilité à la connection...

Mav a bien donné la même réponse que Crouze.
C'est pendant le développement de la 4.33 ("during 4.33 development") qu'il y a eu un changement vers Enet. Mais ça ne s'est pas avéré concluant, et il faut comprendre que, pour les versions définitives, ils sont revenus au Raknet.

EDIT : Par ailleurs, Raknet ou Enet ne fait pas tout le réseau. C'est seulement une partie du problème. Tu peux conserver Raknet d'un bout à l'autre et pourtant avoir des soucis du fait du changement d'autres choses.

Ok, effectivement, oui, je ne savais pas la 4.33.U1 avait été distribuée avec Raknet, Et non Enet.
En fait, il y a eu un test en interne avec Enet, mais une remise en place de Raknet sur la même version avant sa sortie.
Compris.

La différence reste colossale quand même, entre La 4.32, et La 4.33.U1.

@+Markus

CheckPoint a écrit :Le lien ci-dessous est un fichier EXCEL permettant de simuler le comportement d'une partie Multiplayer en fonction :
- de ce qui est prévu en terme de présence IA lors de la partie (avions, unités mobiles, armement en vol + flare chaffs)
- du nombre et des configurations Internet des participants (DownLoad, UpLoad)
- des types de connexions prévus (Serveur, P2P ou CS)

Il est basé sur l'éclairage apporté par Crus sur P2P / CS et une relecture approfondie des pages 84-85 (Impact du réglage BW dans BMS) et 280 à 294 (valeur des quantités de données transmises par type d'objet en présence) du BMS Manual

Bon test

BandWidth Calculator

Je vais jeter un oeil, merci beaucoup pour le taf

Pour info on a envie de bosser en interne pour rendre ca plus simple. Mais en attendant ca peut aider

Pour ta question précédente, concernant max(U,N), je confirme que c'est max. En fait, coté client, faut pas trop compter sur le réglage BW pour limiter ce que tu vas envoyer, il vaut mieux faire le calcul pour voir si l'upload qu'on a peut tenir le coup en P2P. Par contre, si tu renseignes un valeur de BW trop faible par rapport a ce que le serveur t'envoie, tu risques d'avoir des soucis. En particulier, il y avait un bug bien identifié, reproductible dans le cas ou un joueur seul renseignait une valeur de BW trop faible dans une situation chargée, qui menait a des vols "fantomes".On a réglé ce truc précis dans l'U1 (si vous allez sur le changelog de l'U1, recherchez g_bSkipAggregationBWCheck, c'était ça ). Mais en testant, on a aussi vu des trucs plus chelou genre des locks radars qui passaient pas, des DOFs mal updatés, etc. Donc faut quand même faire attention a pas mettre de BW trop faible par rapport a la situation. Mis a part ce fix la, la gestion BW a pas été touchée significativement - c'était un peu trop "touchy" pour une update, ca demande des tests aboutis.

Et qu'est-ce qui lie BMS à Raknet dans le choix de la librairie MP ?
Sa gratuité ?

Pourquoi des solutions comme SmartFoxServer ne serait-elle pas retenue ?
C'est un moteur fait pour les plateformes multiplayers de masse, et compatible C++.
ici.

C'est juste une question... .

@+Markus

l3crusader a écrit :

CheckPoint a écrit :Le lien ci-dessous est un fichier EXCEL permettant de simuler le comportement d'une partie Multiplayer en fonction :
- de ce qui est prévu en terme de présence IA lors de la partie (avions, unités mobiles, armement en vol + flare chaffs)
- du nombre et des configurations Internet des participants (DownLoad, UpLoad)
- des types de connexions prévus (Serveur, P2P ou CS)

Il est basé sur l'éclairage apporté par Crus sur P2P / CS et une relecture approfondie des pages 84-85 (Impact du réglage BW dans BMS) et 280 à 294 (valeur des quantités de données transmises par type d'objet en présence) du BMS Manual

Bon test

BandWidth Calculator

Je vais jeter un oeil, merci beaucoup pour le taf

Pour info on a envie de bosser en interne pour rendre ca plus simple. Mais en attendant ca peut aider

Pour ta question précédente, concernant max(U,N), je confirme que c'est max. En fait, coté client, faut pas trop compter sur le réglage BW pour limiter ce que tu vas envoyer, il vaut mieux faire le calcul pour voir si l'upload qu'on a peut tenir le coup en P2P. Par contre, si tu renseignes un valeur de BW trop faible par rapport a ce que le serveur t'envoie, tu risques d'avoir des soucis. En particulier, il y avait un bug bien identifié, reproductible dans le cas ou un joueur seul renseignait une valeur de BW trop faible dans une situation chargée, qui menait a des vols "fantomes".On a réglé ce truc précis dans l'U1 (si vous allez sur le changelog de l'U1, recherchez g_bSkipAggregationBWCheck, c'était ça ). Mais en testant, on a aussi vu des trucs plus chelou genre des locks radars qui passaient pas, des DOFs mal updatés, etc. Donc faut quand même faire attention a pas mettre de BW trop faible par rapport a la situation. Mis a part ce fix la, la gestion BW a pas été touchée significativement - c'était un peu trop "touchy" pour une update, ca demande des tests aboutis.

Ma compréhension et mon approche ont évolué au fur et à mesure de la relecture des posts et des docs.
De ce que je comprends, sur une connexion un peu faible il de toute façon un UpLoad supérieur au trafic basique du seul avion du client (40 kbits d'après la doc BMS, 60-100 kbits dans ce qui tu as écris plus haut) et un Download supérieur à ce qui est prévisible de la TE/Campagne (on parle souvent de 2048 kbits)
Un fois ces conditions de base respectée, pour le paramétrage, ce serait CS + une BW non limitante (ex 2048).
Le CS garanti un Upload limité au strict minimum pour le client, tandis que le BW, à une valeur "raisonnable", ne limite pas le serveur.

Bien évidement et comme déjà mentionné plus il y a de clients avec une "petite" qui force en CS, plus il faut un serveur avec une "grosse" ...