2. Alcuni problemi di progettazione
2A. Assunzione di base
La funzione del processo Telnet è quella di far sì che un terminale situato nel sito dell'utente appaia, attraverso la rete, come logicamente equivalente a un terminale «direttamente» collegato al sito server. Questa funzione di base ha una serie di implicazioni.
i) L'utente dovrebbe poter provocare la generazione di tutti i codici che un terminale del sistema server può generare. Per quanto riguarda il Network Information Center e alcuni altri siti, sembrerebbe un requisito ragionevole avere convenzioni di battitura tali che l'utente possa generare tutti i 128 codici di caratteri ASCII come ingresso alla rete. Altri siti con codici di caratteri diversi possono richiedere che un processo Telnet fornisca quei codici alla rete.
ii) L'utente dovrebbe poter fare escape (escape) verso il proprio sistema locale, o fare escape dal processo server verso il sistema server.
iii) I Telnet dei sistemi riga per riga (line-at-a-time) dovrebbero poter lavorare con i sistemi carattere per carattere (character-at-a-time) e riga per riga, e i Telnet dei sistemi carattere per carattere dovrebbero poter lavorare con i sistemi riga per riga e carattere per carattere.
2B. Controllo dell'eco
Usiamo il termine controllo dell'eco (echo control) anziché i termini half duplex o full duplex, perché la connessione Telnet è in realtà full duplex per quanto riguarda le trasmissioni di rete. Devono essere considerati tre casi di terminale.
- Caso 1 - Carattere per carattere, eco dal sito server
- Caso 2 - Carattere per carattere, eco dal sito utente
- Caso 3 - Riga per riga, eco dal sito utente
Alcuni siti server potrebbero essere in grado di operare con tutti e tre i casi, ed è richiesta una convenzione per impostare la modalità. A rigore, quali caratteri vengano riportati in eco per quali tasti premuti non è di competenza del sito server, sebbene si vorrebbe cercare di minimizzare le differenze nella trascrizione così come appare all'utente.
2C. Caratteri di controllo di formato
I caratteri di controllo di formato, vale a dire la tabulazione orizzontale (HT), la tabulazione verticale (VT), l'avanzamento pagina (FF), l'avanzamento riga (LF) e il ritorno carrello (CR), devono essere trattati in modo coerente per i casi 2 e 3 sopra descritti. Per il caso 1 sopra indicato, la situazione è più semplice.
2D. Confini dei messaggi di rete
Il protocollo NCP-NCP è stato specificato con l'obiettivo di rendere i confini dei messaggi di rete (network message boundaries) invisibili ai processi utente. Sarebbe bene che questo obiettivo potesse essere mantenuto, ma potrebbe essere difficile con alcuni sistemi riga per riga.
2E. Una convenzione di implementazione
Se assumiamo che il flusso di caratteri ricevuto dal sito server da un processo Telnet venga immesso in quel punto del monitor del server dove viene immesso l'ingresso dei caratteri dei terminali «direttamente» collegati, e che l'uscita del processo server venga immessa nel punto del monitor dove viene immessa la normale uscita dei caratteri, allora le convenzioni per risolvere i problemi sopra esposti si stabiliscono più semplicemente. Il NCP del server riceve il suo ingresso nel punto dove viene ottenuta la normale uscita di caratteri del monitor. In altre parole, il processo server otterrebbe il suo ingresso dai buffer di caratteri del monitor del server e invierebbe la sua uscita a questi buffer, anziché ottenere l'ingresso direttamente dai buffer NCP o emettere verso i buffer NCP.
Il processo Telnet, d'altro canto, otterrebbe e invierebbe i flussi di caratteri direttamente da o verso il suo NCP locale.
Esistono altre situazioni in cui i processi utente alle due estremità comunicano direttamente con il NCP. Pertanto, raccomanderemmo che entrambe le modalità di connessione (processo utente-monitor-NCP, oppure processo utente-NCP) siano disponibili per la comunicazione tra il NCP e un processo utente. Queste modalità sarebbero impostate, sotto controllo di programma, dal processo utente. La convenzione di rete iniziale durante la procedura di accesso (login) e fino a quando il processo server non la modifichi sarebbe quella di ottenere i caratteri dal monitor e inviare i caratteri al monitor. Anche il NCP del server comunica con il monitor. Tale schema è illustrato nella figura 1.
La motivazione di una tale flessibilità risulterà forse più chiara dalla discussione che segue.