Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

RFC 1: Host Software

Date de publication du RFC : Avril 1969
Auteur(s) du RFC : Steve Crocker (University California Los Angeles (UCLA))
Statut inconnu, probablement trop ancien
Première rédaction de cet article le 10 juillet 2009


Un document historique, le premier des RFC. Cette série de documents, qui forme l'ossature de la normalisation de l'Internet a désormais un peu plus de quarante ans. L'auteur de ce RFC 1, Steve Crocker, a d'ailleurs publié un excellent article dans le New York Times pour célébrer cet anniversaire, How the Internet Got Its Rules, révélant que le RFC 1 avait été écrit dans une salle de bains.

Évidemment, le temps a passé. Techniquement, le RFC 1 n'a plus beaucoup d'utilité. Mais, outre son rang dans la série, il reste une lecture fascinante pour l'ingénieur, le souvenir d'une époque où une bande d'universitaires mettaient en place les fondations de ce qui allait devenir l'Internet.

Pour l'anecdote, notons que le dernier RFC écrit par Steve Crocker, le RFC 4986 sur DNSSEC, a été publié en août 2007, trente-huit ans après le premier. (Ne pas confondre avec les RFC, plus récents, de son frère Dave Crocker).

Le prédécesseur de l'Internet, l'Arpanet, existait déjà lorsque le RFC a été écrit. Suivant une tradition courante sur l'Internet, la documentation suit le déploiement. Ce réseau était composé de deux sortes de machines bien distinctes, les IMP (on dirait aujourd'hui les routeurs) et les machines terminales, les hosts. Les IMP étant fermés et contrôlés par une entreprise privée, BB&N, les étudiants comme Crocker étaient laissés avec le host software. Le RFC 1, contrairement aux RFC récents, méritait bien son nom d'« Appel à commentaires ». Il contient autant de questions que de réponses.

Donc, à l'époque, les données circulaient dans des messages (les termes comme paquet n'existaient pas encore). L'en-tête de ces messages faisait seulement 16 bits dont cinq (!) étaient réservés à l'adresse de destination. Il ne pouvait donc y avoir que 32 machines sur le premier Arpanet (IPv4 passera à 32 bits en 1981 et IPv6 à 128 en 1995). Parmi les autres champs de l'en-tête, un bit Trace qui indiquait à l'IMP d'envoyer une copie du message au Network Measurement Center, pour déboguage...

Plus étonnant, l'en-tête comporte un champ nommé Link qui indique une connexion entre deux machines. Ces connexions n'étaient pas établies ou coupées à la demande mais fixes. (Le fait que les ressources soient allouées statiquement était courant dans les systèmes d'exploitation de l'époque.) Les connexions étaient au nombre de 32, maximum, et le RFC se demande à juste titre pourquoi le champ Link fait huit bits (il semble que personne ne se souvienne de la raison).

Après cette description très sommaire du logiciel, le RFC liste les usages prévus, et les exigences que doit suivre ce logiciel. Ainsi, le principal usage envisagé est la connexion à distance (dans le style du futur telnet).

La question de la latence du réseau revient souvent dans le RFC. Avec le temps que prend un message pour aller et venir (environ une seconde à l'époque), des problèmes comme l'écho des caractères tapés localement allaient être pénibles.

Si certains problèmes ont disparu avec le temps (ou bien ont diminué d'acuité comme la question de la latence), d'autres restent d'actualité. Ainsi, le RFC 1 insiste sur le fait que la machine doit mettre en œuvre de la correction d'erreurs, même si BB&N jure que l'IMP le fait déjà (« nous les croyons mais nous vérifions »). Une question qui préfigure les futurs débats sur le principe de bout en bout.

Si les connexions entre machines sont permanentes, à bord de chaque machine, les programmes n'ont pas d'accès au lien avant de l'avoir demandé explicitement. Chaque système d'exploitation d'une machine Arpanet doit donc fournir des fonctions de gestion de la connexion (et, bien sûr, d'envoi et de réception des données via la connexion). La fonction doit indiquer si la connexion sera plutôt utilisée pour l'accès à distance ou plutôt pour le transfert de fichiers (auquel cas la gestion des tampons est différente et il n'y a pas d'échappement des caractères de contrôle).

L'accès à distance étant de loin la principale application envisagée, et le problème étant très riche, une section entière du RFC discute des besoins particuliers de ce service. Par exemple, compte-tenu des problèmes de latence, le RFC recommande que la gestion de certains caractères comme le caractère de suppression soit effectuée localement. Mais le RFC allait plus loin en proposant un langage entier de description des terminaux, nommé DEL.


Téléchargez le RFC 1

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)