Résumé

  • Créé à Columbia en 1981, Kermit répondait au besoin de transférer des fichiers entre les ordinateurs centraux et les micro-ordinateurs utilisés par les étudiants et le personnel.
  • Ses petits paquets acquittés passaient par une liaison série, tandis que des conventions de caractères, d’enregistrements et d’options négociées traitaient des différences que le câble ne pouvait résoudre.

La première démonstration de transfert Kermit fit communiquer deux programmes Kermit-20 au moyen d’un câble null-modem reliant deux ports série du même DECSYSTEM-20. Le projet Kermit l’a ensuite qualifiée de preuve de faisabilité : sur un seul ordinateur, une simple commande de copie aurait été plus facile. Le test décisif eut lieu quelques semaines plus tard. D’un côté, un DEC-20 sous TOPS-20 ; de l’autre, un Intertec Superbrain sous CP/M-80. Processeur, système d’exploitation et représentation des fichiers différaient. Envoyer des octets n’était que la partie visible du problème.

À Columbia, les usages évoluaient. Des micro-ordinateurs arrivaient dans les laboratoires, les départements, les logements et les résidences universitaires, tandis que les fichiers utiles restaient sur les systèmes centraux à temps partagé. Dans un article préparé en 1983, Frank da Cruz et Bill Catchings expliquaient que les identifiants des étudiants, attribués par cours ou par semestre, ne leur garantissaient pas un espace disque durable. Une disquette pouvait conserver les travaux localement, à condition de pouvoir les transférer de façon fiable entre le petit ordinateur et le système central.

Ce récit éclaire le problème d’une université ; il ne prouve pas que toutes les universités connaissaient la même situation.

La liaison rendait les différences plus difficiles à gérer. Une ligne série asynchrone ordinaire ne protégeait guère contre le bruit, la perte de caractères, le débordement des tampons ou les coupures intermittentes du porteuse. Kermit découpa donc le transfert en paquets et transforma chaque paquet en élément d’un dialogue. L’émetteur commençait par un paquet Send-Init, qui annonçait ses paramètres. Le récepteur répondait avec les siens. Un en-tête de fichier donnait son nom, les paquets de données en transportaient les fragments, et des paquets distincts marquaient la fin du fichier puis celle du transfert.

L’accusé de réception permettait d’avancer ; un refus ou une expiration du délai déclenchait une retransmission.

Le mécanisme restait volontairement modeste. Le numéro de paquet avançait modulo 64 : les deux programmes pouvaient ainsi savoir quelle unité avait été acquittée et repérer une étape manquante ou répétée pendant l’échange. Un contrôle arithmétique obligatoire d’un caractère aidait à détecter un paquet altéré. Ce n’était ni un contrôle cryptographique moderne ni une identification de la personne au terminal. Il permettait aux logiciels de repérer certaines erreurs de transmission et de recommencer. La fiabilité venait de leur coopération, pas d’un câble devenu fiable.

Le défi d’interopérabilité de Kermit se situait aussi au-dessus de la ligne. Deux machines pouvaient échanger des caractères ASCII et interpréter les fichiers différemment. Le DEC-20 et CP/M n’organisaient pas le stockage de la même façon ; les systèmes IBM ajoutaient d’autres contraintes. Un fichier pouvait être composé d’enregistrements plutôt que d’un simple flux d’octets. Les codages de texte variaient, et le terminal d’un système central pouvait faire écho, couper les lignes, modifier la casse ou interpréter certains caractères de contrôle.

Une connexion traitée comme un tuyau transparent risquait donc d’altérer le contenu avant son écriture sur le disque destinataire.

Kermit introduisit une représentation commune pour le transfert et des conversions explicites aux deux extrémités. La syntaxe de base utilisait des caractères imprimables ; les octets de contrôle présents dans les données pouvaient être encodés sous forme de séquences imprimables. Chaque programme traduisait ensuite ce format d’échange vers les conventions locales du fichier. Le manuel situe précisément l’hypothèse partagée : ASCII sur une ligne série asynchrone ordinaire. Il ne rendait pas les ordinateurs identiques. Il leur fournissait un langage limité pour échanger malgré les différences de stockage, de codage et de terminal.

Il fallait aussi que des implémentations aux capacités inégales puissent fonctionner ensemble. Le manuel de novembre 1983 explique que le développement étant distribué, aucune version fixe ne pouvait être imposée à tous les auteurs. Il définissait un socle de fonctions et des options, annoncées lors de l’échange initial. Son ambition était qu’un programme élémentaire puisse travailler avec un programme plus avancé. C’est un objectif de conception exprimé dans le manuel, pas la preuve que toutes les paires de programmes Kermit étaient interopérables.

Le noyau minimal n’a pas figé le protocole. Des versions ultérieures ont ajouté des paquets plus longs, des contrôles plus robustes et les fenêtres glissantes en duplex intégral. Le manuel attribue ce dernier développement à un groupe de The Source Telecomputing en 1985–1986. Il répondait à une autre contrainte : attendre un accusé après chaque paquet peut gaspiller du temps sur un trajet présentant un délai notable. L’option devait être négociée ; le récepteur qui ne la prenait pas en charge pouvait rester au mode de base. Ces évolutions témoignent d’une famille de programmes, pas d’une fonction à attribuer au transfert initial de 1981.

La chronologie du projet signale un site FTP et la liste Info-Kermit sur l’ARPANET en 1984. Le réseau facilita la diffusion et les échanges autour du protocole, tandis que son besoin d’origine restait concret : un utilisateur voulait envoyer un fichier d’un ordinateur à un autre. Kermit n’était pas une norme Internet et ne remplaçait pas les protocoles réseau. Il remplissait une autre fonction : rendre le transfert de fichiers possible entre des systèmes reliés par une ligne série ou, plus tard, par un service réseau.

Cette histoire rappelle que connectivité et interopérabilité ne se confondent pas. Un signal de porteuse peut relier deux terminaux sans rendre leurs fichiers compatibles ; un contrôle de paquet peut détecter certaines altérations sans authentifier l’émetteur ; une spécification commune rend l’échange possible sans garantir que chaque programme adopte toutes les options. Kermit a rendu ces interfaces explicites et réalisables.

Sources