Introduction
Page 3. Supprimer le marquage. À la place, transformer tous les messages ordinaires en deux messages : le premier ne contenant que l'en-tête et indiquant que les données suivent dans le second (le suivant). Faire cela aussi bien de l'hôte source vers son IMP que de l'IMP de destination vers son hôte. Ainsi, il n'est plus nécessaire de chercher le début des données. Une fois cet ajustement effectué, une simplification supplémentaire devient possible. Si la longueur maximale d'un message est un multiple commun des tailles de mot de tous les ordinateurs du réseau (peut-être 2880*2 bits), les messages successifs d'un fichier long peuvent être abandonnés sur place sans décalage.
Page 4. Les messages de contrôle doivent être envoyés vers et depuis le socket de contrôle — et non sur la liaison de contrôle. Le concept de liaison de contrôle crée un cas particulier énorme et inutile.
Page 5. L'attribution permanente de sockets à certaines ressources du réseau devrait être encouragée, et un répertoire des associations socket/ressource devrait être disponible quelque part dans le réseau, peut-être sous forme de document papier sur chaque site.
Page 6. Les liaisons n'ont d'autre but hôte-hôte que d'identifier une connexion, afin que les numéros de socket n'aient pas à figurer dans tous les messages, et de simplifier les recherches dans les tables des NCP. Toutefois, comme il peut exister 512 liaisons* portant le même numéro, les liaisons n'aident pas beaucoup aux recherches dans les tables. De plus, trouver la prochaine liaison disponible vers une destination donnée est très pénible. Par conséquent, je propose de limiter le nombre de liaisons à un total de n (où n = 32, 64 ou 256, ou quelque autre bon nombre) pour toutes les destinations. Autrement dit, une liaison donnée n'est utilisée que vers une seule destination à la fois (en réalité depuis une seule destination à la fois, puisque c'est le récepteur qui choisit la liaison à utiliser pour une connexion). Cette modification rend le choix de la prochaine liaison disponible très simple et, je le sens, constitue un changement qui vaut la peine, ne serait-ce que pour cette raison. La question de simplifier les recherches dans les tables est un peu plus complexe. Il est facile d'utiliser directement la liaison comme index dans les tables de la partie réception du NCP, puisque c'est le récepteur qui choisit la liaison. Mais une table de hachage, une recherche linéaire ou autre chose reste nécessaire dans la partie émission du NCP. Cela aussi peut être corrigé par les changements suivants. Ajouter à STR une pseudo-liaison choisie par l'émetteur. Cette liaison est envoyée dans tous les messages non de contrôle, dans les 8 bits à droite de la liaison dans l'en-tête. L'IMP doit conserver ces bits et les renvoyer avec les RFNM, et le récepteur doit utiliser la pseudo-liaison au lieu de la liaison dans RET et INR. La mémoire supplémentaire nécessaire pour stocker la pseudo-liaison dans les tables de réception du NCP (indexées par liaison) et la liaison dans les tables d'émission du NCP (indexées par pseudo-liaison) est certainement inférieure à la surcharge nécessaire pour maintenir des tables associatives.
*Un numéro de destination fait 9 bits.
Page 8. Le mécanisme d'allocation semble très peu commode à utiliser pour la partie réception du NCP. Le récepteur souhaite que l'allocation soit consommée en unités de la taille de tampon du récepteur, et non en unités de messages de l'émetteur, dont la longueur peut être variable. Sinon, le récepteur a un problème de compactage de mémoire.
Page 9. Les nouveaux messages irréguliers destinés à faire fonctionner le mécanisme de « cease » sont inutiles, je pense. L'émetteur peut suivre (probablement avec un compteur d'un bit) les ALL et les GVB et ignorer les GVB 0 pour lesquels des ALL de reprise sont déjà arrivés. Ainsi le récepteur n'a pas besoin de savoir si le cease a été envoyé ou non.
Page 15. Si j'implémentais un NCP, tous les ERR seraient traités comme des NOP. En tant que mécanisme de contrôle d'erreur, ERR est compliqué et insuffisant. Qui veut déboguer un mécanisme compliqué qui ne détecte que les bogues dus au fait que le mécanisme principal n'est pas débogué. Le seul mécanisme de contrôle d'erreur que je fournirais est un accusé de réception du processus récepteur vers le processus émetteur sur chaque message. S'il n'est pas reçu pendant trop longtemps, le processus émetteur peut renvoyer le message s'il l'a conservé. Cet accusé de réception détecte les erreurs causant une perte de message aux niveaux processus/NCP, NCP/NCP, hôte/IMP, IMP/IMP, etc. Actuellement, l'interface hôte/IMP manque particulièrement de contrôles d'erreur utiles. Je ne me préoccuperais pas des types d'erreurs que les sommes de contrôle sont conçues pour détecter. Si les bits perdus et mal captés deviennent un problème, ajoutez du matériel à davantage d'interfaces ou faites en sorte que le processus récepteur n'envoie pas l'accusé de réception de processus à processus si une somme de contrôle logicielle ne se vérifie pas.
Les commentaires des pages 3 et 6 impliquent une modification du programme IMP. Je me sens un tout petit peu coupable de suggérer des changements que je n'ai plus à implémenter. Toutefois, je fais confiance à Crowther et Cosell pour, comme toujours, résister aux mauvais changements tout en en faisant de sensés. Le commentaire de la page 9 vise à éviter une modification du programme IMP.
Note: Ce RFC a été mis sous forme lisible par machine pour être intégré aux archives RFC en ligne par Luke Hollins 8/99.