Bonjour à tous,
Je travaille à développer un package python qui me permettra de parser automatiquement les sources du jeu relatives au protocole de communication afin d'avoir des données exploitables pour d'autres projets (analyse des échanges client-serveur, et plus si affinités
)
Je me suis basé sur l'approche du fameux Kouin-Kouin et son labot dans mon développement reconstruire le protocole. J'ai bien compris que certains aspects du projet sont maintenant outdated mais l'approche globale semble toujours valable.
En me promenant dans les fichiers sources pour fix les regexes permettant d'extraire les détails relatifs aux variables des différentes classes du protocole, je me suis rendu compte qu'il y avait deux approches concurrentes dans les sources pour la deserialization desdites variables par le client. Je pense plus particulièrement aux variables représentant des instances d'autres classes du jeu.
1) L'instanciation de la classe, directement, puis la lecture des données dans le stream reçu pour set la classe correctement.
2) La lecture d'un ID (short) dans les données reçues, puis l'appel à une méthode de la classe ProtocolTypeManager pour effectuer un lookup dans sa table de correspondance et obtenir la classe à instancier dans la variable, et enfi la lecture dans les données reçues pour set la classe correctement.
Si c'est pas clair je pourrai poster des bouts de code du jeu, mais m'est avis que vous voyez ce dont je veux parler.
Je me demandais donc : qu'est ce qui justifie l'existence de ces deux méthodes de deserialization ? Quel est l'intérêt de l'utilisation de ProtocolTypeManager ?
Bonne fin de week-end à vous
Je travaille à développer un package python qui me permettra de parser automatiquement les sources du jeu relatives au protocole de communication afin d'avoir des données exploitables pour d'autres projets (analyse des échanges client-serveur, et plus si affinités
)Je me suis basé sur l'approche du fameux Kouin-Kouin et son labot dans mon développement reconstruire le protocole. J'ai bien compris que certains aspects du projet sont maintenant outdated mais l'approche globale semble toujours valable.
En me promenant dans les fichiers sources pour fix les regexes permettant d'extraire les détails relatifs aux variables des différentes classes du protocole, je me suis rendu compte qu'il y avait deux approches concurrentes dans les sources pour la deserialization desdites variables par le client. Je pense plus particulièrement aux variables représentant des instances d'autres classes du jeu.
1) L'instanciation de la classe, directement, puis la lecture des données dans le stream reçu pour set la classe correctement.
2) La lecture d'un ID (short) dans les données reçues, puis l'appel à une méthode de la classe ProtocolTypeManager pour effectuer un lookup dans sa table de correspondance et obtenir la classe à instancier dans la variable, et enfi la lecture dans les données reçues pour set la classe correctement.
Si c'est pas clair je pourrai poster des bouts de code du jeu, mais m'est avis que vous voyez ce dont je veux parler.
Je me demandais donc : qu'est ce qui justifie l'existence de ces deux méthodes de deserialization ? Quel est l'intérêt de l'utilisation de ProtocolTypeManager ?
Bonne fin de week-end à vous
