Check-Six Forums

Hello,

j'aimerais connaitre les raisons qui peuvent entrainer une perte de connexion lors d'un vol en multi...

pour rappel d'un cas rencontré: vol avec Juls qui hoste (IVC inclus), tous deux nous avons un fort debit ( 80Mo en D et 5Mo en U pour ma part)

le problème apparait après plus de 30min de vol , puis sans trop savoir pourquoi, on a le message qu' untel a quitté falcon... IA reprend la main

je constate également , que le hoster (Juls en l'occurence ici) n'apparait plus dans le menu des Comms empêchant la possibilité de revenir dans la partie


bref quels sont les tests à effectuer et comment savoir celui qui est l'origine du pb?


Merci d'avance pour votre aide

AkulAx

L'un de vous aurait un NAS par hasard ?

pour ma part, non...

Un peu similaire à ce cas
rejeté par le hosteur
Il y a à l'intérieur de ce post, les différentes recherches effectuées et à faire
Peut être y trouveras tu ton bonheur, mais les problèmes réseau, aie aie aie !!!....

akulax a écrit :Hello,

j'aimerais connaitre les raisons qui peuvent entrainer une perte de connexion lors d'un vol en multi...

pour rappel d'un cas rencontré: vol avec Juls qui hoste (IVC inclus), tous deux nous avons un fort debit ( 80Mo en D et 5Mo en U pour ma part)

le problème apparait après plus de 30min de vol , puis sans trop savoir pourquoi, on a le message qu' untel a quitté falcon... IA reprend la main

je constate également , que le hoster (Juls en l'occurence ici) n'apparait plus dans le menu des Comms empêchant la possibilité de revenir dans la partie


bref quels sont les tests à effectuer et comment savoir celui qui est l'origine du pb?


Merci d'avance pour votre aide

AkulAx

Qu'est ce que met comme bandwidth le hosteur et le client ?
Êtes vous certain d'avoir très exactement la même version ? (Un qui aurait un Théâtre ou autre truc que l'autre n'aurait pas).
Le problème viendra de celui qui n'a pas la même version que le Host

Il faut savoir que pour pouvoir revenir dans une partie, il faut en être partie très proprement, soit en ayant fait un Sign Off.
Dans le cas d'une éjection du jeu il y a de forte de chance de ne pas pouvoir revenir.

A savoir qu'avec 5 Mbps le host doit mettre 3750 en Bandwidth (5000-25%=3750) Toi en temps que client tu peux te mettre à 1024 à priori

de mémoire je pense que le bandwidth était de 4000 pour le Host et de 3000 pour le Client ...

est-il préférable pour le client d'avoir une bandwidth bien inférieure à son upload à 75%...? ici tu préconises 1024...?!

quant à la version, il semble que nous avons la même

akulax a écrit :de mémoire je pense que le bandwidth était de 4000 pour le Host et de 3000 pour le Client ...

bein il faut savoir. Si les 4000 c'était bien son upload -25%, ok sinon bein ça peut être ça. Il faut voir aussi les pings entre vous, et également si vos lignes ne subissent pas de grosses variations de débit.
Cela peut créer des temps de désynchro, qui accumulé peuvent avoir le résultat d'une éjection de l'un ou l'autre.

akulax a écrit :est-il préférable pour le client d'avoir une bandwidth bien inférieure à son upload à 75%...? ici tu préconises 1024...?!

La Bandwidth est divisé par le nombre de clients
2 clients sur 4000 devraient théoriquement pouvoir mettre 2000 chacun. 1024 donne la même chose. Comprend "est largement suffisant."

akulax a écrit :quant à la version, il semble que nous avons la même

Semble???? Ou est ???? Parce avec le 1er rien est sur

Je ne me rappelle pas avoir jamais mis plus de 512 en bandwidth, alors même que ma connexion me le permet. Et même pour hoster 8 Griffons, ça suffit.

En cas de différence de version ou de théâtre, vous ne pourriez même pas vous connecter l'un à l'autre (de mémoire, vous arrivez dans le lobby, mais impossible de voir la partie créée par l'autre).

Seekles a écrit :Je ne me rappelle pas avoir jamais mis plus de 512 en bandwidth, alors même que ma connexion me le permet. Et même pour hoster 8 Griffons, ça suffit.

En cas de différence de version ou de théâtre, vous ne pourriez même pas vous connecter l'un à l'autre (de mémoire, vous arrivez dans le lobby, mais impossible de voir la partie créée par l'autre).

Le 1024 c'est Bad boy qui nous a dit que c'était bien pour notre serveur par exemple. Donc c'est que cela peut se faire. Notre serveur est réglé sur une banwidth à 270000, et tous les pilotes se connectent avec 1024. Maintenant vu la bandwidth d'akulax 1024 passe très bien aussi

Pour le théâtre je ne parle pas de savoir s'ils étaient sur le même théâtre je dis que si l'un d'eux à installé quelque chose sur sa version original que l'autre n'a pas comme un théâtre cela peut merder.
Nous c'était le cas

Peut-être je comprends pas tous les post ci-dessus mais la vitesse d'upload à mettre dans la fenêtre de connexion ne dépend pas du serveur. Mais uniquement de la vitesse d'upload disponible chez le client.

Je cite le manuel BMS p11.

Connection Bandwidth
For the time being you must enter a value in this box (future versions may automate this). Unfortunately there isn’t really a hard and fast rule for what to put here. The value is used to help manage network traffic on your connection to avoid flooding while keeping the throughput as high as practical. As a general rule of thumb, enter the upload speed of your connection minus 25% in kilobits. For example, if you upload capacity is 1000 kilobits per second then you would enter 750 in this box.

Je résume : mettre dans la case "Connection Bandwidth" la vitesse d'upload de votre connection minorée de 25% (en kilobits par secondes).

Je sais pas si c'est la cause de ces déconnections. Mais dans le doute vaut mieux respecter ce qui est préconisé par les mecs qui ont pondu le code .
Je suis pas un grand connaisseur de réseau, et encore moins du code de BMS, mais je pense que dire au serveur "vas s'y, balance la sauce, mon tuyaux est énorme !" quand il s'agit d'un vermicelle c'est le meilleur moyen pour que le serveur envoie des données qui seront jamais réceptionnées par client.

Tout ce que je peux te dire Spiryth, c'est que c'est comme cela que nous procédons, tous nos vols à plus de 25 se sont très bien passés. Ce soir nous serons 32 et cela ne devrait rien changer
Et cela fonctionne tout aussi bien en simultané sur 4 ou 5 VM

C'est bien noté BlackAngel : l'expérience montre que ça fonctionne aussi comme ça (et tant mieux ).
(Et vu ton exemple, j'imagine que plus tu es nombreux à être connecté et moins il y a de risque que le serveur noie un des client, ou alors il faudrait qu'il ait lui même un upload très conséquent pour arriver à saturation d'un client).

Mais si ça fonctionne mal (le cas présenté plus haut), mon avis est qu'il est préférable d'utiliser la solution définie par le soft, plutôt qu'une solution fonctionnelle mais expérimentale. Et ceci afin de supprimer le plus de variables possible et identifier la bonne cause du problème.

bon le vol de hier soir a été concluant : pas de perte de connexion

- voici les opérations faites :
-> test de connexion Juls ( U 22 D 2.3) Akulax ( U 80 D 5)
->retour sur une version sans les mods Runway& clouds
->Juls a reduit sa bandwidth à 1700kps et moi à 2500kps
-> compte tenu de mon debit, nous avons inversé : j'ai pris le host