Aller au contenu principal

5. Paquets TFTP (TFTP Packets)

TFTP supporte cinq types de paquets, tous mentionnés ci-dessus :

OpcodeOpération
1Demande de lecture (Read request, RRQ)
2Demande d'écriture (Write request, WRQ)
3Données (Data, DATA)
4Acquittement (Acknowledgment, ACK)
5Erreur (Error, ERROR)

L'en-tête TFTP d'un paquet contient l'opcode associé à ce paquet.

Paquet RRQ/WRQ​

  2 octets     chaîne    1 octet     chaîne   1 octet
  ------------------------------------------------
 | Opcode |  Filename  |   0  |    Mode    |   0  |
  ------------------------------------------------

           Figure 5-1 : Paquet RRQ/WRQ

Les paquets RRQ et WRQ (opcodes 1 et 2 respectivement) ont le format montré dans la figure 5-1. Le nom de fichier est une séquence d'octets en netascii terminée par un octet zéro. Le champ mode contient la chaîne "netascii", "octet", ou "mail" (ou toute combinaison de majuscules et minuscules, comme "NETASCII", "NetAscii", etc.) en netascii indiquant les trois modes définis dans le protocole. Un hôte qui reçoit des données en mode netascii doit traduire les données dans son propre format. Le mode octet est utilisé pour transférer un fichier qui est dans le format 8 bits de la machine à partir de laquelle le fichier est transféré. Il est supposé que chaque type de machine a un seul format 8 bits qui est plus courant, et que ce format est choisi. Par exemple, sur un DEC-20, une machine 36 bits, il s'agit de quatre octets 8 bits par mot avec quatre bits de rupture. Si un hôte reçoit un fichier octet et le renvoie ensuite, le fichier renvoyé doit être identique à l'original. Le mode mail utilise le nom d'un destinataire de courrier à la place d'un fichier et doit commencer par un WRQ. Sinon, il est identique au mode netascii. La chaîne du destinataire de courrier devrait être de la forme "username" ou "username@hostname". Si la deuxième forme est utilisée, elle permet l'option de transfert de courrier par un ordinateur relais.

La discussion ci-dessus suppose que l'expéditeur et le destinataire opèrent dans le même mode, mais il n'y a aucune raison que cela soit le cas. Par exemple, on pourrait construire un serveur de stockage. Il n'y a aucune raison qu'une telle machine doive traduire netascii dans sa propre forme de texte. Au lieu de cela, l'expéditeur pourrait envoyer des fichiers en netascii, mais le serveur de stockage pourrait simplement les stocker sans traduction en format 8 bits. Une autre situation de ce type est un problème qui existe actuellement sur les systèmes DEC-20. Ni netascii ni octet n'accèdent à tous les bits dans un mot. On pourrait créer un mode spécial pour une telle machine qui lit tous les bits dans un mot, mais dans lequel le récepteur stocke l'information en format 8 bits. Lorsqu'un tel fichier est récupéré du site de stockage, il doit être restauré à sa forme originale pour être utile, donc le mode inverse doit également être implémenté. Le site utilisateur devra mémoriser certaines informations pour y parvenir. Dans ces deux exemples, les paquets de demande spécifieraient le mode octet à l'hôte étranger, mais l'hôte local serait dans un autre mode. Aucun mode spécifique à la machine ou à l'application n'a été spécifié dans TFTP, mais un serait compatible avec cette spécification.

Il est également possible de définir d'autres modes pour des paires d'hôtes coopérants, bien que cela doive être fait avec prudence. Il n'y a aucune exigence que d'autres hôtes les implémentent. Il n'y a pas d'autorité centrale qui définira ces modes ou leur attribuera des noms.

Paquet DATA​

         2 octets     2 octets      n octets
         ----------------------------------
        | Opcode |   Block #  |   Data     |
         ----------------------------------

              Figure 5-2 : Paquet DATA

Les données sont en fait transférées dans des paquets DATA représentés dans la figure 5-2. Les paquets DATA (opcode = 3) ont un numéro de bloc et un champ de données. Les numéros de blocs sur les paquets de données commencent par un et augmentent d'un pour chaque nouveau bloc de données. Cette restriction permet au programme d'utiliser un seul numéro pour discriminer entre les nouveaux paquets et les doublons.

Le champ de données a une longueur de zéro à 512 octets. S'il a une longueur de 512 octets, le bloc n'est pas le dernier bloc de données ; s'il a une longueur de zéro à 511 octets, il signale la fin du transfert. (Voir la section sur la terminaison normale pour plus de détails.)

Tous les paquets autres que les ACK en double et ceux utilisés pour la terminaison sont acquittés à moins qu'un délai d'expiration ne se produise [4]. L'envoi d'un paquet DATA est un acquittement pour le premier paquet ACK du paquet DATA précédent. Les paquets WRQ et DATA sont acquittés par des paquets ACK ou ERROR, tandis que les paquets RRQ et ACK sont acquittés par des paquets DATA ou ERROR.

Paquet ACK​

               2 octets     2 octets
               ---------------------
              | Opcode |   Block #  |
               ---------------------

               Figure 5-3 : Paquet ACK

La figure 5-3 représente un paquet ACK ; l'opcode est 4. Le numéro de bloc dans un ACK fait écho au numéro de bloc du paquet DATA acquitté. Un WRQ est acquitté avec un paquet ACK ayant un numéro de bloc de zéro.

Paquet ERROR​

     2 octets     2 octets      chaîne    1 octet
     -----------------------------------------
    | Opcode |  ErrorCode |   ErrMsg   |   0  |
     -----------------------------------------

              Figure 5-4 : Paquet ERROR

Un paquet ERROR (opcode 5) prend la forme représentée dans la figure 5-4. Un paquet ERROR peut être l'acquittement de tout autre type de paquet. Le code d'erreur est un entier indiquant la nature de l'erreur. Un tableau de valeurs et de significations est donné dans l'annexe. (Notez que plusieurs codes d'erreur ont été ajoutés à cette version de ce document.) Le message d'erreur est destiné à la consommation humaine, et devrait être en netascii. Comme toutes les autres chaînes, il est terminé par un octet zéro.

Dernière mise à jour le