Résumé

  • Le drapeau SO de la RFC 916 indiquait qu’un paquet transportait exactement un octet ; le champ LENGTH, devenu redondant comme compteur, contenait alors le caractère et la somme de contrôle d’en-tête le protégeait.
  • La même position physique annonçait le Maximum Data Length dans un SYN, comptait les données dans un paquet normal ou portait les données avec SO. Son sens venait des drapeaux validés et de l’état de connexion.
  • Les numéros de séquence et d’acquittement tenaient chacun sur un bit parce qu’un seul paquet au plus attendait une réponse dans chaque direction. L’économie et la restriction étaient inséparables.

Publiée en octobre 1984, la RFC 916 proposait le Reliable Asynchronous Transfer Protocol, RATP. Elle visait surtout une liaison point à point RS-232, asynchrone et bidirectionnelle, entre petits ordinateurs, modems ou équipements recevant des commandes. La fiche du RFC Editor classe aujourd’hui le texte comme Historic. Ce statut ne mesure ni son adoption passée ni la précision de son mécanisme.

L’ordre des priorités était déclaré : fiabilité d’abord, simplicité d’implémentation ensuite. La gestion dynamique d’une fenêtre et la présence de plusieurs paquets en attente furent écartées. Lorsqu’une fermeture distante survenait, les données encore en file étaient abandonnées, ce qui supprimait, selon le texte, deux états. RATP ne cherchait pas à reproduire tout TCP sur un câble plus petit ; il achetait un automate plus étroit par des limites explicites.

Sept octets pour une seule touche

L’en-tête normal comptait quatre octets : un leader de synchronisation 01 en hexadécimal, un octet de contrôle, un octet de longueur et une somme de contrôle d’en-tête. Les données ordinaires venaient ensuite, suivies de leur somme de contrôle sur seize bits.

Dans une session interactive, attendre plusieurs caractères pour amortir cet en-tête pouvait dégrader l’usage. Mais envoyer immédiatement un caractère dans la forme ordinaire coûtait sept octets : quatre d’en-tête, un de donnée et deux pour sa somme de contrôle.

Le drapeau SO, Single Octet, traitait précisément ce cas. S’il était positionné tandis que SYN, RST et FIN restaient à zéro, le récepteur savait que le paquet contenait un seul octet de données. Inscrire par ailleurs la longueur un aurait répété cette information. La RFC plaçait donc le caractère dans l’octet normalement appelé LENGTH, supprimait la partie données et laissait la somme de contrôle de l’en-tête couvrir le caractère. Elle présentait le passage de sept à quatre octets comme un gain d’efficacité de 40 %.

Ce n’était pas une compression générale. Le protocole retirait trois octets dont les fonctions étaient déjà satisfaites : le drapeau disait la longueur, la position de longueur portait le caractère, et la somme de contrôle d’en-tête vérifiait ce caractère. Deux octets ne pouvaient pas emprunter le même chemin. Un paquet SO n’échappait pas non plus à l’état de connexion ni à l’acquittement.

Un octet, trois autorisations de lecture

Dans un paquet SYN, la troisième position contenait le Maximum Data Length, ou MDL. Celui qui envoyait le SYN annonçait la plus grande quantité de données qu’il accepterait dans un paquet reçu. Pendant l’ouverture en trois temps, chaque extrémité déclarait donc sa propre limite.

Après l’établissement, lorsque SYN, RST et FIN étaient absents, la position devenait LENGTH. Avec SO à zéro, elle comptait les octets qui suivaient, entre zéro et le MDL annoncé par le pair. Avec SO à un, elle n’était plus un compteur : elle était l’unique octet de données.

La valeur ne pouvait pas décider seule de son interprétation. Il fallait reconnaître le leader, valider la somme de contrôle, lire les drapeaux et accepter le paquet dans l’état courant. Une capture qui garde la valeur mais perd l’époque de connexion ne conserve qu’une inscription ambiguë.

Cette grammaire rendait le MDL exécutoire. Si un en-tête valide déclarait une longueur ordinaire supérieure au MDL du récepteur, la RFC y voyait une violation du protocole ou, moins probablement, une erreur de longueur non détectée. Le récepteur réinitialisait la connexion. Le MDL n’était donc pas un commentaire sur la mémoire disponible ; c’était une frontière d’admission locale assortie d’un effet commun.

Une extrémité pouvait annoncer zéro si elle ne souhaitait recevoir aucune donnée, permettant une circulation à sens unique. Les deux ne pouvaient évidemment pas choisir zéro si elles voulaient échanger. La spécification définissait la représentation et la sanction. La machine décidait elle-même de sa capacité.

Le bit unique dépendait d’une attente unique

Les champs SN et AN, séquence et acquittement, n’occupaient chacun qu’un bit. Cette brièveté reposait sur une règle plus vaste : dans une direction donnée, un seul paquet exigeant une réponse pouvait être en cours d’envoi ou d’acquittement.

Le récepteur comparait SN à la valeur attendue modulo deux. Une autre valeur désignait le duplicata d’un paquet déjà reçu, probablement retransmis parce que l’acquittement précédent avait disparu. Le duplicata était écarté et l’acquittement utile pouvait être renvoyé. L’émetteur, lorsqu’il recevait le bon AN, supprimait son paquet de la file de retransmission et alternait le bit.

Les deux sens restaient autonomes. Une extrémité dont le dernier paquet avait été acquitté pouvait émettre, même si l’autre n’avait rien à lui transmettre. Lorsque les deux fonctions coïncidaient, données et acquittement partageaient un paquet. Un acquittement pur ne demandait pas d’acquittement supplémentaire.

L’absence de fenêtre était à la fois le prix et la source de la simplicité. Sur une liaison où beaucoup de données pourraient voyager pendant un aller-retour, attendre après chaque paquet limitait le débit. Pour un petit équipement relié par un circuit lent et interactif, elle limitait aussi les tampons, les états et les ambiguïtés de duplicata. On ne peut conserver le bit sans conserver l’invariant qui le rend suffisant.

Le récepteur fixait la taille qu’il pouvait assumer

Le MDL ne dépassait pas 255. Le plus grand paquet ordinaire atteignait donc 261 octets, en comptant la synchronisation, l’en-tête, la somme de contrôle des données et 255 octets utiles. La RFC en tirait une propriété d’implémentation : aucun tampon de paquet reçu ne devait dépasser cette borne.

La valeur effective restait locale. Le système d’exploitation, le pilote, la mémoire, la vitesse et les caractères de contrôle éventuellement injectés sur la liaison pouvaient justifier un maximum inférieur. La RFC conseillait notamment de réduire ce nombre lorsqu’une longue rafale risquait de déclencher le contrôle de flux externe.

Le protocole formait ainsi une couche commune mince mais stricte. Il disait comment annoncer la limite et quoi faire si elle était dépassée. Il ne décidait ni de la mémoire à acheter ni de l’application à faire tourner. Le pair pouvait respecter la limite ou provoquer la rupture ; aucune autorité continue n’attribuait les capacités.

Fin de paquet et fin de dossier n’étaient pas synonymes

RATP utilisait un motif de début, mais aucun délimiteur final. Des motifs quelconques pouvaient apparaître dans les données. Une fois l’en-tête validé, sa longueur interprétée indiquait combien d’octets restaient dans le paquet.

Le protocole prévoyait pourtant que l’objet de niveau supérieur puisse dépasser le MDL. Le drapeau EOR signalait que le record supérieur s’achevait dans ce paquet. C’était au niveau supérieur de le positionner lors de la fragmentation. Un paquet parfaitement reçu pouvait donc rester un fragment d’un objet incomplet.

Les preuves s’arrêtent à leur couche. La somme de contrôle soutient la validité limitée de l’en-tête. L’acquittement montre qu’un état RATP a accepté le paquet. EOR aide à reconstituer le record. Aucun de ces faits ne prouve que l’application a obéi, que la commande était autorisée ou que l’effet attendu s’est produit.

Le bruit relevait d’un autre contrat

Une liaison RS-232 délimitait des caractères, pas des paquets RATP. Le récepteur cherchait donc 01, lisait les trois octets suivants et contrôlait leur somme. En cas d’échec, ces trois octets redevenaient de nouvelles entrées pour la recherche. Un faux début ne permettait pas de sauter une longueur arbitraire.

La RFC 1055 documenta plus tard le compromis différent de SLIP : délimiteurs et échappement autour de datagrammes IP, mais pas de champ de type, pas de maximum défini par la convention de base et pas de correction d’erreur sur la liaison. Les RFC 1661 et RFC 1662 décrivirent ensuite PPP avec multiplexage de protocoles, LCP, paramètres négociables, fanions, transparence et FCS. Il s’agit de comparaisons, pas d’une généalogie prouvée.

La RFC 793 fournit la comparaison contemporaine citée par la RFC 916 lorsqu’elle refuse la fenêtre dynamique. TCP possédait un contrat de flot et d’interconnexion beaucoup plus large. RATP réunissait trame, fiabilité et négociation sur une seule liaison point à point. Employer des mots voisins ne donnait pas aux deux protocoles la même surface opérationnelle.

Ces sources ne mesurent pas le déploiement de RATP et n’établissent aucun incident actuel. Une somme de contrôle n’est ni une signature ni une permission. La leçon historique est plus précise : quatre octets suffisaient parce que les extrémités partageaient déjà un état strict sur la longueur, la capacité et le seul paquet encore en attente.