Résumé

  • XMODEM limitait le terrain commun à un bloc de 128 octets, un numéro et son complément, une somme de contrôle, un acquittement piloté par le récepteur et un signal de fin. Il ne prétendait pas administrer l’appel, le disque ou l’expérience utilisateur.
  • Cette sobriété réduisait le coût d’une implémentation indépendante et rendait les écarts observables. Le contrôle d’erreur restait faible, l’attente après chaque bloc pénalisait les lignes lentes et les métadonnées manquaient, mais les successeurs pouvaient corriger ces points sans confier la compatibilité à un service central.

Un protocole que l’on peut retenir

Le cœur de XMODEM tient dans une courte succession : SOH, numéro de bloc, complément à un du numéro, 128 octets de données, somme de contrôle. Le numéro commence à un et avance bloc après bloc. Le complément aide à repérer un en-tête abîmé. Pour vérifier les données, on additionne les octets et l’on abandonne la retenue.

Le dialogue est tout aussi dépouillé. Le programme récepteur envoie NAK lorsqu’il est prêt. L’émetteur transmet alors le premier bloc. Si le calcul du récepteur concorde, celui-ci répond ACK ; sinon, NAK demande une nouvelle tentative. À la fin, EOT annonce qu’il n’y a plus de données, puis attend son acquittement.

Rien dans cet échange ne choisit le fichier sur le disque, ne compose un numéro de téléphone, ne crée un compte ni ne dessine une barre de progression. Le protocole ne sait pas davantage qui exploite la machine distante. Il impose uniquement les faits que deux programmes doivent partager pour transporter une suite d’octets.

Le choix de 128 n’était pas une vérité universelle. Il correspondait au secteur de disquette CP/M dans l’environnement de Christensen. Une taille fixe simplifiait les tampons et le code sur des machines contraintes. Elle obligeait aussi à compléter le dernier bloc et ne fournissait pas, à elle seule, la longueur exacte du fichier.

Le doublon qui répare un accusé perdu

La manière dont XMODEM traite un bloc répété montre la qualité de cette petite frontière. Le récepteur attend normalement le numéro suivant. Il peut pourtant recevoir une seconde fois le bloc précédent. Cette répétition n’indique pas nécessairement que les données ont échoué : l’ACK retourné après leur première réception a pu être corrompu, conduisant l’émetteur à recommencer.

Le récepteur accepte donc ce doublon comme un événement de reprise et renvoie l’acquittement, sans écrire deux fois les mêmes 128 octets. Un numéro qui n’est ni celui attendu ni le précédent peut, en revanche, signaler une perte de synchronisation assez grave pour interrompre le transfert.

Cette règle résout une ambiguïté précise avec très peu d’état. Aucun arbitre central ne conserve une version canonique. Les deux extrémités retrouvent leur accord au moyen d’un numéro, de la mémoire du bloc antérieur et d’un octet de réponse. La fiabilité ne signifie pas absence de panne ; elle signifie que certaines pannes produisent une réaction prévisible de part et d’autre.

Christensen a plus tard qualifié son travail de 1977 de solution improvisée à un besoin personnel. Selon lui, l’avoir achevé tôt puis placé immédiatement dans le domaine public a contribué à en faire un standard. Ce témoignage éclaire son intention mais ne prouve pas, à lui seul, la cause de la diffusion. L’économie de mise en œuvre reste néanmoins claire : un petit programme pouvait être copié, lu, porté et confronté à un autre sans demander l’autorisation d’un propriétaire de réseau.

Un standard de fait observé par un RFC

Il serait trompeur de présenter XMODEM comme un standard élaboré par l’IETF. Le RFC 916, publié en 1984, proposait un autre protocole fiable pour les liaisons asynchrones. Son annexe décrivait MODEM/XMODEM parce que celui-ci était déjà couramment utilisé dans le monde des micro-ordinateurs.

Le texte en consignait aussi les limites. Le flux de données était unidirectionnel ; les paquets avaient une taille fixe de 128 octets ; certains concentrateurs intermédiaires géraient mal de longues arrivées continues. Ajouter l’attente d’un ACK après chaque bloc revient en outre à gaspiller une part croissante de la liaison lorsque l’aller-retour s’allonge. La somme de contrôle élémentaire ne détecte pas toutes les corruptions.

La minceur du protocole ne rendait donc pas chaque compromis judicieux pour toujours. Elle rendait toutefois le défaut localisable. On pouvait compter les reprises, mesurer le débit, injecter des erreurs et constater le traitement du dernier bloc. Une dépendance enfouie dans un service réunissant identité, stockage et transfert aurait été beaucoup plus difficile à isoler.

Les extensions devaient faire leurs preuves

Des pratiques ultérieures ont ajouté un CRC-16 plus solide, des blocs optionnels de 1K et un bloc zéro portant notamment le nom et la taille du fichier. Les programmes diffusés par Chuck Forsberg ont aidé ces extensions à circuler sous des appellations telles que YMODEM.

Christensen se méfiait de l’idée de transformer le noyau en système duplex intégral, avec plusieurs blocs non acquittés ou plusieurs destinations. Il ne niait pas l’utilité de transferts plus riches. Il estimait que l’extrême simplicité expliquait la survie du protocole sur tant de machines et dans tant de logiciels. Une innovation qui rend immédiatement tous les anciens correspondants invalides ne change pas seulement la technique : elle déplace le pouvoir de définir le socle.

L’adoption volontaire n’a pas supprimé la confusion. Les références historiques signalent que des produits portant le même nom YMODEM pouvaient se comporter différemment. Une étiquette n’établit pas l’interopérabilité. Celle-ci naît d’une boucle plus exigeante : proposition, programme concret, fichiers d’essai, déploiement limité, observation des échecs, description exacte des capacités.

Le tableau d’affichage n’était pas dans le paquet

Après le blizzard de Chicago de 1978, Christensen et Randy Suess ont créé CBBS, Suess prenant en charge le matériel et Christensen le logiciel. Ce tableau d’affichage répondait au téléphone, conservait des messages et formait un lieu auquel les utilisateurs revenaient. Il appartient au contexte social de XMODEM, pas à la définition de son bloc.

Cette distinction a permis à des BBS, des terminaux et des interfaces différents d’ajouter le transfert de fichiers sans devenir les clients d’un service XMODEM unique. Le fil commun restait stable tandis que le produit autour pouvait varier.

Le legs n’est donc pas le nombre 128. C’est une façon de tracer une limite : rendre strict ce qui doit être identique pour que deux extrémités se comprennent, et maintenir ailleurs le droit de choisir. Les extrémités n’étaient pas libres de violer l’ordre ou le contrôle partagé ; elles restaient libres de ne pas se ressembler là où le transfert n’exigeait aucune uniformité.

Sources