Résumé

  • ETFTP regroupait les packets dans un buffer puis dans des bursts afin qu’un accès coûteux au canal transporte beaucoup de données; le récepteur ne répondait qu’à la frontière du buffer.
  • CONTROL_RESEND nommait les packets absents et CONTROL_OK acceptait le buffer. Ces reçus, comme NULL-ACK et le plus haut numéro CONTROL consécutif, ne prouvaient ni le fichier entier, ni l’identité, ni la sécurité, ni la cause d’une perte.
  • Les chiffres de 1993 appartenaient à un montage point à point à 16 kbps. Le RFC reconnaissait en outre l’absence de validation par mot de passe et l’oubli de la sécurité dans le prototype.

La réponse n’était pas gratuite

Le chemin décrit par RFC 1986 demandait environ 1,25 seconde pour synchroniser radio et équipement cryptographique avant toute émission. La propagation satellitaire ajoutait quelque 500 millisecondes au trajet aller-retour. Dans ce monde semi-duplex, chaque échange de sens consommait du temps avant même de transporter un octet utile.

ETFTP a donc changé l’unité de contrôle. Le fichier entrait dans des buffers, découpés en blocks; chaque block devenait un packet DATA et plusieurs packets formaient un burst. LDATA marquait le dernier block d’un buffer. Le récepteur attendait cette frontière: il envoyait CONTROL_OK si tout était présent, ou CONTROL_RESEND avec le numéro du buffer et la liste exacte des numéros manquants.

Une grande séquence de données pouvait ainsi acheter un seul retournement. Mais la sémantique restait limitée. RESEND décrivait les trous visibles d’un buffer à un instant donné. OK fermait ce buffer. La fermeture du transfert complet dépendait encore de QUIT, puis de DONE.

Trois tailles, trois arbitrages

Augmenter le buffer réduisait les frontières d’acquittement, au prix de la mémoire et d’une occupation plus longue du canal. Augmenter le burst gardait l’émetteur actif, tout en risquant de saturer les files intermédiaires. Augmenter le packet réduisait la part d’en-tête, mais exposait davantage de données à chaque erreur binaire.

RFC 1986 autorisait une adaptation. Si au moins la moitié des blocks d’un buffer exigeaient une retransmission, l’implémentation réduisait d’abord de moitié la taille du packet, puis diminuait le burstsize, puis rapprochait le burstrate du tight timer observé. À 99 % de réussite sans reprise, la taille du packet pouvait remonter. CONTROL_OK proposait les nouveaux paramètres; NULL-ACK confirmait leur acceptation par l’émetteur.

Cette poignée de champs ressemble à la couche commune minimale décrite par Lu Heng: numéros de buffer et de packet, liste des absents, valeurs proposées et frontière de changement. Pourtant, un accord n’est pas encore une exécution. Seul le trafic suivant montre que les deux côtés ont adopté les valeurs au même endroit.

Une suite continue ne clôt pas le dossier

DATA et LDATA reportaient le plus haut numéro consécutif de message CONTROL reçu. Ce nombre accusait réception d’un préfixe sans trou dans l’historique de contrôle. Il ne couvrait ni les messages ultérieurs, ni les blocks de données non encore signalés, ni le contenu écrit sur disque.

Un timeout avait une portée tout aussi modeste. Le modèle utilisait un baudrate saisi, un radiodelay fourni ou estimé, et ajoutait cinq secondes après chaque nouvelle expiration. Le retard disait que l’attente n’avait pas été satisfaite; il ne distinguait pas BER, contention, débordement de file, erreur de mesure ou lenteur du programme. De même, une liste RESEND ne prouvait pas que l’émetteur n’avait jamais envoyé les packets cités.

Mesurer un prototype n’est pas décrire un marché

Les tableaux portaient sur un fichier de 101 306 octets, une liaison chiffrée de 16 kbps, un radiodelay de deux secondes et plusieurs combinaisons de buffer, packet et burst. Les radios étaient reliées par câble coaxial pour constituer un lien dit « clean » à 10e-5 de BER. La meilleure valeur affichée, 10 432 bps, correspondait à un buffer de 131 072 octets, des packets de 2 048 octets et seize packets par burst; la durée incluait connexion, réparation et fermeture.

Cette observation ne prouvait ni diffusion générale, ni multicast, ni équité en canal partagé, ni supériorité face à des systèmes modernes. Le texte précise d’ailleurs que le p-persistence maximal choisi pour deux utilisateurs ne convenait pas à un canal partagé. Il laisse aussi une tension documentaire: la plage réglable annoncée est de 16 à 1 448 octets utiles, alors que les essais mentionnent 2 048. Une analyse honnête conserve cette contradiction.

Enfin, aucune mécanique de reçu ne réparait la sécurité. ETFTP ne validait pas utilisateur et mot de passe, répétait les problèmes de TFTP et utilisait un serveur appartenant à root avec setuid root. Le RFC dit que la question avait été négligée. Checksum, ports, connection ID et séquences corrélaient des messages; ils n’authentifiaient personne.

L’apport historique d’ETFTP tient donc à une comptabilité précise: dépenser moins de retournements, transmettre longtemps dans un sens, puis demander seulement les trous. Cette précision oblige à lire les reçus sans les gonfler. Un OK de buffer reste un OK de buffer; achèvement, identité, cause et sécurité gardent leurs propres exigences de preuve.

Sources