MokaByte Numero 14 - Dicembre 1997
TELNET 

 
di
Pietro Venanzangeli
 REALIZZAZIONE E PROGETTAZIONE DI UN SERVER TELNET

 

  

HTTP e SMPT sono i più noti e richiesti servizi di rete. Ma oltre a questi, ne esiste una serie meno conosciuta ed utilizzata soprattutto dagli addetti ai lavori, come news telnet e gofer. Quello che ci accingiamo ad analizzare è un piccolo server telnet.

Introduzione
Che cosa è veramente un server telnet ? Il server telnet, è la versione moderna (si fa per dire) , delle vecchie connessioni ai grandi mainframe. Si basa sullo stesso criterio di allora. Il telnet di per se' può essere considerato come una finestra di console remota. L'idea di base è che il mainframe (o il server) esegue il lavoro per noi. I vantaggi prodotti da questo tipo d'approccio sono in genere due : Questi concetti erano veri dieci anni fa', quando i costi per una stazione erano accessibili solo alle grandi società . Oggi con il basso costo dei PC, gli HOST e le sessioni telnet utilizzate sono diminuite di gran numero, soprattutto perché si preferisce usare Word piuttosto che il telnet.  Prima di procedere ricordo che i sorgenti di questo progetto sono disponibili qui
 

PROGETTARE UN SERVER TELNET
Prima di realizzare un qualsiasi server ci si deve porre delle domande più o meno importanti, sia per il servizio che si intende dare all'utilizzatore, sia per le specifiche che intendiamo seguire nella realizzazione del server.
Un' ipotetica lista dei punti da seguire potrebbe essere :

SICUREZZA
Uno dei punti fondamentali su cui bisogna fare, secondo me, particolarmente attenzione sia in fase di analisi che in fase di stesura del codice è la sicurezza del servizio. La sicurezza del servizio può essere a sua volta suddivisa in vari eventi:

MODIFICA IMPOSTAZIONI SERVIZIO
Una delle caratteristiche più apprezzate di un server o di un sistema operativo è quella di permette la modifica delle impostazioni e dei servizi senza dover riavviare la macchina. Secondo il mio parere, questo è uno dei vincoli fondamentali a cui si deve pensare prima della stesura di qualunque applicativo la cui esecuzione puo' durare anche mesi. Nell'ipotesi di un servizio che abbia utenti per circa ventitré ore al giorno è impossibile chiedere a chi amministra il sistema di chiudere tutto e ripartire, disconnettendo gli utenti in quel momento connessi.
Dopo questa breve introduzione al mondo dei server incominciamo ad analizzare i sorgenti allegati all'articolo. Le classi che compongono Il nostro MokaServer telnet (da ora MST) si possono dividere in tre gruppi il server vero, le eccezioni e i suoi servizi.

 
SERVER 
DESCRIZIONE
MokaServer
 Si occupa di accettare le connessioni dai vari client che vogliono accedere al servizio, si puo' considerare come la nostra porta di ascolto. 
MokaDialog
 Questa classe viene creata ogni volta che arriva una richiesta di connessione da parte di un nuovo utente. 

È eseguita in thread. 
GetTelnetLine
 E' la nostra interfaccia verso il client telnet, gestisce la sua connessione ed I possibili messaggi anomali, genera l'eccezione TException. 
ExecCommand
 Si occupa della gestione di tutte le richieste di comandi da parte dell'utente e di caricare se necessario i comandi richiesti. 

 
 
ECCEZIONI
DESCRIZIONE
TException
 Classe di eccezioni generate da GetTelnetLine, in particolare è generata alla chiusura del telnet e alla sua disconnessione. 
SERVIZI
DESCRIZIONE
LogIn
 Verifica login e passowrd per tutti i nuovi client. 
User
 Contiene tutte le informazioni sull'utente attualmente collegato. 
DynaMode
 Contiene il nostro ponte, la nostra interfaccia, per il caricamento dinamico dei dati. 
SYSTEM
 Esegue un CHECK del sistema del server. Questa classe viene caricata dinamicamente. 
PWD
 Esegue il comando PWD delle console UNIX, cioè mostra la directory corrente, nel nostro caso la directory privata. Questa classe viene caricata dinamicamente. 
DIR
 Esegue il vecchio e buon comando dir del dos. Questa classe viene caricata dinamicamente. 

Ora possiamo analizzare gli unici due punti oscuri di tutto il programma, il quale rimane ugualmente di facile lettura .

DynaMode e il caricamento delle classi
La classe DynaMode è il punto di ingresso per le classi caricate dinamicamente. Questo meccanismo ci permette di chiamare dei metodi di una classe DERIVATA da una classe "PADRE " . Questo è quello che in C++ è gestito da quell'insieme di funzioni RTTI ( Run Time Type Identification ). Per maggiori informazioni a riguardo vedi la documentazione ufficiale. Il punto più caldo e pragmatico di tutti i sorgenti potrebbe essere la seguente istruzione :

Con questa linea di codice obblighiamo la JVM ( Java Virtual Machine ) ad eseguire un GARBAGE COLLECTOR e quindi a scaricare dalla memoria tutte le classi caricate dinamicamente che possiedono zero instanze in quel momento. Questo è eseguito ogni volta che un utente richiede un comando, per permettere di cambiare o di aggiungere dei comandi anche con degli utenti collegati. ( Può essere considerato anche come un effetto sorpresa non indifferente per gli utenti che mentre sono on-line, si vedono cambiare il comando PWD da un'esecuzione all'altra ).

Hashtable per i comandi personalizzati
Per contenere tutti i comandi personalizzati di ogni utente, la mia scelta è ricaduta su una hashtable, questo perché permette un recupero dei comandi molto veloce e quindi riduce i tempi di risposta del servizio, anche se ha un grande spreco di risorse.

 

Come configurare un nuovo utente.
Ogni utente che accede al nostro MST dispone di :

Il file di configurazione degli utenti deve essere nella stessa directory da cui parte il servizio e deve essere denominato come NomeFile.psw dove NomeFile è il login dell'utente.
Le linee del file vanno impostate nel seguente modo :

        0 - password utente.
        1 - directory privata
        da 2 in poi la lista dei comandi dell'utente.

Ad esempio:
        File : Moka.psw
        [ Linea 0 ] moka
        [ Linea 1 ] C:\.
        [ Linea 2 ] DIR
        [ Linea 3 ] PWD
        [ Linea 4 ] SYSTEM

La path privata deve terminare con il carattere ' . , .  La password è case sensitive, qundi attenzione !
 

SICUREZZA
Quello che ho presentato è solo una bozza di ciò che si può fare e ci sono molte migliorie da apportare tra cui :

Spostare il parsec dei comandi in una classe esterna cosi' da poterlo aggiornare dinamicamente, insomma, quello che ho presentato è veramente una bozza di un piccolo SERVER, ma che mette in risalto tutte le caratteristiche più importanti di questa branca di servizi.
Quasi dimenticavo, se intendete scrivere delle applicazione CLIENT / SERVER che utilizzano I socket tramite internet non utilizzate come numero di porta i valori minori di 1000, perché il range di ' porte ' ; da o a 1000 sono riservati ai servizi noti tipo :
 
 
SERVIZIO
PORTA
HTTP
80
FTP
21
TELNET
23
MAIL
25
                                                                                                        Buon divertimento.
Pietro Venanzangeli

 
 

Pietro Venanzangeli è programmatore C/C++ e JAVA. Diplomato in informatica all'ITIS B.Pascal di Roma. 
Si interessa di amministrazione di siti WEB e allo sviluppo di applicazioni internet e di networking. 
Attualmente lavora come consulente. 
Puo' essere contattato via e-mail a: networkmanager@lcnet.it
 
 
MokaByte rivista web su Java

MokaByte ricerca nuovi collaboratori
Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it