Introduction

Le protocole prévoit un mécanisme d'allocation de tampons. Ce mécanisme est assez compliqué, car il nécessite deux mécanismes parallèles. Il n'est pas évident que les deux soient nécessaires. En fait, il est suggéré que ce mécanisme pourrait probablement être remplacé par une conception légèrement différente de la demande de message suivant (RFNM). Or le RFNM est renvoyé par l'IMP récepteur après que le message a été reconstitué et que le premier paquet a été transmis à l'hôte. Rien ne garantit que le message entier ait été accepté et correctement reçu par l'hôte ; de plus, la conception de l'interface hôte/IMP permet à l'hôte de cesser d'accepter des données de l'IMP pendant une durée quelconque ; comme la liaison a déjà été débloquée par l'envoi du RFNM, un autre message peut être transmis par l'hôte étranger émetteur, ce qui encombrera la mémoire de l'IMP. D'autre part, il est probable que l'hôte est habituellement capable d'accepter les données de l'IMP à un débit supérieur à celui de leur transmission sur le réseau, par exemple 200k bits/s ; le temps nécessaire pour transmettre un message complet de l'IMP à l'hôte serait donc d'environ 1/20 de seconde, soit 10 fois moins que le délai moyen de transmission d'un message sur le réseau. Cela indique qu'envoyer un RFNM après la réception d'un message complet par l'hôte n'augmenterait pas sensiblement le temps de réponse du réseau.

Dans ce cas, rien n'empêche que le RFNM soit déclenché par l'hôte récepteur comme accusé de réception correcte du message (ACK) et prenne la forme d'un message hôte/IMP ou d'un message de commande de contrôle. Ce RFNM pourrait avoir les deux formes

         ACK  (CONTINUE)
or       ACK  (CEASE)

Cela permettrait d'ajouter au message une redondance de détection d'erreur, comme des bits de somme de contrôle ainsi que le propose [DELO 69]. Dans la conception actuelle, rien ne garantit qu'un ou plusieurs bits du texte n'ont pas été altérés, par exemple par une interférence ou par un défaut de l'une des interfaces hôte/IMP. Cela pourrait avoir des conséquences importantes, par exemple si le texte sert à mettre à jour une base de données centralisée. De plus, si l'utilisateur a un moyen de détecter l'erreur mais aucun de la corriger, il n'a aucun moyen de demander la retransmission du message, lequel a probablement été rejeté à l'extrémité émettrice à la réception du RFNM. En fait, il semble que ce ne soit pas à l'utilisateur de détecter les erreurs dans son texte, mais au NCP : le processus utilisateur doit, autant que possible, agir comme s'il parlait à un autre processus local. Ainsi, une troisième sorte de RFNM envoyée par le NCP pourrait être :

            NAK(REPEAT)

La répétition serait également déclenchée en cas d'absence de réponse.

Nous voyons donc qu'il vaut la peine d'apporter ces légères modifications, qui permettraient d'utiliser entre l'hôte émetteur et l'hôte récepteur une procédure de transmission point à point très simple, assurant le contrôle des données transmises de bout en bout.

Il pourrait aussi remplacer le mécanisme d'allocation de mémoire : ACK (CONTINUE) ne serait envoyé que s'il y a de la place pour un nouveau message sur cette connexion et/ou ACK (CEASE) serait envoyé s'il n'y a plus de place ; cela correspond au WABT des procédures de transmission classiques [USAS69] ; la transmission pourrait être reprise par un ACK (CONTINUE) ou un RESUME venant de l'extrémité réceptrice. Le processus utilisateur n'est pas du tout mêlé à cette allocation de mémoire, qui est une fonction du système (ou du NCP) : il ne voit qu'une vitesse de transmission globale variable de ses données sur une connexion. Les programmes de l'IMP se chargent du routage des données selon la nature distribuée du réseau, et ni l'utilisateur ni le système (ou le NCP) ne s'en préoccupe. D'autres améliorations du protocole pourront être trouvées après l'avoir expérimenté.

Enfin, notons que cette solution n'immobilise pas la mémoire de l'IMP plus longtemps que la solution actuelle, car ce n'est pas l'IMP qui doit répéter un message, mais l'hôte émetteur.

DELO 69 DELOCHE G.  Implementation of the Host-Host Software
        Procedures in GORDO Network Working Group RFC #11 Aug 1969

USAS 69 Proposed USA standard data communication control procedures
        for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178

Note : Ce RFC a été mis sous forme lisible par machine pour être intégré aux archives RFC en ligne par Kai Henningsen 6/97.