Les premiers pas
Une «Tour de Babel YMODEM» s'est abattue sur la communauté des micro-ordinateurs, apportant avec elle confusion, frustration, factures de téléphone gonflées et heures de travail gaspillées. Malheureusement, Chuck Forsberg est en partie responsable de ce désordre.
En tant qu'auteur du lot du début des années 1980 et des extensions XMODEM 1k, il a supposé que les lecteurs des versions antérieures de ce document implémenteraient autant du protocole YMODEM que leurs compétences en programmation et leurs environnements informatiques le permettraient. Cette hypothèse s'est avérée plutôt naïve, car les programmeurs motivés par la pression concurrentielle ont mis en oeuvre le moins de YMODEM possible. Certains ont pris les parties de YMODEM les intéressant, les ont appliquées à MODEM7 Batch, Telink, XMODEM ou autre, et ont appelé le résultat YMODEM.
Jeff Garbers (directeur du développement du package Crosstalk) a tout dit : «Avec des protocoles dans le domaine public, quiconque veut les manipuler peut le faire.»
Les documents contenant des exemples modifiés dérivés de YMODEM.DOC ont ajouté à la confusion. Dans un cas, un soi-disant réécrivain de l'histoire a modifié le titre de la figure 1 de YMODEM.DOC de «Paquets de 1 024 octets» à «Protocole de transfert de fichiers YMODEM/CRC». Aucun des exemples XMODEM et YMODEM présentés dans ce document n'était correct.
Pour mettre fin à cette confusion, l'auteur Chuck Forsberg s'est efforcé de rendre «parfaitement clair» ce que signifie YMODEM, comme Ward Christensen l'a défini en inventant le terme en 1985.
À la majorité d'entre vous ayant lu, compris et respecté la définition de YMODEM de Ward, Chuck Forsberg s'excuse pour la gêne occasionnée.
Définitions
Voici quelques définitions en relation avec YModem :
| Terme | Description |
|---|---|
| ARC | ARC est un programme compressant un ou plusieurs fichiers dans une archive et extrait les fichiers de ces archives. |
| XMODEM | Fait référence à l'étiquette de transfert de fichiers introduite par le programme MODEM.ASM de Ward Christensen en 1977. Le nom XMODEM vient du programme XMODEM.ASM de Keith Petersen, une adaptation de MODEM.ASM pour les systèmes CP/M à distances (RCPM). On l'appelle également protocole MODEM ou MODEM2. Certains ne connaissant pas le mode de fichier de traitement par lots inhabituel de MODEM7 l'appellent MODEM7. D'autres alias incluent «CP/M Users' Group» et «TERM II FTP 3». Le nom XMODEM a été adopté en partie parce qu'il est distinctif et en partie en raison de l'intérêt des médias pour les babillards électroniques et les systèmes RCPM où il était accessible avec une commande «XMODEM». Ce protocole est pris en charge par tous les programmes de communication sérieux en raison de son universalité, de sa simplicité et de ses performances raisonnables. |
| XMODEM/CRC | Remplace la somme de contrôle de 1 octet de XMODEM par un contrôle de redondance cyclique de deux octets (CRC-16), offrant une protection moderne contre la détection d'erreurs. |
| XMODEM-1k | Fait référence au protocole XMODEM/CRC avec des blocs de données de 1024 octets. |
| YMODEM | Fait référence au protocole XMODEM/CRC (blocs 1k en option) avec transmission par lots comme décrit ci-dessous. En un mot, YMODEM signifie BATCH. |
| YMODEM-g | Fait référence à la variante de streaming YMODEM. |
| True YMODEM | Afin de résoudre le problème de la tour de Babel YMODEM, Omen Technology a déposé le terme True YMODEM pour représenter le protocole YMODEM complet décrit dans un document, y compris le nom du chemin, la longueur et la date de modification transmis dans le bloc 0. |
| ZMODEM | Utilise la technologie familière XMODEM/CRC et YMODEM dans un nouveau protocole offrant fiabilité, débit, gestion de fichiers et commodités utilisateur adaptées aux communications de données contemporaines. |
| ZOO | Comme ARC, ZOO est un programme compressant un ou plusieurs fichiers dans une «archive zoo». ZOO prend en charge de nombreux systèmes d'exploitation différents, notamment Unix et VMS. |
Algorithme de YModem côté émetteur
L'algorithme de pseudo-code de YModem côté émetteur repose sur une structure claire et séquencée permettant d'envoyer un ou plusieurs fichiers de manière fiable. Le processus commence par l'attente du signal 'C' provenant du récepteur, indiquant que ce dernier est prêt à recevoir les données avec vérification CRC. Ensuite, l'émetteur envoie un premier bloc spécial, le bloc 0, contenant les métadonnées du fichier telles que le nom et la taille. Ce bloc permet au récepteur de créer un fichier vide en préparation de la réception des données.
Une fois ce bloc d'introduction validé par un accusé de réception (ACK), l'émetteur entre dans une boucle où il lit les données du fichier par paquets de 1024 octets. Chaque bloc de données est numéroté, encapsulé avec un entête, une vérification CRC et un identifiant complémentaire pour garantir l'intégrité des transmissions. Chaque envoi est suivi de l'attente d'un ACK du récepteur avant de poursuivre. En cas d'erreur de transmission, des mécanismes de renvoi du bloc peuvent être déclenchés.
Lorsque toutes les données ont été transmises, l'émetteur envoie un caractère de fin de transmission (EOT), attend un dernier ACK, puis peut passer à l'envoi du fichier suivant. Si aucun fichier supplémentaire n'est à transmettre, un bloc 0 vide est envoyé pour indiquer la fin de session. L'algorithme YModem côté émetteur assure ainsi une transmission structurée, avec vérification systématique de l'intégrité et synchronisation constante avec le récepteur, offrant un protocole fiable pour les transferts en mode série.
|
MODULE YModemSend Attendre le signal 'C' du récepteur (indique début de transfert CRC) POUR CHAQUE fichier à envoyer Envoyer le bloc 0 : - Contient nom du fichier et sa taille - Ajouter CRC - Attendre ACK (accusé de réception) Ouvrir le fichier à envoyer Numéro_bloc ← 1 BOUCLE TANT QU'IL reste des données à lire Lire 1024 octets du fichier (remplir avec 1Ah si besoin) Construire le bloc de données : - SOH/STX, numéro_bloc, 255 - numéro_bloc, données, CRC Envoyer le bloc Attendre ACK Incrémenter numéro_bloc FIN BOUCLE TANT QUE Fermer le fichier Envoyer une séquence EOT (fin de transmission) Attendre ACK RÉPÉTER pour le fichier suivant FIN POUR CHAQUE Envoyer un dernier bloc 0 vide (nom et taille vides) Attendre ACK |
Algorithme de YModem côté récepteur
L'algorithme de pseudo-code de YModem côté récepteur commence par l'envoi du caractère 'C' vers l'émetteur, signalant que le récepteur est prêt à recevoir des données et souhaite utiliser la méthode de vérification CRC. Ce signal est envoyé de manière répétée tant que l'émetteur ne répond pas. Une fois la réponse reçue, le récepteur s'attend à recevoir le bloc 0 contenant les métadonnées du fichier (nom, taille, etc.). Si ce bloc est valide, le récepteur crée le fichier localement en préparation de la réception des données.
Après la validation du bloc 0, le récepteur envoie un accusé de réception (ACK), puis recommence à envoyer 'C' pour initier la réception des blocs de données. Pour chaque bloc reçu, le récepteur vérifie le numéro du bloc, la complémentarité du numéro inverse, et la validité du CRC. Si le bloc est valide, les données sont écrites dans le fichier, puis un ACK est renvoyé à l'émetteur. En cas d'erreur de transmission, le récepteur envoie un NAK pour demander une retransmission du bloc. Ce processus se poursuit jusqu'à la réception d'un caractère de fin de transmission (EOT).
Lorsque le caractère EOT est détecté, le récepteur envoie un ACK final, indiquant que la transmission est terminée pour le fichier courant. S'il s'agit d'un transfert multi-fichiers, le récepteur renvoie 'C' pour initier la réception du fichier suivant. Sinon, si un bloc 0 vide est reçu, cela signifie que la session de transmission est terminée. L'algorithme YModem côté récepteur assure donc un contrôle précis de la réception, avec des vérifications systématiques d'intégrité et une gestion robuste des erreurs de communication.
|
MODULE YModemReceive Envoyer le caractère 'C' pour signaler début avec CRC RÉPÉTER Recevoir le bloc 0 : - Extraire nom et taille du fichier - SI nom vide ALORS Fin du transfert - Créer un fichier avec ce nom - Envoyer ACK Numéro_bloc_attendu ← 1 RÉPÉTER Recevoir bloc de données Vérifier numéro de bloc et CRC SI bloc valide ALORS Écrire données dans le fichier Envoyer ACK Numéro_bloc_attendu ← Numéro_bloc_attendu + 1 SINON Envoyer NAK FIN SI JUSQU'À réception de EOT Envoyer ACK Fermer le fichier JUSQU'À réception d'un bloc 0 vide |