Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Connection Authentification

Perospero

Bonsoir,

Apres avoir désactiver la sécurité qui vérifie l'adresse IP dans la config de Dofus, je ne comprends pas pourquoi lorsque j'ouvre un client dofus coté application le serveur d'authentification ne le reconnait pas ou bien a quel moment doit-il le reconnaitre ? Doit-il le reconnaître une fois entrer des identifiants sur le client save dans une BDD et lu depuis l'application ?

Voici les codes :

public abstract class ServerBase
    {
        protected Socket _server;
        protected Socket _client;
        public int Port { get; protected set; }
        public int Backlog { get; protected set; }
        public string IP { get; protected set; }
        public IPEndPoint ServerIPEndPoint { get; private set; }

        public ServerBase()
        {
            this._server = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
            this.Port = 443;
            this.Backlog = 100;
            this.IP = "127.0.0.1";
            this.ServerIPEndPoint = new IPEndPoint(IPAddress.Parse(IP), Port);
        }

        public void Initialize()
        {
            Bind();
            Listen();
            Accept();
        }
        private void Bind() => this._server.Bind(ServerIPEndPoint);
        private void Listen()
        {
            this._server.Listen(Backlog);
            Console.WriteLine($"On commence a écouter les clients sur le chemin : <{Port}:{IP}>");
        }
        protected void Accept() => this._server.BeginAccept(AcceptedCallback, null);
        protected abstract void AcceptedCallback(IAsyncResult ar);

    }

public class AuthServer : ServerBase
    
public class AuthServer : ServerBase
    {
        private AuthClient m_authClient;
        
        public AuthServer() : base() { }

        protected override void AcceptedCallback(IAsyncResult ar)
        {
            base._client = base._server.EndAccept(ar);
            this.m_authClient = new AuthClient(_client);
            Console.WriteLine("New client Connected !");
          /* SEND ProtocolRequired
           * SEND HelloConnectMessage
           * Initialize authClient
           */
            base.Accept();
            
        }
    }

Config :

    <!--======================================================================-->
    <!--                  Constantes pour l'accès au serveur                  -->
    <!--======================================================================-->
    
    
    <entry key="connection.useSniffer" type="Boolean" >false</entry>
    <entry key="connection.snifferHost">127.0.0.1</entry>
    <entry key="connection.snifferPort" type="int">18001</entry>
     <entry key="connection.host">127.0.0.1</entry>
     <entry key="connection.host.signature">AARBS1NGAAEAAACACZ9+mr1yAiQ8Iug2hODrUxKfQeviR0QJB/fzthrCQRA3/rSEDPkqL3ojfJsLu/07VkebfaCegbYtR5tQlg6voAMgDMX9FlP6KtQWnLXVUKkOye1pt01gb3uLUBrqm9o/3Lrgo38xuHs67jvAy1Yyo1bwk6JycE0H9yWnjg+WBmI=</entry>
    <entry key="connection.port">443</entry>
    <entry key="spin.chat.host">zaap-chat.ankama.com</entry>
    <entry key="spin.chat.port">6336</entry>

Finalement pour résumer dans le cas ou je n'ai pas été clair , ma question c'est quand est-ce que le client dofus est-il accepté par la socket AuthServer ?

Perospero

Headspace
Le client va essayer d'établir une connexion avec le serveur à l'adresse spécifiée dans la config, lorsque tu cliques sur le bouton jouer, juste après avoir entrer tes identifiants de connexion.

Je dois donc mettre en place la partie BDD pour espérer avoir sur ma console "Un nouveau client vient de se connecter" ^^, merci et du me conseille plutot dapper ou EF pour l'ORM ? Je suis sous NET.Core 2.1 au passage

Nameless

Non, il t'a dit que lorsque tu clic sur le bouton jouer, le client va établir une connexion vers l'adresse et le port spécifié dans le fichier config.xml à la racine de l'éxecutable du jeu, rien a voir avec une base donnée. Pour ta dernière question, je dirai entity framework pour ma part, mais ça dépend de toi il faut faire au mieux et le plus possible avec les choses que l'on comprends.

En parlant de chose que l'on comprends, ne t'aventure pas dans le multi-thread si tu ne comprends pas ça, je me permet de te dire ça au vu de la façon dont tu as utiliser IAsyncResult. Au passage : la TPL est sortit en 2009, plus personne utilise IAsyncResult depuis bien longtemps...

Si tu souhaites te renseigner sur la bonne façon d'implémenter une logique network en C# je te conseil ce repo https://github.com/mgravell/simplsockets, plus particulièrement le folder SimplPipelines pour la façon la plus récente de le faire avec les nouvelles fonctionnalités introduite à partir de .NET core 2.0 (pour plus d'information : https://blog.marcgravell.com/2018/07/pipe-dreams-part-1.html) ainsi que le folder SimplSocket te propose la façon verbeuse de faire qu'on peut retrouver dans la plupart des projets en général.

Et sinon je t'assure qu'il y a des choses bien plus importantes à implémenter avant de s'attaquer à la partie network : binary, serialization entre autre, et une logique comme l'entity component system (afin d'avoir des behaviors facilement testable, maintenable et extensible) serait un gros plus dans une application orienté jeu video comme ça.

Enfin, pour une application côté serveur de façon plus général il y a des langages fait spécialement pour tel que Rust. Cf. https://doc.rust-lang.org/book/foreword.html, ECS de rust : https://slide-rs.github.io/specs/

Mais se lancer dans un projet de cet envergure pour apprendre la programmation c'est du suicide, il faut un certain bagage pour pouvoir se débrouiller.

Perospero

Nameless
Non, il t'a dit que lorsque tu clic sur le bouton jouer, le client va établir une connexion vers l'adresse et le port spécifié dans le fichier config.xml à la racine de l'éxecutable du jeu, rien a voir avec une base donnée. Pour ta dernière question, je dirai entity framework pour ma part, mais ça dépend de toi il faut faire au mieux et le plus possible avec les choses que l'on comprends.
Et en parlant de chose que l'on comprends, ne t'aventure pas dans le multi-thread si tu ne comprends pas ça, je me permet de te dire ça au vu de la façon dont tu as utiliser IAsyncResult. Au passage : la TPL est sortit en 2009, plus personne utilise ça depuis bien longtemps...
Si tu souhaites te renseigner sur la bonne façon d'implémenter une logique network en C# je te conseil ce repo https://github.com/mgravell/simplsockets, plus particulièrement le folder SimplPipelines pour la façon la plus récente de le faire avec les nouvelles fonctionnalités introduite à partir de .NET core 2.0 (pour plus d'information : https://blog.marcgravell.com/2018/07/pipe-dreams-part-1.html) et sinon le folder SimplSocket te propose la façon verbeuse de faire qu'on peut retrouver dans la plupart des projets en général.
Et sinon je t'assure qu'il y a des choses bien plus importantes à implémenter avant de s'attaquer à la partie network : binary, serialization entre autre, et une logique comme l'entity component system (afin d'avoir des behaviors facilement testable, maintenable et extensible) serait un gros plus dans une application orienté jeu video comme ça.
Sinon, pour une application côté serveur de façon plus général il y a des langages fait spécialement pour tel que Rust. Cf. https://doc.rust-lang.org/book/foreword.html, ECS de rust : https://slide-rs.github.io/specs/

Merci pour ces links super merci ! :)

Mais du coup, même si j'appuie sur jouer avec rien ou des identifiants répertoriés nuls partent (d'où implémenté la partie BDD, je me suis mal exprimé effectivement...) pourquoi je n'ai pas sur ma console ("New client Connected !"); ? J'ai pourtant bien redirigé les ports Etc ... A moins que sur mon code j'ai fauté ? Après sinon le projet en lui-même j'ai déjà implémenté la partie IO Reader/Writer, gestion des messages enfin la Class de base pour les messages, et un truc en plus sur le singleton pattern. c'est vrai que je galère mais je m'accroche après mon but ce n'est pas d'avoir un truc performent mais qui tienne la route pour apprendre. Je pars du principe qu'on vise les milliards pour avoir le million (non je déconne :'()

Ps : je me calque sur l'architecture de Stump plus ou moins

Nameless

Tout d'abord il faut replacer les choses dans leur contexte et appeller les choses par leur vrai nom, en programmation des IO (Input/Output) ça correspond par exemple au parsing des frame, et des reader writer c'est de la logique binary. Ensuite, la gestion de la serialization via une classe abstraite est une hérésie pour les concepts de la programmation orienté objet (le paradigme qui régis le langage que tu utilise, entre autre). L'un des principe qu'il faut avoir en tête est le principe de responsabilité unique (SRP), ici les messages sont censés se définir par une classe ne servant qu'a contenir des données (POCO), la responsabilité de la serialization devant être délégué a une autre classe pour faire les choses correctement. Et tu peux éventuellement approfondir en générant ces méthodes dynamiquement au runtime via les arborescences d'expression en .NET par exemple.

Pour ce qui est du pattern singleton, c'est un pattern périlleux qui rend un programme difficilement testable, et les tests unitaires sont la base d'une architecture solide (je t'invite à te documenter à ce sujet), il ne faut pas s'en servir n'importe où et n'importe comment.Il faut remplacerça par un

injecteur de dépendance ou container IoC (un entity component system c'est aussi de l'inversion de contrôle quand on s'y penche un peu).

Comme je te le disais, il y a beaucoup à faire avant de se préoccuper du network, notamment se documenter sur les bonnes pratiques et ne pas se calquer sur des sources obsolètes et/ou mal faite.

Il faut placer la maintenabilité au centre en commençant par s'assurer d'avoir un maximum de code coverage au niveau des tests unitaire, et pour cela il faut déjà commencer par en faire, il est donc évident que se baser sur un projet qui n'en possède aucun n'est pas sérieux du tout.

Perospero

Nameless
Tout d'abord il faut replacer les choses dans leur contexte et appeller les choses par leur vrai nom, en programmation des IO (Input/Output) ça correspond par exemple au parsing des frame, et des reader writer c'est de la logique binary. Ensuite, la gestion de la serialization via une classe abstraite est une hérésie pour les concepts de la programmation orienté objet (le paradigme qui régis le langage que tu utilise, entre autre). L'un des principe qu'il faut avoir en tête est le principe de responsabilité unique (SRP), ici les messages sont censés se définir par une classe ne servant qu'a contenir des données (POCO), la responsabilité de la serialization devant être délégué a une autre classe pour faire les choses correctement. Et tu peux éventuellement approfondir en générant ces méthodes dynamiquement au runtime via les arborescences d'expression en .NET par exemple.
Pour ce qui est du pattern singleton, c'est un pattern périlleux qui rend un programme difficilement testable, et les tests unitaires sont la base d'une architecture solide (je t'invite à te documenter à ce sujet), il ne faut pas s'en servir n'importe où et n'importe comment.Il faut remplacerça par un
injecteur de dépendance ou container IoC (un entity component system c'est aussi de l'inversion de contrôle quand on s'y penche un peu).
Comme je te le disais, il y a beaucoup à faire avant de se préoccuper du network, notamment se documenter sur les bonnes pratiques et ne pas se calquer sur des sources obsolètes et/ou mal faite.
Il faut placer la maintenabilité au centre en commençant par s'assurer d'avoir un maximum de code coverage au niveau des tests unitaire, et pour cela il faut déjà commencer par en faire, et se baser sur un projet qui n'en a aucun ce n'est pas sérieux du tout.

Merci pour tes conseils, j'en prends note je reviendrai une fois plus expérimenté.

Nameless

Tu peux me contacter sur discord @NamelessK1NG#3577 si tu jamais tu as besoin de plus d'informations