Structure

[fioutubs]

Bonjour,

Je me permet de poser une question à laquelle je n'ai pas trouvé de réponse sur le forum.

Lors de la création d'un bot on peut avoir une librairie dédiée au fonctions tirées du client (pathfinding, encodage, ect), ce genres de fonctions prennent des valeurs en entrées et retournent une valeur qui sont pour la plus part du temps vérifiable aux travers de tests unitaires.

Cependant je ne parviens pas à trouver une structure qui me convienne pour gérer d'une part la connexion socket, et d'autre part le parseur de packet. Je pourrais utiliser une BDD pour faire le lien entre tout les modules de l'app, ce qui rendrait aussi plus simple les tests, mais j'ai peur que les performances soient affectés. A l'heure actuelle j'utilise des varriables globales, qui ont l'avantage d'être rapide en lecture/ecriture, mais au moment des tests unitaire ca deviens vite impossible de tester certaines parties du programme.

Au final si j'ai une fonction move(cell), elle devrait retourner quoi ? Le paquet a envoyer au serveur ? Une valeur booleenne ? Il y a plein de façons de faire mais je n'ai pas trouvé la bonne pour rendre le projet le plus clean possible

 

[slinker0]

You have to think of this as the server would. How would the server know that the user wants his character to move from cell 1 to cell 100? It has no receive that information somehow then it'll process that information and then send you a message back allowing your client to do the move or not.
The way I like to deal with Socket connection is making a class for it and inside of that class having Virtual functions that will be called whenever a receive / send a message. That way I can overwrite those virtual functions in the main body of the bot and handle the packets there with ease.
Sorry for your answer being in English.

 

[Kailun]

Salut à toi jeune entrepreneur,

Si tu veux rendre ton architecture la plus testable possible, il va falloir passer par les principes SOLID. (https://fr.wikipedia.org/wiki/SOLID_(informatique))

Ensuite, on va essayer de segmenter les choses logiques et développer en couche (layers). Sur Dofus, par exemple pour la partie networking on va pouvoir faire ce genre de layers :
- Socket --> Gestion bas niveaux (buffer, IO...)
- Framing --> Gestion plus haut niveau (frames) (une frame c'est juste par exemple le messageId et le payload complet du message)
- Message --> Gestion plus haut niveau, on parle ici des message Dofus

L'objectif est de développer tout via abstraction afin de pouvoir "mocker" (le concept ne doit pas t'être étranger si tu t'intéresses aux TU) chaque partie de la pipeline et tester en isolation chaque composant.

Enfin, tu vas développer ta logique métier juste avec la partie haut-niveau (uniquement via les messsages Dofus) avec un système de handler "basique" qui va trigger des API encore plus haut (API Inventory, Chat..) qui vont s'occuper donc de traduire une action "métier" (parler, lancer un combat) en un ensemble de messages Dofus selon le contexte (état de santé, map, etc.)
L'objectif étant donc de pouvoir tester les API plus haut niveaux sans même-lancer Dofus et ainsi augmenter sa productivité (enfin un test en condition réelle ne fait pas de mal de temps en temps ) et s'assurer d'un comportement fiable.
De plus, tes composants étant isolés, un changement de protocole (ou du jeu) ne devrait pas ou peu impacter ton code métier, celui qui contient toute la logique et où tu vas passer 90% de ton temps.

Bonne chance !

 

[fioutubs]

Merci pour vos réponses, je vais approfondir mes recherches vers ces concepts

 

[Scheduler]

Salut à toi jeune entrepreneur,

Si tu veux rendre ton architecture la plus testable possible, il va falloir passer par les principes SOLID. (https://fr.wikipedia.org/wiki/SOLID_(informatique))

Ensuite, on va essayer de segmenter les choses logiques et développer en couche (layers). Sur Dofus, par exemple pour la partie networking on va pouvoir faire ce genre de layers :
- Socket --> Gestion bas niveaux (buffer, IO...)
- Framing --> Gestion plus haut niveau (frames) (une frame c'est juste par exemple le messageId et le payload complet du message)
- Message --> Gestion plus haut niveau, on parle ici des message Dofus

L'objectif est de développer tout via abstraction afin de pouvoir "mocker" (le concept ne doit pas t'être étranger si tu t'intéresses aux TU) chaque partie de la pipeline et tester en isolation chaque composant.

Enfin, tu vas développer ta logique métier juste avec la partie haut-niveau (uniquement via les messsages Dofus) avec un système de handler "basique" qui va trigger des API encore plus haut (API Inventory, Chat..) qui vont s'occuper donc de traduire une action "métier" (parler, lancer un combat) en un ensemble de messages Dofus selon le contexte (état de santé, map, etc.)
L'objectif étant donc de pouvoir tester les API plus haut niveaux sans même-lancer Dofus et ainsi augmenter sa productivité (enfin un test en condition réelle ne fait pas de mal de temps en temps ) et s'assurer d'un comportement fiable.
De plus, tes composants étant isolés, un changement de protocole (ou du jeu) ne devrait pas ou peu impacter ton code métier, celui qui contient toute la logique et où tu vas passer 90% de ton temps.

Bonne chance !

Salut par simple curiosité, tu mettrais plutôt où la partie sur la logique de serialization . À moins que ce soit une 4e couche au même titre des 3 autres mentionné.

 

[Kailun]

Salut par simple curiosité, tu mettrais plutôt où la partie sur la logique de serialization . À moins que ce soit une 4e couche au même titre des 3 autres mentionné.

La logique de serialization peut intervenir lors de la conversion bytes->frame et frame->messages (dans les 2 sens, évidemment)
La serialization n'est pas une couche, c'est un outil pour faire transiter d'un format à l'autre

 

[Scheduler]

La logique de serialization peut intervenir lors de la conversion bytes->frame et frame->messages (dans les 2 sens, évidemment)
La serialization n'est pas une couche, c'est un outil pour faire transiter d'un format à l'autre

Ok donc elle serait plus dans la couche Framing que Message ?

 

[Kailun]

Ok donc elle serait plus dans la couche Framing que Message ?

Elle intervient dans les 2 cas, mais plus dans les messages vu que tu as plus de messages que de frames. Des frames, t'en as pas 50 sur Dofus : t'en as 2, une client (avec l'instanceId) et une serveur

 

[Scheduler]

Elle intervient dans les 2 cas, mais plus dans les messages vu que tu as plus de messages que de frames. Des frames, t'en as pas 50 sur Dofus : t'en as 2, une client (avec l'instanceId) et une serveur

Ok ok , je voyais plus un truc du style les Messages sont que des "POCO"/"Models" et à coté une couche Serialization dissocié des Messages. Mais finalement tu as raison, c'est plus simple et maintenable comme ca .
Merci

 

[Kailun]

Ok ok , je voyais plus un truc du style les Messages sont que des "POCO"/"Models" et à coté une couche Serialization dissocié des Messages. Mais finalement tu as raison, c'est plus simple et maintenable comme ca .
Merci

Non non tu as bien raison, les messages ne sont rien de plus que des POCO/modèles de domaines, sans logique métier - juste des placeholder de données.
La partie serialization va convertir ta classe en un autre format, et c'est tout. elle va le faire pour convertir ton buffer en frame, puis ta frame en message "fortement" typé