2. Quelques problèmes de conception
2A. Hypothèse de base
La fonction du processus Telnet est de faire en sorte qu'un terminal situé sur le site de l'utilisateur apparaisse, à travers le réseau, comme logiquement équivalent à un terminal « directement » raccordé au site serveur. Cette fonction de base a un certain nombre d'implications.
i) L'utilisateur devrait pouvoir provoquer la génération de tous les codes qu'un terminal du système serveur peut générer. En ce qui concerne le Network Information Center et quelques autres sites, il semblerait raisonnable d'exiger des conventions de frappe telles que l'utilisateur puisse générer les 128 codes de caractères ASCII en entrée du réseau. D'autres sites, dotés de codes de caractères différents, peuvent exiger qu'un processus Telnet fournisse ces codes au réseau.
ii) L'utilisateur devrait pouvoir s'échapper (escape) vers son système local, ou s'échapper du processus serveur vers le système serveur.
iii) Les Telnet des systèmes ligne par ligne (line-at-a-time) devraient pouvoir fonctionner avec les systèmes caractère par caractère (character-at-a-time) et ligne par ligne, et les Telnet des systèmes caractère par caractère devraient pouvoir fonctionner avec les systèmes ligne par ligne et caractère par caractère.
2B. Contrôle de l'écho
Nous employons le terme contrôle de l'écho (echo control) plutôt que les termes half duplex ou full duplex, car la connexion Telnet est en réalité full duplex en ce qui concerne les transmissions réseau. Trois cas de terminal doivent être envisagés.
- Cas 1 - Caractère par caractère, site serveur en écho
- Cas 2 - Caractère par caractère, site utilisateur en écho
- Cas 3 - Ligne par ligne, site utilisateur en écho
Certains sites serveurs peuvent être capables de fonctionner selon les trois cas, et une convention est nécessaire pour fixer le mode. À strictement parler, les caractères qui sont renvoyés en écho pour telles ou telles touches frappées ne concernent pas le site serveur, même si l'on aimerait essayer de minimiser les différences dans la copie telle qu'elle apparaît à l'utilisateur.
2C. Caractères de contrôle de format
Les caractères de contrôle de format, à savoir la tabulation horizontale (HT), la tabulation verticale (VT), le saut de page (FF), le saut de ligne (LF) et le retour chariot (CR), doivent être traités de manière cohérente pour les cas 2 et 3 ci-dessus. Pour le cas 1 ci-dessus, la situation est plus simple.
2D. Frontières de messages réseau
Le protocole NCP à NCP a été spécifié dans le but de rendre les frontières de messages réseau (network message boundaries) invisibles aux processus utilisateurs. Il serait bon que cet objectif puisse être maintenu, mais cela peut être difficile avec certains systèmes ligne par ligne.
2E. Une convention de mise en œuvre
Si nous supposons que le flot de caractères reçu par le site serveur en provenance d'un processus Telnet est introduit, dans le moniteur du serveur, au point où est introduite l'entrée de caractères des terminaux « directement » raccordés, et si la sortie du processus serveur est introduite au point du moniteur où est introduite la sortie normale de caractères, alors les conventions permettant de résoudre les problèmes ci-dessus s'établissent le plus simplement. Le NCP du serveur reçoit son entrée au point où est obtenue la sortie normale de caractères du moniteur. En d'autres termes, le processus serveur obtiendrait son entrée depuis les tampons de caractères du moniteur du serveur et enverrait sa sortie vers ces tampons, plutôt que d'obtenir son entrée directement depuis les tampons NCP ou de sortir vers les tampons NCP.
Le processus Telnet, quant à lui, obtiendrait et enverrait les flots de caractères directement depuis ou vers son NCP local.
Il existe d'autres situations où les processus utilisateurs des deux extrémités communiquent directement avec le NCP. Par conséquent, nous recommanderions que les deux modes de connexion (processus utilisateur-moniteur-NCP, ou processus utilisateur-NCP) soient disponibles pour la communication entre le NCP et un processus utilisateur. Ces modes seraient définis, sous contrôle du programme, par le processus utilisateur. La convention réseau initiale, pendant la procédure de connexion et jusqu'à ce que le processus serveur y déroge, serait d'obtenir les caractères du moniteur et de lui envoyer les caractères. Le NCP du serveur communique également avec le moniteur. Ce schéma est illustré par la figure 1.
La motivation d'une telle flexibilité ressortira plus clairement de la discussion ci-dessous.