Page 74

IL PROTOCOLLO

KERMIT

LUNGH.

I N.pROGR.I __ T,_PO

le degli studenti negli archivi principali. Ne fu invece consigliato il decentramento nelle memorie dei vari sistemi periferici, e da queste il backup su floppy e relativa conservazione completamente fuori linea a cura del proprietario. Fu quando si trattò di mettere in pratica questa ragionevole direttiva che i gestori del centro di calcolo realizzarono con grande stupore che non esisteva nessun mezzo veramente semplice ed efficiente che consentisse il trasferimento di un file da un sistema all'altro della loro struttura! Le varie macchine erano infatti così diverse fra loro da non avere possibilità di colloquio ad alto livello (protocolli sincroni o reti) se non nei casi particolari di sistemi della stessa classe o famiglie verticali di macchine dello stesso produttore. Mancava, in particolare, un «ponte» diretto fra i personal ed i mainframe centrali, che consentisse lo scambio di file e non la semplice emulazione di terminale. L'unico canale comune a tutti i computer era quello, a basso livello, costituito da linee asincrone: la buona vecchia RS-232, insomma, da usarsi o per via diretta o tramite modem proprio per collegamenti «stupidi» di tipo ITY, ossia in emulazione di terminale. Esistevano sì mezzi per far parlare coppie di macchine: ma portare un file da un sistema qualunque ad un altro sistema qualunque avrebbe comportato un lavoro di passaggi multipli per varie macchine intermedie, con modalità differenti ad ogni passaggio e soprat.tutto con una quantità di lavoro addizionale insostenibile. Fu così che lo staff tecnico del centro di calcolo cominciò a pensare di sviluppare in proprio un sistema per trasferire i file fra macchine qualsiasi sfruttando il canale asincrono della RS-232. Il progetto fu intrapreso a due livelli: definire un protocollo che avesse le proprietà desiderate, e successivamente implementarlo in programmi reali su tutte le macchine della Columbia. Quello che serviva era un protocollo che fosse il più indipendente possibile dall'hardware, semplice da programmare in un linguaggio anche ad alto livello, non eccessivamente sofisticato e ragionevolmente efficiente, diretto soprattutto allo scambio di file di testo ma valido anche per file binari. Il lavoro fu portato avanti accuratamente, studiando e cercando di seguire le principali direttive degli enti di normalizzazione (in primis l'architettura a sette livelli OSI-ISO), per far sì 74

DA_T_,

che il nuovo protocollo fosse compatibile e potenzialmente integrabile in ogni sistema di comunicazione attuale e futuro. Da questo lavoro nacque infine la prima versione di Kermit come protocollo, subito implementata con successo in una serie di programmi Kermit specifici per i vari elaboratori della Columbia. Il nuovo procollo così inventato era qualcosa di effettivamente utile, ed i suoi autori pensarono che non fosse giusto che rimanesse chiuso nell'ambito della Columbia University. Decisero pertanto di renderlo pubblico, mettendo in circolazione i programmi sviluppati e pubblicando le specifiche del protocollo in modo che chiunque fosse in grado di implementarlo in proprio. Non bastava l'Xmodem? Qualcuno si potrebbe domandare, a questo punto, se era veramente necessario sviluppare un ulteriore protocollo asincrono o non poteva bastare uno di quelli già largamente diffusi, magari l'Xmodem che abbiamo visto nei mesi scorsi. La risposta è no, l'Xmodem pur con tutti i suoi pregi in questo caso non bastava. E vediamo perché. Il concetto di base su cui si fonda l'Xmodem è che le due macchine da far parlare siano uguali o perlomeno molto simili. Ricordiamo che fu inventato originariamente per scambiare file tra microcomputer basati sullo 280 ed il CP/M, ossia solo fra macchine con un substrato comune. L'estensione ad altri personal è stata facile, trattandosi sempre di macchine concettualmente analoghe. Gli assunti di base impliciti nell'Xmodem sono che entrambi i sistemi usino l'alfabeto ASCII ad otto bit, che il canale di comunicazione accetti dati ad otto bit senza bit di parità, che il sistema ricevente accetti pacchetti lunghi oltre 130 byte senza incorrere in problemi di ricezione o di overflow nel buffer, e che sia il canale di trasmissione che i sistemi colloquianti non «facciano capricci» in corrispondenza a determinati caratteri di controllo. Queste caratteristiche sono generalmente verificate nei microcomputer ma non sempre nei mini e nei mainframe, i quali a riguardo sono assai più schizzinosi. Inoltre l'Xmodem non brilla certo per versatilità, ed anzi ha due grossi limiti pratici di utilizzo. Il primo è che può inviare solo un file per volta, dopo di che il colloquio si interrompe forzatamente ed un nuovo trasferimento può essere fatto solo ricominciando tutto da capo; il

C_HK_S_u_M __

11

secondo è che il protocollo si limita a trasferire il file e non esporta alcuna conoscenza od informazione di livello superiore, neppure il semplice nome del file trasmesso. Kermit invece supera questi problemi, primi fra tutti quelli di incompatibilità imposti dall'hardware o dal software dei corrispondenti e del canale di trasmissione. Non fa affidamento sulle loro caratteristiche se non presumendo che siano in grado di ricevere e trasmettere i soli caratteri ASCII «stampabili», ossia quelli da 32 a 126. Ogni dettaglio tecnico della trasmissione è lasciato al mondo esterno: Kermit si adatta ai vincoli esistenti, configurandosi a quello che risulta il minimo comun denominatore fra le capacità del canale e dei sistemi colloquianti. Per far ciò Kermit si avvale di un più stretto scambio di informazioni fra i due sistemi corrispondenti. L'Xmodem è un protocollo rigido, in cui i parametri e le regole sono fisse ed immutabili. Kermit invece è un protocollo flessibile, in grado di modificare il suo comportamento adattandosi in modo dinamico alle esigenze imposte dall'esterno. La responsabilità di queste azioni di adattamento è a carico, ovviamente, dei due programmi Kermit che girano sui due sistemi in colloquio e gestiscono il trasferimento. E mentre sotto Xmodem i due corrispondenti interagiscono in modo molto limitato, sotto Kermit ogni estremità intrattiene con l'altra un colloquio assai più stretto . Struttura del Kermit Prima di passare a vedere i concetti di base del Kermit, vi do un breve cenno sulla struttura fisica del protocollo tanto per chiarire che, comunque, non si tratta di nulla di particolarmente esoterico. Attenzione al fatto che da ora in poi con la parola «Kermit» indicherò sia il protocollo in sè che i programmi che implementano il protocollo stesso, i quali si suppone siano disponibili ed attivi sui due sistemi che partecipano al colloquio. Dal contesto sarà facile capire a quale dei due significati farò riferimento. Kermit è ovviamente un protocollo asincrono orientato al byte, e quindi non richiede hardware particolare per il suo funzionamento. Si basa sul medesimo concetto di «pacchetto» che abbiamo già visto nel caso dell'Xmodem, ma più generalizzato. In Xmodem esiste fondamentalmente un solo tipo di pacchetto, quello di dati, oltre MCmicrocomputer

n. 63 - maggio 1987

063 MCmicrocomputer  

Maggio 1987

063 MCmicrocomputer  

Maggio 1987

Advertisement