Nous allons expliquer comment décrypter le fichier “ryzom_xxx.idx”. Ce fichier est le premier fichier télécharger par le client, il permet de mettre à jour le client. De plus, on retrouve la base de la communication réseau (enfin je pense) Par la suite, je vais considéré le fichier comme un document.

Le fichier est séparé en quatre zone.

Version : Définit la version du document

Taille totale : Taille du document (incluant tous les champs)

Chaque token a une taille de 16 bits. Un token permet de décrypter le contenu du document

Un token est séparé en deux groupes:

1. Token ID : Définit la fonction du token
2. Token Type : Définit le type de donnée

Cette structure flexible permet de définir la structure des données de manière non rigide. Un plus pour toute évolution, par contre moins simple à décrypter.

Ainsi pour notre fichier patch nous avons une liste de fichier et une catégorie.

pour chaque fichier:

Pour chaque categorie : (en fait il y en a qu'une)

Corresponde à l'ID (la fonction du token)

Ici on a un numéro, mais il fait référence à un mot de clef (position dans le tableau/liste de String)

Bref, sans le tableau de string, impossible de savoir la fonction du token !

Un token type est sur 16 bits, avec une possibilité qu'il soit étendu (donc 32 bits) (via l'option EXTEND_TOKEN)

Quand il est étendu, il doit avoir le même Token ID.

Sans interprétation :

En interprétant l'option “Extend”, si il est définit:

Chiffre sur 32bits Suivant les informations du token, il peux s'agit d'un nombre signé, non signé, 32 bits, 64 bits, …

Chaque chaîne de caractère sont séparé par '\0'. (à l'image d'un string en C/C++)

1. On lit le premier token (on sépare token id et token type)
2. Puis suivant le type on lit le/les arguments (1, 2 voir 3 - mais jamais vu dans le patch)
3. Dans le cas d'une chaîne on récupère la valeur de l'argument (on garde que la partie basse) et on obtiens la position de la chaîne.
4. Et on envoie la donnée.

Attention, dans le cas de EXTEND_TYPE, il faudra lire le token suivant