BusyIzi

Ah ce n'est pas normal tu penses ? J'me suis dit que load 20 maps avec tous les mobs ça mangeait beaucoup

Bon problème résolu, maintenant ça me semble tellement évident... J'ai donc essayé en modifiant le CONFIG du core4 an mettant seulement les 10 premières map et en les ajoutant une a une jusqu'à ce que ça plante. Sauf que c'était complètement aléatoire, parfois ça plantait pour la map 72, parfois 70, je ne comprenais rien ! J'ai ouvert un terminal avec la commande Top pour monitorer un peu la machine, voir les consommations de ram. Effectivement l'OS faisait sauter le core4 au lancement car il bouffait toute la ram ! A lui tout seul c'est quasiment 500Mo de disparus, sur une machine de 1Go de Ram forcément ça n'a pas plu à l'OS qui s'empressait de virer ce process trop lourd. (C'est aussi pour ça qu'il n'y a rien dans les logs, le process se faisait simplement kill) Seule solution : Monter la ram de la machine. Je l'ai lu 15 fois en faisant mes recherches mais je ne comprenais pas du tout le rapport avec mes déconnexions sur certaines maps donc j'ai mis ça de côté. Leçon du jour : Si on se fait déconnecter à la sélection du personnage c'est soit que l'IP est mal configurée, soit c'est un problème de ports, soit c'est que la machine n'est pas bien dimensionnée et vire quelques cores au passage ! Désolé d'avoir posté pour ça du coup, la question avait déjà été posée et la réponse déjà apportée (bon par contre c'était pas du tout expliqué ) Merci Galet

Voilà les maps du core4 MAP_ALLOW: 61 62 63 65 66 67 68 69 70 71 72 73 74 75 76 77

Merci pour cette piste Galet, ça aurait pu carrément être ça je n'y avais pas pensé ! Mais après vérification tous les cores sont pourvus d'un lien symbolique vers le game, le game n'est pas en dur. J'ai regardé un peu du côté des ports avec la commande netstat. En fait, tous les cores tournent sur les ports configurés sauf le core4 (qui contient toutes les maps qui sautent). Donc impossible de se connecter sur une socket qui n'est pas ouverte alors ça fait tout sauter ! Le truc bizarre c'est qu'il n'y a rien dans le syserr Là j'ai essayé en chargeant une seule map dans le core4 et ça marche ! Ça veut dire qu'il y a une des 20 map chargées initialement qui fait tout sauter, j'ai juste à les essayer une à une et voir les syslog au passage pour voir ce qui provoque tout ce bordel dans un silence le plus total. Je posterai les résultats de mon enquête Merci de ton aide en tout cas

Non et je pense avoir compris pourquoi ! Je comprends mieux le chargement des maps, donc chaque core est responsable de charger plusieurs maps grâce à une liste d'index de map données dans la clé MAP_ALLOW. Dans mon core1, on charge les map1 et map2 des trois royaumes, ça passe nikel. La map orc par exemple est chargée dans le core4 (id 64), si je la retire du fichier CONFIG du core4 pour l'ajouter dans le core1 je peux me connecter dessus ! Le problème doit venir des ports encore une fois, le core4 démarre sur le port 13003 tandis que le core1 sur le 13000 dans mon cas. C'est plutôt de ce côté là qu'il faut que je creuse je pense. PS : Dommage que le client ne log pas les erreurs de connexion aux sockets, ça aiderait beaucoup à débugger Toutes les idées sont bonnes, envoyez ! :happy:

Me revoilà pour de nouveaux problèmes de déconnexion ! Après avoir résolu les problèmes de déco à la sélection des personnages j'ai un problème étrange. En effet cela arrive selon où se trouve le personnage. Exemple : Un perso qui est map 1, map 2 (bleu/jaune/rouge) aucun problème, je me connecte sans soucis. Dès que je me téléporte (orcs, cave2, tour) je me fait déconnecter. Peu importe la manière dont je me TP le perso se fait déconnecter (téléporteur, item, TP GM) Une fois que le perso est téléporté il m'est impossible de me connecter sur ce perso, sauf si je le remet map 1 manuellement dans la base de données. Des idées ? Bien évidemment rien dans les logs... :@ Version des files : 2014 Domaine (Base de données, Core, etc.) : Téléportation Ingame Votre niveau (débutant, intermédiaire, avancé) : intermédiaire Description du problème : Déconnexion à la téléportation sur une map commune (orcs, cave, etc) Comment reproduire le problème : Se téléporter Ingame Recherches et tests effectué : Seulement certaines map sont soumises au problème ce qui complexifie le diagnostic. A noter que les files sont un copié collé d'une version de mon serveur local qui marchait très bien avec ces maps... J'ai regardé s'il n'y avait pas de problèmes de droit j'ai tout passé en 777 pour tester et rien n'y fait Résultat des recherches et tests : J'ai vu que d'autres personnes ont rencontré le même problème mais ils n'ont pas mis la solution dans leur topic... Message d'erreur, capture d'écran : Nada !

Merci ! Je compte faire plusieurs tutos oui après tous les problèmes que j'ai eu et ce n'est pas fini !

EUREKA ! C'était bien cela... Foutu maxi firewall d'Amazon. Bon ça m'étonnerait que ça arrive à quelqu'un d'autre mais on se sait jamais alors voici ma solution : Le problème c'est que l'instance d'Amazon ne sait pas créer de socket tcp sur l'ip publique car elle n'y a pas accès directement. En effet quand on tape ifconfig on voit que les interfaces réseau configurées possèdent toutes des IP privées. Impossible d'y accéder de l'extérieur, c'est une sécurité. Sauf que si on met une IP privée dans le BIND_IP des Config des cores, le client ne pourra jamais s'y connecter (déco à la sélection des personnages). Pour contourner cela, il faut que le serveur Metin2 créé des sockets sur l'IP privée mais transmette l'IP publique au client. Amazon se charge de la correspondance IP privée/publique, donc une socket ouverte sur une IP privée sera transmise sur l'IP publique et vice-versa. Pour se faire il faut modifier les fichiers config.cpp et main.cpp des sources Dans le fichier de config.cpp, on va récupérer les valeurs des IP publique/privée TOKEN("bind_private_ip") { strlcpy(g_szInternalIP, value_string, sizeof(g_szInternalIP)); fprintf(stderr, "Reading private IP : %s\n", value_string); strlcpy(g_szIPInterne, value_string, sizeof(g_szIPInterne)); } TOKEN("bind_public_ip") { strlcpy(g_szPublicIP, value_string, sizeof(g_szPublicIP)); fprintf(stderr, "Reading public IP : %s\n", value_string); strlcpy(g_szIPExterne, value_string, sizeof(g_szIPExterne)); } Il faut bien sur configurer vos IP publiques/privées dans les fichier CONFIG des cores de chaque channel BIND_PRIVATE_IP: XXX.XXX.XXX.XXX BIND_PUBLIC_IP: XXX.XXX.XXX.XXX Ici pour arrivez à récupérer les données des fichiers CONFIG. Le main.cpp va pouvoir y avoir accès quand il appelera le config_init. Dans le main.cpp il faut créer les socket tcp sur les IP privées (si elles existent) Cherchez la ligne if ((tcp_socket = socket_tcp_bind(g_szPublicIP, mother_port)) == INVALID_SOCKET) Et remplacez l'intégralité de la condition comme suit if ((tcp_socket = socket_tcp_bind(*g_szInternalIP ? g_szInternalIP : g_szPublicIP, mother_port)) == INVALID_SOCKET) { fprintf(stderr, "Invalid IP %s", *g_szInternalIP ? g_szInternalIP : g_szPublicIP, mother_port); perror("socket_tcp_bind: tcp_socket"); return 0; } Même chose avec la ligne if ((p2p_socket = socket_tcp_bind(g_szPublicIP, p2p_port)) == INVALID_SOCKET) Remplacez comme suit if ((p2p_socket = socket_tcp_bind(*g_szInternalIP ? g_szInternalIP : g_szPublicIP, p2p_port)) == INVALID_SOCKET) { perror("socket_tcp_bind: p2p_socket"); return 0; } Compilez, remplacez le game et on est bon !

Non c'est un game mainline compilé sur mon serveur avec quelques ajouts des tutos de ce forum, idem pour les files 2014. Le client est un compilé oui je n'ai pas les sources de celui-ci en revanche. Mais je pense savoir d'où vient tout ce bazar en fait... Mon serveur (hardware) est dans le cloud, chez Amazon. Amazon utilise un VPC (Virtual Private Cloud), un réseau privé virtuel avec ses propres IP privées. Je dois mettre l'IP privée dans le BIND_IP pour que cela marche. Côté client dans le sysinfoserver j'ai l'IP publique. C'est pour cela que la connexion au compte fonctionne. Sauf que après c'est le client qui récupère l'IP privée configurée dans le BIND_IP (pour se connecter aux sockets ouvertes par le game côté serveur) lors de la phase du choix des personnages (j'ai bon ?) et forcément c'est une IP privée donc impossible d'y accéder depuis le client, alors la connexion est fermée et retour à la page du choix de serveur. Du coup je regarde pour modifier le config.cpp pour prendre en compte ces deux IP différentes plutôt qu'une seule IP publique. Je vous tiens au courant :angel:

Bonjour, J'ai un peu traîné dans la création de mon serveur dédié donc j'ouvre un nouveau sujet, l'ancien ayant été fermé. Après avoir bieeeeen galéré pour installer le serveur Metin2 sur le dédié, j'ai enfin réussi à me connecter au serveur à partir de mon client. Simplement maintenant je me fait déco à la sélection des personnages. J'ai bien sûr lu les 5 pages de résultats de la recherche avec le mot clé "Déconnexion", tous les sujets abordent des solutions différentes, on parle aussi de laucher by danger et dans un autre sujet j'ai lu qu'il n'était plus compatible avec les files 2012. Enfin bref aucune info tangible. J'ai suivi ce tuto (/topic/18028-thread/) pour configurer les attributs BIND_IP des fichiers Config et modifié mon config.cpp Aucune erreur lors du lancement du serveur, aucune trace dans les syserr (tous vierges), rien de croustillant dans les sysinfo, rien dans les logs du client.... Frustrant ! Version des files : 2014 Domaine (Base de données, Core, etc.) :Client Votre niveau (débutant, intermédiaire, avancé) :intermédiaire Description du problème : Déconnexion sélection des personnages Comment reproduire le problème : A chaque fois que l'on tente de sélectionner un personnage Recherches et tests effectué : Lecture de tous les sujets à ce propos, j'ai refais le tuto de Calypso 3 fois pour être sur de ne pas m'être planté quelque part Résultat des recherches et tests : Que nenni ! C'est très frustrant de n'avoir aucune log, il n'y a pas de mode verbose pour faire parler un peu le serveur ? Merci de m'avoir lu !

Verdict, Hamachi n'a rien résolu :huh: Je ne comprends vraiment pas ce qui justifie ces déconnexions. La VM est bien dimensionnée, je n'ai pas de problème particulier concernant mon réseau local. Vraiment je ne vois pas

D'accord j'essayerai demain avec Hamachi. Je laisse le topic ouvert, je posterai les résultats. Merci une fois de plus

Je suis en IP locale, c'est à dire que pour le moment j'ai configuré le client avec l'ip locale de mon réseau (192.168.0.X), donc ni hamachi ni no_ip. De ce fait seulement les pc du même réseau local (mon réseau wifi) peuvent s'y connecter. Et cela fonctionne très bien ! C'est à dire que depuis un autre pc je peux jouer tranquillement jusqu'à me faire déconnecter brutalement au bout de 5, 10 minutes ou même une heure c'est très aléatoire. En revanche si le jeu est lancé depuis la machine sur laquelle se trouve la VM je ne me fais jamais déconnecter, c'est uniquement d'un autre ordi du même réseau. Effectivement je comprends mieux ton tuto dans le cas où la deconnexion arrive dès la sélection du personnage

Merci Calypso je vais modifier les sources et voir si ça change quelque chose. Mais si j'ai bien compris, si c'est une histoire d'adresse IP alors l'autre pc ne pourrait pas se connecter du tout non ?

Visiblement non... :huh: Quelle est la modification à apporter ? (j'ai bien les sources)