Netcode généralités
Généralités concernant le protocole réseau de T4C
Type de transmission
Le protocole réseau de T4C est de type non-connecté (UDP/IP). Le contrôle d'erreur se fait donc au niveau application (c'est le serveur et les clients T4C qui doivent savoir les gérer, ainsi que la retransmission des données perdues) et non au niveau protocole (ce n'est pas la pile IP du système d'exploitation, ni la DLL Winsock qui le fera).
- Le port d'écoute par défaut du serveur est 11677.
- Le port d'écoute des clients est aléatoire. Le serveur le retiendra comme le port source UDP du premier paquet d'informations que le client lui envoie et enverra subséquemment toutes les communications à ce client sur ce port.
Quand intervient l'échange d'informations sur le réseau ?
Le serveur et les clients T4C s'échangent des paquets d'information UDP sur le réseau pour toutes sortes de raisons. Principalement :
- Le client envoie au serveur toutes les notifications concernant ses actions (demande d'actualisation de la liste des sorts, demande d'actualisation de l'inventaire, déplacement du personnage dans telle ou telle direction, attaque d'un monstre, etc)
- Le serveur répond au client en le renseignant sur le résultat de ces actions, et l'informe sur l'état des différents éléments dynamiques qui composent son environnement (monstres, PNJ, lumière du jour, ce que font les autres joueurs, etc)
En résumé, des paquets d'information sont échangés quand :
- Le client demande et le serveur répond
- Le serveur informe le client des changements dans l'environnement de son personnage
Définition du vocabulaire employé
- Le datagramme: il s'agit des données brutes de la charge utile (payload) d'un paquet UDP.
- Le pak: il s'agit des données brutes de la charge utile (payload) d'un datagramme (ou de plusieurs datagrammes s'il s'agit d'un pak fragmenté), en gros ce qui intéresse le jeu.
- Le header (en-tête): suivant les versions du protocole réseau, il s'agit des N premiers octets d'un datagramme (ou de plusieurs datagrammes s'il s'agit d'un pak fragmenté), porteurs d'information sur le pak telles que son identifiant, ses flags, la longueur de ses données, sa clé d'encryption et, dans le cas d'un pak fragmenté, d'informations sur le datagramme telles que la position des données transportées par celui-ci dans le pak fragmenté.
- Le footer: suivant les versions du protocole réseau, il s'agit des N derniers octets d'un datagramme (ou de plusieurs datagrammes s'il s'agit d'un pak fragmenté), porteurs d'informations sur le pak telles que la somme de contrôle (checksum) de celui-ci.
- Le netcode: abréviation anglaise pour protocole réseau. Sous-entend, plus particulièrement, les algorithmes d'encryption.
Diagramme explicatif:
[====================================== PAQUET IP ======================================]
[================= Ce qu'on voit effectivement passer sur le réseau ====================]
[en-tête IP][============================== DATAGRAMME UDP =============================]
[============ Ce qui est reçu par le buffer de la carte réseau =============]
[header][======================== PAK encrypté =====================][footer]
[================ Ce qui intéresse l'algorithme d'encryption ===============]
[======================== PAK décrypté =====================]
[================== Ce qui intéresse le jeu ================]
Visualisation d'un datagramme T4C dans plusieurs formats
Voici l'exemple d'un datagramme T4C selon le protocole 1.25, une fois que les données ont été reçues et que l'encryption a été levée (note: pour savoir comment lever ou réappliquer l'encryption 1.25, consultez la page correspondante).
Format Ordinal : Il s'agit des données ASCII brutes du datagramme UDP telles qu'on les verrait dans un sniffer Ethernet, ou si on imprimait simplement à l'écran le contenu du buffer de réception de la carte réseau.
5¥‹¹B¬Bienvenue sur le Wiki de T4C !
Format Décimal : Il ne s'agit que des valeurs numériques des octets composant le buffer de réception, visualisées en base 10.
000 002 053 000 004 000 000 000 000 000 000 000 003 165 139 185 000 066 000 031 066 105 101 110 118 101 110 117 101 032 115 117 114 032 108 101 032 087 105 107 105 032 100 101 032 084 052 067 032 033 013
Format Hexadécimal : Il s'agit encore des valeurs numériques des octets composant le buffer de réception, visualisées cette fois en base 16, c'est-à-dire telles qu'on les verrait en mémoire, ou dans un sniffer Ethernet (tel qu'Ethersnoop).
00 02 35 00 04 00 00 00 00 00 00 00 03 A5 8B B9 00 42 00 1F 42 69 65 6E 76 65 6E 75 65 20 73 75 72 20 6C 65 20 57 69 6B 69 20 64 65 20 54 34 43 20 21 0D
Parsing du paquet (Identification de chaques parties)
00.c (char en position 0)
Exemple :
00
Description :
Identification du paquet dans une suite en udp, on n’est jamais certain d'obtenir le paquet dans le même ordre que le client/serveur les a envoyé.
Si jamais le paquet faisait au total plus de 1024 octets, donc 1ko (1octet = 2 valeurs hexa, ex.: A3), Il serait alors coupé en plusieurs parties afin de ne pas dépasser les 1024 octets.
Ce paramètre du paquet permet alors, en cas de splitage du paquet, de nous redonner l'ordre des paquets reçus.
On aurait très bien pu avoir le premier paquet splitté, puis le troisième splitté et enfin le second splitté, on les remettrait alors dans l'ordre grâce a l'identifiant.
La valeur décimale est le numéro du paquet.
01.c (char en position 1)
Exemple :
02
Description :
C'est le type du paquet, le type du paquet permet de prévenir le récepteur du paquet si il doit lui renvoyer un pong ou non, si c'est un pack splitté, etc.
La valeur décimale est le type du paquet.
Les types de paquets : 0 : Paquet normal, sans demande de pong. 1 : Un pong. 2 : Paquet normal, avec demande de pong. 4 : Paquet splitté, sans demande de pong. 6 : Paquet splitté, avec demande de pong.
PS : Si on tombe sur un paquet avec comme type 4 ou 6, ceci veut dire que c'est un paquet splitté, il faut essayer de patienter afin d'obtenir le reste du paquet en interagissant avec les identifiants du paquet, le type du paquet, sont poids total et les Ids des paquets pour savoir si on se trouve dans les bonnes chaînes etc.
02.s (short(2 char) en position 2)
Exemple :
35 00
Description : C'est le poids du paquet, En cas de splittage, se paramètre permet de connaitre le poids total de tous les paquets splittés, comme cela, quand on a tout son poids en stock on peut se permettre de ranger les paquets dans l'ordre puis de le décrypter.
La valeur décimale est le poids total du paquet.
04.l (long(2 short, 4 char) en position 4)
Exemple :
04 00 00 00
Description : L'Id du paquet (aléatoire), Comme l'explique l'identifiant du paquet, on est pas sûrs d'avoir le paquet total dans l'ordre, imaginez si deux paquets différents se splittent et se réceptionnent dans le désordre, l'Id permet de retrouver quels paquets va avec qui en interagissant avec le pong du byte numéro 8.
Il permet de faire le tri entre plusieurs paquets splittés de nature différentes, puis grâce a l'identifiant du paquet splitté de nature différente, puis grâce a l'identifiant du paquet, on met chaque tris dans l'ordre.
08.l (long(2 short, 4 char) en position 8)
Exemple :
00 00 00 00
Description : L'Id du paquet de départ, il s'utilise avec l'id du paquet en long du byte en position 4, par exemple, le long du byte 4 est égal à 04 00 00 00 dans le premier paquet, le paquet suivant splitté aura en long le 8ème byte 04 00 00 00, ça permet de trier entre différents paquets splittés qui peuvent subvenir en même temps.
12.s (short(2 char) en position 12)
Exemple :
03 A5
Description : Le Random Seed, c'est le point le plus important des paquets T4C.
Après une série d'application mathématique dessus, on obtient des clés à xorer sur la partie encodées(16.x) afin d'obtenir la partie en décodée.
14.s (short(2 char) en position 14)
Exemple :
8B B9
Description : Le CheckSum, Quand un paquet est reçu, il est possible que celui ci ai subit une altération, le checksum est là pour vérifier si cette altération a eu lieux.
Une fois la partie encryptée décodée, on additionne byte par byte la partie décodée pour obtenir un résultat, si celui ci n'est pas égale au checksum, c'est qu'il y a eu une altération, il faux absolument ignorer le paquet !
16.x (char *(X char) data du paquet en position 16)
Exemple :
00 42 00 1F 42 69 65 6E 76 65 6E 75 65 20 73 75 72 20 6C 65 20 57 69 6B 69 20 64 65 20 54 34 43 20 21 0D
Description : La partie encodée, C'est la partie dont je parlais pendant le Random Seed et le CheckSum, une fois décryptée, il y a un second parsing à appliquer sur le paquet.
Prenez le premier short de cette partie, et convertissez le en décimal, vous avez l'Id de l'action.
Cherchez cette Id dans la Structure des paks connus.
La suite de la partie décodée est appliquée a ka suite de vitre recherche dans la Structure des paks connus.
Exemple des données de ce paquet qui contient l'Id 66 ($42) qui est un paquet MOTD :
Dans la Structure des paks connus nous trouvons :
#define PAK_SERVER_MessageOfTheDay 0x0042 // 2 string16 message;
Cela signifie que la partie décodé sans l'identifiant est :
00 1F 42 69 65 6E 76 65 6E 75 65 20 73 75 72 20 6C 65 20 57 69 6B 69 20 64 65 20 54 34 43 20 21 0D
Donc en ordinal :
31Bienvenue sur le Wiki de T4C !<chr(13)>
Dans notre exemple cela veut dire que le data contient un short(00 1F) qui est la taille d'une chaîne de caractère qui celle ci est "Bienvenue sur le Wiki de T4C !<chr(13)>"
Je remercie Kalis pour m'avoir fournit une bonne partie de ces informations il y a quelques années.
--Mestoph 12 mars 2008 à 08:31 (UTC)