Protocolli di login remoto: TELNET

Generalità Telnet è un'applicazione standard dell'Internet ed è disponibile nella maggior parte delle implementazioni del TCP/IP, indipendentemente dal sistema operativo host. Si tratta di un semplice protocollo di login remoto, implementato secondo un modello di tipo client-server, che permette ad un utente attestato ad una certa macchina di stabilire una connessione TCP con un server di login che si trova su un'altra macchina. Subito dopo Telnet rilancia i caratteri battuti sulla tastiera dell'utente direttamente al calcolatore remoto come se essi fossero battuti su una tastiera direttamente connessa ad esso. Inoltre Telnet ritorna l'output della macchina remota indietro fino allo schermo dell'utente. Il servizio è definito trasparente perchè dà l'apparenza che la tastiera e lo schermo dell'utente siano attaccati direttamente alla macchina remota. Sebbene Telnet non sia molto sofisticato se paragonato ad altri protocolli di terminale remoto, esso risulta tuttavia largamente diffuso. Di solito, il codice client di Telnet permette all'utente di specificare la macchina remota a cui ci si vuole connettere dando il suo nome di dominio oppure il suo indirizzo IP. Telnet offre tre servizi di base. Per prima cosa, definisce un network virtual terminal (terminale virtuale di rete) che fornisce una interfaccia standard verso i sistemi remoti. Il programma client non può essere istruito sui dettagli di tutti i possibili sistemi remoti, così esso è realizzato per usare l'interfaccia standard. In secondo luogo, Telnet include un meccanismo che permette ai due moduli client e server di negoziare delle opzioni, e fornisce un insieme di opzioni standard (ad esempio, una delle opzioni controlla se i dati trasmessi attraverso la connessione debbano essere rappresentati mediante il set standard di caratteri ASCII a 7 bit oppure mediante un set di caratteri ad 8 bit). Infine, Telnet tratta simmetricamente entrambi gli estremi della connessione. In particolare, Telnet non obbliga che l'input del client provenga da una tastiera, e nemmeno che l'output di tale client sia costituito per forza da uno schermo. In questa maniera, Telnet permette ad un qualsiasi programma di diventare utente del client. Inoltre, entrambe le parti possono negoziare le opzioni. La seguente figura illustra come dei programmi applicativi implementano un client e server di Telnet: Quando un utente invoca Telnet, un determinato programma applicativo sulla macchina dell'utente diviene il client. Esso stabilisce una connessione TCP con il server, tramite la quale comunica con questo. Una volta stabilita la connessione, il client legge i caratteri battuti sulla tastiera dell'utente e li trasmette al server, e nel frattempo legge i caratteri che il server gli ritorna indietro per visualizzarli sullo schermo dell'utente. Il server deve accettare la richiesta di connessione dal client, dopodichè deve rilanciare i dati ricevuti tramite questa connessione al sistema operativo della macchina su cui si trova. Nella pratica, il server è più complesso di quanto mostrato in figura, poichè esso deve gestire connessioni multiple concorrenti. Di solito, un processo padre aspetta su una determinata porta una richiesta di connessione e, quando questa arriva, crea un processo figlio che gestisce tale connessione. Perciò, il server Telnet mostrato in figura rappresenta il processo figlio che gestisce una particolare connessione. La figura dunque non mostra il processo padre che ascolta sul socket in attesa di nuove richieste, nè mostra altri processi figli che concorrenzialmente gestiscono ulteriori connessioni. Si adopera il termine pseudoterminale per descrivere il punto di ingresso (entry point) del sistema operativo che permette ad un programma quale il server Telnet di immettere caratteri nel sistema operativo della macchina remota facendo credere a quest'ultimo che essi provengano da una tastiera. Sarebbe impossibile realizzare un server Telnet senza che il sistema operativo fornisca una tale possibilità. Se il sistema supporta un dispositivo di pseudoterminale, il server Telnet può essere implementato mediante programmi applicativi. Nel server, ogni processo figlio funge da collegamento tra il flusso di dati provenienti dalla connessione TCP ed un particolare dispositivo di pseudoterminale. Fare in modo che il server Telnet sia un programma a livello applicativo comporta sia vantaggi che svantaggi. Il vantaggio più ovvio è che risulta più semplice la modifica ed il controllo del server rispetto al caso in cui il codice sia contenuto nel sistema operativo. Lo svantaggio è chiaramente l'inefficienza, poichè ciascun carattere deve viaggiare dalla tastiera d'utente, attraverso il sistema operativo, fino al programma client, dal programma client tornare al sistema operativo e, attraverso la connessione di rete, arrivare alla macchina remota. Qui, i dati devono arrivare, attraverso il sistema operativo, fino al programma applicativo server, e da quest'ultimo di nuovo indietro al sistema operativo in un dispositivo di pseudoterminale. Alla fine, il sistema operativo remoto invia il carattere al programma applicativo che l'utente sta facendo correre. Si capisce che, nel frattempo, l'output (compresi i caratteri di echo se tale opzione è stata selezionata) viaggia a ritroso dal server al client lungo lo stesso percorso. Adattamento delle eterogeneità Affinchè Telnet possa interoperare tra il maggior numero possibile di sistemi, è necessario adattare le particolarità di calcolatori e sistemi operativi eterogenei. Per esempio, alcuni sistemi prevedono che le linee di testo siano chiuse dal carattere ASCII carriage control (CR). Altri richiedono il carattere linefeed (LF). Altri ancora richiedono la sequenza dei due caratteri CR-LF. Inoltre, la maggior parte dei sistemi interattivi fornisce all'utente il modo di immettere una chiave che interrompe un processo in esecuzione, ma il particolare carattere usato per tale scopo varia da sistema a sistema (alcuni usano Control-C, mentre altri adoperano Escape). Per adattare le eterogeneità, Telnet definisce il modo in cui i dati e le sequenze di comando devono essere trasmesse attraverso la rete. La definizione è nota come network virtual terminal (NVT). Come illustrato dalla figura sopra, il codice client traduce i caratteri e le sequenze di comando dal formato del terminale d'utente al formato NVT e li trasmette al server. Il codice server traduce i dati e i comandi ricevuti dal formato NVT al formato richiesto dal sistema remoto (quello in cui il server si trova). Per il percorso inverso, il server traduce dal formato della macchina remota al formato NVT, mentre il client traduce dal formato NVT a quello della macchina locale. La definizione del formato NVT è estremamente precisa. Ogni comunicazione coinvolge unità informative (byte) ciascuna formata da 8 bit. All'avvio, per default, NVT adopera la rappresentazione standard USASCII a 7 bit per i dati e riserva per le sequenze di comando i byte col bit di ordine massimo settato ad 1. Il set di caratteri USASCII include 95 caratteri stampabili e 33 caratteri di controllo. Passaggio di comandi per controllare la parte remota Abbiamo già accennato al fatto che molti sistemi forniscono un meccanismo che permette agli utenti di terminare un programma in esecuzione. Di solito, il sistema operativo accoppia tale meccanismo ad un particolare tasto o sequenza di caratteri. Ad esempio, a meno che l'utente non specifichi diversamente, molti sistemi Unix riservano al carattere generato dalla sequenza Control-C la funzione di interruzione. Digitando Control-C si costringe Unix a terminare il programma in esecuzione; il programma non riceve Control-C come input. Il sistema inoltre può riservare altri caratteri o sequenze di caratteri per altre funzioni di controllo. NVT di Telnet adatta le funzioni di controllo definendo come esse devono essere passate dal client al server. Dal punto di vista concettuale, si immagina che NVT possa accettare immissioni di caratteri da una tastiera in grado di generare più dei 128 possibili caratteri. Si suppone cioè che la tastiera dell'utente abbia tasti virtuali (immaginari) che corrispondono alle funzioni tipicamente usate per controllare i processi. Ad esempio, NVT definisce un tasto concettuale di "interruzione" ("interrupt") che serve a richiedere la terminazione di un programma. Nella pratica, la maggior parte delle tastiere non fornisce tasti in più per i comandi. Tuttavia, certi sistemi operativi o interpreti di comandi presentano una varietà di modi per generarli. Abbiamo già menzionato la tecnica più comune: accoppiare un determinato carattere ASCII ad una funzione di controllo cosicchè, quando l'utente preme il tasto, il sistema operativo effettua l'azione appropriata invece di accettare il carattere come input. I progettisti dell'NVT hanno scelto di tenere separati i comandi dal normale set di caratteri ASCII per due ragioni. Per prima cosa, definire separatamente le funzioni di controllo significa conferire a Telnet una maggiore flessibilità. Esso può infatti trasferire tutte le possibili sequenze di caratteri ASCII tra il client ed il server così come tutte le possibili funzioni di controllo. Inoltre, tenendo separati i segnali dai normali dati, NVT permette al client di specificare i segnali senza ambiguità, ovvero senza confusione circa il fatto se il carattere immesso debba essere trattato come dato o come funzione di controllo. Per mandare le funzioni di controllo attraverso la connessione TCP, Telnet le codifica adoperando una cosiddetta sequenza di escape. Una sequenza di escape usa un ottetto riservato per indicare che è in arrivo un ottetto in cui è codificato un comando. In Telnet, l'ottetto riservato che apre una sequenza di escape è noto come l'ottetto interpret as command (IAC). I segnali generati dai tasti concettuali di una tastiera NVT corrispondono ciascuno ad un comando. Ad esempio, per richiedere che il server interrompa il programma in esecuzione, il client deve inviare la sequenza di due ottetti IAC IP (255 seguito da 244). Comandi addizionali permettono al client ed al server di negoziare il set di opzioni da usare e di sincronizzare la comunicazione. Facciamo notare che la codifica NVT di tutti i caratteri stampabili e di controllo, qualora sia in vigore il comportamento di default, coincide con la codifica standard ASCII a 7 bit, la quale comporta una corrispondenza di tali caratteri con i primi 128 numeri naturali (da 0 a 127), e conseguentemente il valore nullo del bit pesante nell'ottetto che rappresenta il dato. Poichè la codifica NVT delle funzioni di controllo prevede l'impiego di ottetti ai quali, secondo la rappresentazione binaria, corrispondono numeri naturali maggiori di 128, cioè col bit pesante settato ad 1, si evince che non può esservi confusione tra alcun dato e qualsiasi ottetto di comando, in particolare l'ottetto IAC, formato interamente da bit unitari (codifica decimale 255). Tale confusione può però verificarsi qualora sia in vigore l'opzione cosiddetta di trasmissione binaria, la quale prevede l'uso di un set di caratteri ad 8 bit, cioè di ottetti in cui il bit pesante può essere settato ad 1 anche per la codifica di dati. In tal caso, è previsto che se deve essere trasmesso un dato (ovvero un carattere) tale che l'ottetto che lo codifica è uguale all'IAC, allora tale ottetto deve essere trasmesso due volte. Come si forza il server a leggere una funzione di controllo L'invio delle funzioni di controllo assieme ai normali dati non sempre è sufficiente per garantire il risultato desiderato. Per capire il perchè, consideriamo la situazione in cui un utente vuole mandare la funzione di controllo interrupt process al server. Di solito, un tale evento è necessario quando il programma in esecuzione sulla macchina remota sta funzionando male e l'utente vuole che il server termini il programma. Per esempio, il programma potrebbe star eseguendo un loop infinito senza leggere l'input o generare alcun output. Sfortunatamente, se l'applicazione sulla macchina remota smette di leggere l'input, i buffer del sistema operativo si riempiono ed il server non potrà più scrivere dati sullo pseudoterminale. Quando ciò accade, è previsto che il server smetta di leggere i dati che provengono dalla connessione TCP, i cui buffer di conseguenza si riempiono. In una circostanza del genere, l'entità TCP sulla macchina del server notifica la situazione all'entità paritaria sulla macchina locale informandola circa la dimensione nulla della finestra di flusso, ed in seguito a tale notifica si interrompe il flusso di dati lungo la connessione. Se l'utente genera una funzione di controllo di interruzione nel momento in cui i buffer sono pieni, la funzione di controllo non raggiungerà mai il server. Ovvero, il client può senz'altro generare la sequenza di comando IAC IP e scriverla sul proprio socket, ma poichè l'entità TCP ha interrotto la trasmissione verso l'entità paritaria remota, il server non potrà leggere la suddetta sequenza di controllo. Per risolvere il problema, Telnet adopera un segnale cosiddetto fuori-banda (out of band signaling). Il TCP implementa la segnalazione fuori banda col meccanismo di urgent data. Ogniqualvolta deve inserire una funzione di controllo all'interno del flusso di dati, il modulo client di Telnet genera un comando di SYNCH, costituito dalla sequenza "IAC (segnale utente) IAC DMARK" (per esempio, se l'utente ha generato il segnale di interrupt process premendo la combinazione Control-C sulla propria tastiera, il comando di SYNCH sarà formato dalla sequenza "IAC IP IAC DMARK"). Tale sequenza viene passata all'entità TCP sottostante contemporaneamente ad un'apposita segnalazione che forza la stessa entità TCP a trasmettere un segmento (col bit di URGENT DATA settato ad 1) che elude il controllo di flusso e giunge immediatamente all'entità TCP remota. Questa, ricevendo un così fatto segmento, segnala al modulo server di Telnet che sono arrivati dati con la massima priorità, ed è previsto che il server, in virtù di una tale segnalazione, scarichi dal buffer della connessione TCP tutti i dati che trova, continuando però ad interpretare i comandi. Di conseguenza il server, durante tale operazione, è destinato ad incontrare dapprima la sequenza di comando "IAC (segnale utente)", dalla quale capisce cosa l'utente vuole che faccia, e subito dopo la sequenza di comando "IAC DMARK", che ha il significato "torna al normale modo di processamento" Opzioni di Telnet Finora abbiamo omesso la descrizione di uno degli aspetti più complessi di Telnet: le opzioni. In Telnet, le opzioni sono negoziabili, e rendono possibile a client e server riconfigurare la loro connessione. Ad esempio, abbiamo già detto che di solito il flusso di dati è a 7 bit e gli ottetti col bit pesante settato ad 1 sono usati per passare informazioni di controllo come il comando di interrupt process. Comunque, Telnet fornisce anche un'opzione che permette a client e server di scambiarsi dati ad 8 bit (quando questo succede, l'ottetto riservato IAC deve essere raddoppiato se appare come dato). Client e server hanno bisogno di una fase di negoziazione, ed entrambi devono accettare il passaggio di dati ad 8 bit prima che un tale tipo di comunicazione sia possibile. L'area delle funzionalità delle opzioni Telnet è vasta: alcune estendono le possibilità in modo maggiore, mentre altre si occupano di dettagli meno importanti. Per esempio, il protocollo originale fu progettato per un ambiente half-duplex in cui era necessario dire all'altra parte di "andare avanti" (go ahead) prima che essa potesse trasmettere altri dati. Una delle opzioni controlla se Telnet opera in modo half-duplex o full-duplex. Un'altra opzione permette al server sulla macchina remota di determinare il tipo di terminale d'utente. Il tipo di terminale è importante per il software che genera le sequenze di posizionamento del cursore (ad esempio un editor a tutto schermo in esecuzione sulla macchina remota). La maniera in cui Telnet negozia le opzioni risulta interessante. Siccome talvolta ha senso anche per il server iniziare l'esecuzione di una particolare opzione, il protocollo prevede di permettere ad entrambe le parti di effettuare una richiesta. In tal maniera, si dice che il protocollo è simmetrico per quanto riguarda il processamento delle opzioni. Entrambe le parti inoltre rispondono ad una richiesta con un'accettazione o un rifiuto. Nella terminologia Telnet, la richiesta è WILL X, che significa permettimi di usare l'opzione X; e la risposta può essere sia DO X che DON'T X, ovvero rispettivamente ti permetto di usare l'opzione X e non ti permetto di usare l'opzione X. La simmetria consiste nel fatto che DO X richiede che il ricevente cominci ad usare l'opzione X, mentre WILL X o WON'T X significa voglio cominciare ad usare l'opzione X o non voglio cominciare ad usarla. Un altro interessante aspetto della negoziazione consiste nel fatto che entrambi i moduli Telnet devono essere in grado di eseguire una implementazione base di NVT (cioè senza alcuna opzione in vigore). Se una delle due parti tenta di negoziare un'opzione che l'altra non capisce, la parte che riceve la richiesta si limita semplicemente a declinare l'invito. In questa maniera, è possibile fare interagire versioni di moduli Telnet più recenti e sofisticate (cioè software che comprende più opzioni) con versioni meno sofisticate. Se sia il client che il server capiscono le nuove opzioni, essi potranno incrementare la qualità dell'interazione, altrimenti faranno riferimento ad uno stile meno efficiente ma comunque funzionante.

il 26/09/2005 09:58:05 77 click