Spécification du protocole HPGTSUR

Introduction

La Compagnie Cybernétique de Sirius est heureuse de vous présenter son nouveau protocole de consultation de fichier HyperProtoGalactifornet de Transfération Siriusienne Ultra-Réglementée¹ (HPGTSUR).

Ce protocole, reposant sur TCP, est orienté client/serveur. Le serveur expose un système de fichiers, composé de répertoires et de… fichiers. Un client a alors la capacité de se déplacer dans l’arborescence, de lister les fichiers présents dans le répertoire courant, et de télécharger les fichiers présents.

Notez que les noms des fichiers sont en UTF-8, et peuvent comporter la plupart des caractères, à l’exception notable de l’espace d’une part, et du caractère / qui est utilisé comme séparateur.

La Compagnie Cybernétique de Sirius espère que vous aurez toute satisfaction dans l’utilisation de ce protocole.

Format des paquets

Généralités

Un paquet est structuré de la manière suivante :

Champ Taille Description
ID requête 4 octets Identifiant de la requête
Requête / réponse 1 bit 1 pour requête, 0 pour réponse
Erreur 1 bit Pour réponse uniquement, 1 si erreur, 0 sinon
Type commande 6 bits Type de commande (cf ci-après)
Séquence 14 bits Numéro de séquence (0-16383)
Taille payload 10 bits Taille de la payload (0-1023)
Payload Variable Contenu (dépend du type de commande)
CRC 4 octets Somme de contrôle

Les champs sont orientés gros-boutiste.

Identifiant de la requête

L’ID de requête est un entier sur 4 octets, commun à l’ensemble des échanges liés à une commande : le paquet de requête, le ou les paquets de réponse et/ou le paquet d’erreur associé. La génération de l’identifiant est à la charge du client, mais il doit être unique à l’ensemble d’une transmission globale entre un client et un serveur; dans le cas contraire les conséquences ne sont pas spécifiées.

Requête / réponse

Bit indiquant si le paquet est une requête (émise par un client, valeur 1) ou une réponse (émise par un serveur, valeur 0).

Erreur

Bit positionné dans un paquet émis par le serveur si une erreur a été détectée dans une requête. Dans ce cas, la payload contient un message d’erreur l’explicitant.

Par exemple: Fichier truc.txt non trouvé.

Type commande

Les commandes disponibles pour les requêtes sont les suivantes :

Dans le cas d’une réponse, le champ contient la commande à laquelle la réponse est associée.

Séquence

Le protocole supporte la fragmentation des réponses. Si la payload est plus grande que 1023 octets, il la découpe en plusieurs paquets, en incrémentant le numéro de séquence. Attention, il peut arriver que les fragments n’arrivent pas dans le bon ordre ! C’est même assez fréquent.

Si la valeur du champ séquence est 0, cela signifie que la réponse n’est pas fragmentée. Elle l’est lorsque le numéro de séquence est strictement positif. Notez que, par conséquent, les numéros de fragments commencent à l’index 1.

Payload

Contenu du paquet. Pour les requêtes émises par un client, il peut s’agir de paramètres (par exemple le nom du répertoire pour une commande CHFLD). Pour les réponses, le contenu dépend de la commande de la requête correspondante. Cf. ci-après la description de chacune des commandes. Une réponse contenant une payload de plus de 1023 octets sera découpée en plusieurs paquets (Cf. Séquence ci-dessus).

CRC

Une somme de contrôle permettant de s’assurer de l’intégrité du paquet. Elle est calculée sur l’intégralité du contenu du paquet, hormis le CRC lui-même évidemment. L’algorithme utilisé est le classique CRC32. Dans le cas où l’on reçoit un paquet dont le CRC n’est pas valide, on peut demander la réémission du paquet à l’aide de la commande RSND.

Commandes et réponses

Dans les exemples ci-dessous, les données binaires sont exprimées sous forme hexadécimale, et les payloads sous forme textuelle.

Attention, les payloads des erreurs documentées ci-dessus sont données à titre indicatif mais peuvent varier suivant l’ implémentation du serveur.

Liste les fichiers (LST/01)

Cette commande demande à lister le contenu du répertoire courant. La payload de cette commande doit être vide, sinon le serveur retourne une erreur.

Dans la réponse, le serveur indique la liste des répertoires et des fichiers contenus dans le répertoire courant. Chaque élément est préfixé par un D pour un répertoire ou un F pour un fichier. Les différents éléments sont séparés par des retours chariot ().

Exemple de commande :

<ID>|0|0|01|00|0||<CRC>

Exemple de réponse :

<ID>|1|0|01|00|39|F foo.txt\nD Folder1\nD Folder2\nF bar.txt|<CRC>

Exemples d’erreur :

<ID>|1|1|01|00|40|Le contenu de la requête doit être vide.|<CRC>
<ID>|1|1|01|00|34|La somme de contrôle est invalide.|<CRC>

Change le répertoire courant (CHFLD/02)

Cette commande permet de changer le répertoire courant. Il prend en paramètre (dans la payload) le nom du répertoire dans lequel se positionner relativement au répertoire courant. Il n’est pas possible de se déplacer de plusieurs répertoires en une seule commande. Pour «remonter» dans l’arborescence, on demande à se déplacer dans le pseudo répertoire ...

En cas de succès, la payload de la réponse est vide.

Exemple de commande :

<ID>|0|0|02|00|7|Folder1|<CRC>

Exemple de réponse :

<ID>|1|0|02|00|0||<CRC>

Exemples d’erreur :

<ID>|1|1|02|00|27|Le répertoire n'existe pas.|<CRC>
<ID>|1|1|02|00|34|La somme de contrôle est invalide.|<CRC>

Retourne le répertoire courant (PWD/03)

Cette commande retourne le répertoire courant. Aucun paramètre n’est attendu dans la requête (dans le cas contraire, le serveur répondra par une erreur).

En cas de succès, la payload de la réponse contient le chemin absolu du répertoire courant. Il s’agit de la concaténation des différents sous-répertoire avec le séparateur /.

Exemple de commande :

<ID>|0|0|03|00|0||<CRC>

Exemple de réponse :

<ID>|1|0|03|00|12|root/Folder1|<CRC>

Exemples d’erreur :

<ID>|1|1|03|00|40|Le contenu de la requête doit être vide.|<CRC>
<ID>|1|1|04|00|37|La somme de contrôle est invalide.|<CRC>

Télécharger un fichier (DWNLD/04)

Cette commande retourne le contenu d’un fichier. Le nom du fichier à télécharger est passé dans la payload. Seul un fichier du répertoire courant peut-être téléchargé.

En cas de succès, la payload de la réponse contient le contenu binaire du fichier. Celle-ci sera fragmentée si le fichier fait plus de 500 octets.

Exemple de commande :

<ID>|0|0|04|00|7|foo.txt|<CRC>

Exemple de réponse :

<ID>|1|0|04|01|1023|Ceci est le contenu du fichier de test foo.txt [...]|<CRC>
<ID>|1|0|04|02|1023|Le fichier fait plus de 500 octets ce qui implique une réponse fragmentée [...]|<CRC>
<ID>|1|0|04|03|43|Fin du fichier. (c'est toujours du contenu)|<CRC>

Exemples d’erreur :

<ID>|1|1|03|00|32|Le fichier demandé n'existe pas.|<CRC>
<ID>|1|1|04|00|34|La somme de contrôle est invalide.|<CRC>

Réémettre (RSND/05)

Dans le cas où le client reçoit une réponse invalide (la somme de contrôle ne correspond pas au contenu), il peut redemander l’émission du paquet par le serveur. Pour cela, la requête doit contenir l’identifiant et le numéro de séquence exacts de la réponse à répéter. De plus, la payload de cette commande doit être vide, le serveur retournant une erreur dans le cas contraire.

Attention, la plupart des implémentations des serveurs ne sont pas capables de répondre à une demande concernant une ancienne commande. Si vous demandez la réémission d’un paquet d’une commande alors qu’une autre a été envoyée entre temps, il est probable que le serveur retourne une erreur.

Par exemple, si le client a reçu la réponse suivante :

<ID>|1|0|04|<SEQ>|<taille>|<contenu d'un fichier binaire>|<bad CRC>

il peut demander la réémission du paquet avec la commande RSND en reprenant l’identifiant de requête et le numéro de séquence de la réponse invalide :

<ID>|0|0|05|<SEQ>|0||<CRC>

Exemple de réponse :

<ID>|1|0|04|<SEQ>|<taille>|<contenu d'un fichier binaire|<CRC>

Exemples d’erreur :

<ID>|1|1|05|00|22|Le paquet est inconnu.|<CRC>
<ID>|1|1|05|00|27|La payload doit être vide.|<CRC>
<ID>|1|1|05|00|34|La somme de contrôle est invalide.|<CRC>
<ID>|1|1|05|00|34|Ce paquet n'a pas été retrouvé.|<CRC>

Notes

¹: La Compagnie tient à présenter ses excuses pour les dommages occasionnés à la lecture de ce nom, choisi parmi 1823 alternatives par les 6 sous-groupes de la commission de l’administration Vogon, premier acquéreur du système.

Crédits

© Compagnie Cybernétique de Sirius, tous droits réservés, et merci pour le poisson.