Page 1 sur 1
bloqué en MP.
Publié : mar. sept. 13, 2011 11:10 pm
par olmes09
tentative connexion seulement à 2.
ports ouverts merci F4port test
firewall désactivé.
0.0.0.0 pour le hoteur
500 pour la bande passante.
ivc enable décoché.
ivc automatic etc également.
ip hosteur pour l'invité rentré et la BP
arrivé dans le chat, je vois son logbook (1h de vol
)
lancement de la TE.
on arrive. commit online.
on bloque là.
solution ?
Publié : mar. sept. 13, 2011 11:50 pm
par amraam
Vous avez attendu combien de temps? Pour la BW, toi tu étais a 500 (quelle est ta connexion?). Et le client? Car c'est upload - 25% pour tout le monde
.
Publié : mer. sept. 14, 2011 12:21 am
par mav-jp
Publié : mer. sept. 14, 2011 12:45 am
par olmes09
euh la langue de shakespeare est loin derrière moi mais c'est gentil.
pour amraam encore merci de tes conseils, ma BD en upload est de 793 kbit/s
nous avons essayé 400 ou 450. 2,3,4 minutes d'attente rien à faire.
Publié : mer. sept. 14, 2011 9:34 am
par HudLx
Salut Olmes,
Les ports 9987, 9988 et 9989 ouverts pour vous deux?
VMFA_Hud
Publié : mer. sept. 14, 2011 9:51 am
par olmes09
salut mon ami,
c'est si simple que ça ?:huh:
nous avons mis 2934-2935 en UDP seulement, + 2936-2937 pour les coms internes inutilisées pour l'instant.
il faut ouvrir ceux-là en UDP je suppose ?
bref j'ai beau avoir potasser la doc de bms ce détail si simple m'a échappé.
mais ce qui me turlupine c'est que la veille nous sommes arrivé dans un dog (face à du 29 en ace et en BVR bien sur
), sans les décors du monde 3d, mais ça on a su c'était la valeur bande passante pas configurée.
merci.
bref ce problème me rappelle le bon vieux temps de falcon, et ça fait plaisir.
Publié : mer. sept. 14, 2011 10:23 am
par STAG
olmes09 a écrit :euh la langue de shakespeare est loin derrière moi mais c'est gentil.
pour amraam encore merci de tes conseils, ma BD en upload est de 793 kbit/s
nous avons essayé 400 ou 450. 2,3,4 minutes d'attente rien à faire.
793 en upload, avec 25% de moins, ça te fait un bandwith à 590 en arrondissant à la baisse !
J'ai ouvert les ports de 2934 à 2937 en TCP et UDP.
Publié : mer. sept. 14, 2011 10:34 am
par HudLx
Oops Olmes,
J'avais mal lu : tu avais mis IVC décoché donc ça n'est pas une question de ports pour les comms internes.
My bad,
VMFA_Hud
Publié : mer. sept. 14, 2011 10:46 am
par Seekles
Sinon, pour info, depuis que le host héberge toutes les unités, il est le seul à nécessiter un routage de ports, hein...
Publié : mer. sept. 14, 2011 11:06 am
par olmes09
amraam a écrit :Vous avez attendu combien de temps? Pour la BW, toi tu étais a 500 (quelle est ta connexion?). Et le client? Car c'est upload - 25% pour tout le monde
.
stop.
quand tu dis -25% pour tout le monde c'est :
- 25% par rapport à la BP du hosteur ?
ou
- 25% par rapport à chacune des BP ?
Publié : mer. sept. 14, 2011 11:11 am
par mav-jp
putain les meeeecs merci de prendre quand meme 2 secondes pour lire les liens que je vous envoie meme si c'est en anglais (les traducteur de site web ca existe cf chrome), d'autant que ce sujet a déjà été traité ici meme !!!
http://www.checksix-forums.com/showthread.php?t=171383
Arrêtez la masturbation sur les BW ca sert à rien , les BW c'est UP-25% pour chacun des joueurs (evidemment pour la connexion de chacun) et basta.
Ton souci olmes vient du Raknet qui a un probleme pour gérer sa queue en attente au moment du transfert des messages clouds. On a déjà fixé le probleme pour un futur update
en attendant
mets
set g_bShareMpClouds 0
dans ton cfg.
Publié : mer. sept. 14, 2011 11:53 am
par olmes09
ça je savais que lui il réagirait comme ça.
pour les traducteurs, dsl, mais il ne sont jamais efficace à 100%. bon passons.
pour le reste peut-être et sans doute que le sujet a déjà été développé, mais certains petits détails tout bêtes, peuvent encore échapper à certains.
moi quand un truc que je ne comprends pas et que je ne trouve pas sur le forum au bout de 2 heures de recherche, je pose la question, quitte à passer pour le dernier couillu du service actif.
ça m'est égal et ça me simplifie la vie.
en attendant merci à tous pour vos réponses.
Publié : mer. sept. 14, 2011 1:31 pm
par Robin Hood
Seekles a écrit :Sinon, pour info, depuis que le host héberge toutes les unités, il est le seul à nécessiter un routage de ports, hein...
Tiens, intéressant, je n'avais pas vu ça ! N'ayant pas encore essayé le multi, ça m'intéresse, parce que pas mal de gens ont des soucis pour ouvrir leurs ports.
J'ai une question: il y a en endroit dans le (les) manuel(s) où sont écrit ce genre de choses (ports à ouvrir, etc...) ? Parce que j'ai cherché, mais sans trouvé (ou alors dans des vieux manuels dont on ne sait pas s'ils sont à jour à ce sujet).
Publié : mer. sept. 14, 2011 3:14 pm
par spiryth
Robin Hood a écrit :Parce que j'ai cherché, mais sans trouvé (ou alors dans des vieux manuels dont on ne sait pas s'ils sont à jour à ce sujet).
Habituellement, une recherche avec ton moteur de recherche préféré, en entrant "ouvrir" "port" en mots clés et avec le nom et le modèle de ton routeur/ta box/... (choisir la mention utile) devrait mener assez rapidement à trouver la procédure à suivre (à moins que tu n'es un matériel très particulier.... ça arrive
)
Publié : mer. sept. 14, 2011 3:46 pm
par Seekles
Robin Hood a écrit :Tiens, intéressant, je n'avais pas vu ça ! N'ayant pas encore essayé le multi, ça m'intéresse, parce que pas mal de gens ont des soucis pour ouvrir leurs ports.
J'ai une question: il y a en endroit dans le (les) manuel(s) où sont écrit ce genre de choses (ports à ouvrir, etc...) ? Parce que j'ai cherché, mais sans trouvé (ou alors dans des vieux manuels dont on ne sait pas s'ils sont à jour à ce sujet).
Ben si ça peut servir, autant détailler un peu alors.
La nécessité d'ouvrir les ports de manière bilatérale venait, si je ne m'abuse, du temps où les unités n'étaient pas hébergées toutes sur le même serveur mais réparties entre les clients. La communication se faisait alors, forcément, dans tous les sens, nécessitant un routage des ports chez tout le monde.
Depuis qu'on est passés en « server hosts all units », les connexions sont uniquement initiées par les clients vers le serveur, éliminant tout besoin de routage chez lesdits clients, comme pour n'importe quel programme qui se connecte sur un serveur externe. Vous avez déjà dû router un port pour accéder à un FTP (passif, pour les pinailleurs), à une partie de World of Warcraft ou à un serveur Web, vous ?
J'y pense, il serait
bon à présent de mettre à jour le post scotché de Shin à ce sujet !
Publié : mer. sept. 14, 2011 4:45 pm
par STAG
Certains avec je vole et qui n'avaient pas ouvert leurs ports ne pouvaient pas se connecter sur ma partie.
Ils ouvrent leurs ports et ils arrivent à se connecter !
Je reste donc sceptique sur la non nécessité d'ouvertures de ports pour les clients... ?
Publié : mer. sept. 14, 2011 6:12 pm
par Seekles
Réponse rapide : je n'ai pas accès à la page d'administration de mon routeur, je vole depuis des mois sans avoir routé quoi que ce soit, en ce moment je vole pratiquement tous les soirs, la 09 peut confirmer. Magie
Pour être tout à fait honnête, certains routeurs appliquent des règles de firewall aux connexions UDP sortantes.
Publié : mer. sept. 14, 2011 7:48 pm
par mav-jp
Seekles a écrit :Ben si ça peut servir, autant détailler un peu alors.
La nécessité d'ouvrir les ports de manière bilatérale venait, si je ne m'abuse, du temps où les unités n'étaient pas hébergées toutes sur le même serveur mais réparties entre les clients. La communication se faisait alors, forcément, dans tous les sens, nécessitant un routage des ports chez tout le monde.
Depuis qu'on est passés en « server hosts all units », les connexions sont uniquement initiées par les clients vers le serveur, éliminant tout besoin de routage chez lesdits clients, comme pour n'importe quel programme qui se connecte sur un serveur externe. Vous avez déjà dû router un port pour accéder à un FTP (passif, pour les pinailleurs), à une partie de World of Warcraft ou à un serveur Web, vous ?
J'y pense, il serait
bon à présent de mettre à jour le post scotché de Shin à ce sujet !
Ce que tu dis est completement FAUX.
Au contraire, le code MP utilise le P2P en particulier pour toutes les infos de positions.
Justement, si les bon ports en sont pas ouvert, le Raknet va utiliser un port alternatif mais dans ce cas romp la connexion P2P avec les autres clients, ce qui surcharge d'autant plus le serveur qui doit faire le relai.
Publié : mer. sept. 14, 2011 8:07 pm
par Seekles
Je sais bien. Je ne dis pas que c'est la solution recommandable (c'est ce qui explique qu'on a parfois des soucis pour se voir entre pilotes quand justement la charge serveur est trop grande), mais que la connexion marche quand même, sans routage de ports. Ce n'est donc pas « entièrement faux », comme tu le dis.
Si tu préfères, que le routage des ports n'est pas une condition nécessaire au fonctionnement de la connexion.
Dans mon cas, j'ai pas le choix.
Publié : mer. sept. 14, 2011 8:49 pm
par mav-jp
on sait que le raknet se démerde pour établir une connexion si les ports sont fermés mais:
1) celà surcharge le server
2) celà n'a JAMAIS été béta testé
Publié : jeu. sept. 15, 2011 8:37 am
par Regislazy
Un grand merci Seekles.
C'est grace à ton info sur les ports non nécessairement ouverts que j'ai fait une tentative alors que j'étais en déplacement dans un hotel...Me voyait pas demander au staff de m'ouvrir des ports!!!
Et c'est grâce à cela que j'ai pu faire mon premier vol "On line" sur BMS.
J'ai BIEN NOTE que ce n'était pas recommandable, mais c'est en tous cas bien pratique en cas de besoin....
Publié : jeu. sept. 15, 2011 8:40 am
par Seekles
Pfff, la dernière fois que je suis allé dans un hôtel, je suis allé sur la page d'accueil du routeur, j'ai vu que c'était un Netgear, admin/password par défaut, j'aurais pu foutre une merde magnifique
Content de voir que ça marche ailleurs
Après, faut se dire que pour un vol à 2 pilotes, ça ne pose aucun souci de surcharge, du coup. Dommage que ça n'ait pas été testé plus en détail.