X/Y/Z modem

Uno dei fattori di maggior successo dei BBS è stato sicuramente costituito dalle aree file. In quegli anni la disponibilità di software era decisamente scarsa, ed al di là di pochi programmi commerciali – che comunque erano decisamente cari, spesso fuori dalla portata dell’hobbista medio – per caricare nuovi programmi si ricorreva spesso a digitare a mano i lunghi listati pubblicati dalle riviste del settore.

Le aree file dei BBS invece presentavano una grande varietà, per l’epoca, di software di tutti i tipi. Per di più, i meccanismi premiali implementati nei BBS favorivano la diffusione dei programmi, e si imposero come canale di distribuzione di una nuova tipologia di vendita, lo shareware.

Ma trasferire software via modem, un canale tutt’altro che privo di errori, richiede delle tecniche specifiche per assicurare che la copia scaricata sia uguale all’originale. Per effettuare questa operazione in modo rapido ed affidabile sono state sviluppati e perfezionati nel tempo degli appositi protocolli.

Il primo in assoluto è stato XModem. Fu scritto da Ward Christensen prima ancora della creazione di CBBS proprio per poter trasferire software attraverso il modem. Era un programma a se stante, chiamato proprio modem, successivamente modificato da Keith Petersen che lo ribattezzò xmodem, ed operava in modo molto basilare. Suddivideva il file da trasferire in pezzi chiamati pacchetti. Il pacchetto era costruito con un preambolo di tre byte (<SOH>, il numero del del pacchetto ed il complemento a 255 dello stesso numero), 128 byte di dati (la lunghezza di un blocco del floppy disk del sistema operativo CP/M) e da una cifra di controllo finale che era calcolata sommando i byte trasmessi e mantenendo i soli 8 bit meno significativi (modulo 256).
Lato ricezione, una volta giunti tutti i 132 caratteri veniva ricalcolata la cifra di controllo e confrontata con quella trasmessa. Se il risulto corrispondeva, il ricevente trasmetteva il carattere <ACK> (aknoweledge) che indicava al corrispondente di trasmettere il pacchetto successivo, altrimenti inviava un <NAK> (negative aknoweledge) che causava la ritrasmissione dello stesso pacchetto. Veniva controllato anche il numero del pacchetto, in modo da identificare la perdita di un pacchetto. La fine del file era segnalata inviando un carattere <EOT>.
Il processo aveva un timeout di 8 secondi, ed era controllato dal computer ricevente, che avviava la trasmissione inviando un <NAK> iniziale.
Il punto di forza di XModem è stato costituito proprio dalla sua semplicità, piuttosto che dalle sue peculiarità tecniche. Ward ebbe a definirlo, forse a ragione, “il singolo programma più modificato nella storia dell’informatica”¹ Le sue debolezze hanno portato alla definizione di protocolli più sofisticati ed efficienti. Ma è indubbio che il mondo del BBS deve molto a Christensen, ed alla generosità dai tanti che in quegli anni pionieristici rilasciavano software di pubblico dominio.

Le principali lacune di XModem erano sostanzialmente due. La prima era nel metodo di calcolo della cifra di controllo, che era troppo semplice per rilevare efficacemente errori di trasmissione: due errori si segno opposto potevano compensarsi e, quindi, non essere rilevati. In una successiva versione, XModem-CRC, il calcolo modulo 256 venne sostituito da un controllo di ridondanza ciclica (CRC-16), che sostanzialmente tiene in conto anche dove l’errore si manifesta, e che quindi rende la rilevazione dell’errore più sicura.

La seconde dipendeva dal fatto che era un protocollo nato per l’uso diretto, controllato da un operatore. Nei BBS la procedura standard era quella di navigare attraverso le varie aree file, scegliere il file da scaricare, mettere il BBS in modalità di invio xmodem e poi avviare il protocollo sul programma di comunicazione. Una procedura non funzionale per l’automatizzazione del processo.

Gli sviluppi successivi hanno cercato di estendere l’utilizzabilità di XModem anche in altri ambiti.

Il primo dei figli è stato YModem, scritto da Chuck Forsberg. che lo ha inserito nel suo programma YAM (yet another modem program). Le migliorie principali comprendevano la possibilità di abortire un trasferimento, inviando due caratteri <CAN>, il controllo di errore via CRC ed la lunghezza del pacchetto a 1024 bytes, in modo da avere maggiore efficienza operativa. Un ulteriore perfezionamento era costituito dalla possibilità di inserire nel flusso anche il nome del file (in una struttura chiamata zero packet, per differenziarla dai pacchetti di dati che invece erano numerati a partire da 1). Purtroppo quest’ultima caratteristica fu implementata parzialmente, e spesso male, e la cosa causò tanti problemi che alla fine le due implementazioni assunsero due entità diverse: YModem, senza lo zero packet, e YModem-batch, che invece lo supportava.

Alla fine lo stesso Forsberg rilasciò un terzo protocollo, ZModem, per superare i problemi di YModem e quella che lui definiva “Electronic Tower of Babel”², con un approccio del tutto nuovo.

ZModem nasce nel 1986, nel pieno della corsa alla velocità dei modem. Per ottenere trasferimenti sempre più veloci era necessario ottimizzare al massimo l’efficienza del canale di trasmissione, e l’uso di computer più performanti, sia in termini di disponibilità di memoria che si velocità dei processori, consentiva approcci più sofisticati rispetto all’XModem, nato nell’epoca dell’8080, ed ai suoi derivati che ne mantenevano inalterata la sua struttura di base.
Queste famiglie di protocollo avevano tutte una inefficienza legata al fatto di dovere attendere la risposta, positiva o negativa, del ricevente all’invio di ogni pacchetto per potere inviare quello successivo. A basse velocità il ritardo era trascurabile, ma – man mano che le velocità aumentavano – la sua incidenza sull’efficienza diventava più che significativa.
ZModem risolse il problema eliminando del tutto l’attesa. I pacchetti vengono spediti uno di seguito all’altro, senza attendere conferme da parte della stazione ricevente. Nel caso sul lato ricevente un pacchetto dovesse risultare corrotto al controllo del CRC a 32 bit, questa invierà un <NAK> per richiederne la ritrasmissione.
Per potere gestire questa caratteristica, la numerazione del pacchetto è implementata con un intero a 32bit, cosa che consente di riposizionare il trasferimento in un punto qualsiasi del file senza problemi, consentendo di riprendere un trasferimento interrotto da un punto arbitrario.
Un’altra innovazione significativa è lo spostamento del controllo dalla stazione ricevente a quella trasmittente, che quindi ora può gestire il collegamento, ed istruire la ricevente a ricevere e memorizzare i file, anche in sequenza.

Un altro protocollo che ha avuto una buona diffusione in quegli anni, e che non può non essere ricordato, è il Kermit. Nasce però in un contesto del tutto differente, per sopperire alle esigenze in ambito universitario per spostare file fra i vari servizi disponibili alla Columbia University. A questo fine il programma, nato nel 1981, è stato portato su una vasta quantità di sistemi, che all’epoca erano del tutto incompatibili. Grazie al Kermit, ed al supporto dei vari mainframe e minicomputer presenti nel campus universitario, era relativamente facile trasferire dati fra sistemi che non erano nativamente in grado di leggere i supporti magnetici di altre piattaforme.
Per garantire la corretta flessibilità, Kermit è in grado di operare su connessioni sia a 7 che ad 8 bit e in modalità full-fuplex ed half duplex. Come XModem utilizza una struttura a pacchetto,ma che non è limitata ad un solo tipo: un campo (TYPE, 1 byte) consente di selezionare diverse tipologie di pacchetto, che trasportano diversi tipi di contenuto (payload). Sulle connessioni full duplex è implementato lo sliding window, un accorgimento che consente di eliminare i ritardi dell’attesa della conferma di corretta ricezione, gestendolo in maniera asincrona.

Il protocollo Kermit supporta il trasferimento di file di testo e binari su connessioni seriali full-duplex e half-duplex a 8 bit e 7 bit in modo indipendente dal sistema e dal mezzo ed è implementato su centinaia di piattaforme di computer e sistemi operativi diversi. Su connessioni full duplex, viene utilizzato un protocollo a finestra scorrevole con ritrasmissione selettiva che offre prestazioni eccellenti e caratteristiche di recupero degli errori. Su connessioni a 7 bit, i turni di blocco forniscono un trasferimento efficiente dei dati a 8 bit. Se correttamente implementato, come nella collezione Kermit Software della Columbia University, i suoi autori affermano che le prestazioni sono uguali o migliori di altri protocolli come ZMODEM, YMODEM e XMODEM, specialmente su connessioni scadenti. [1] Su connessioni tramite multiplexer statistici RS-232 in cui alcuni caratteri di controllo non possono essere trasmessi, [citazione necessaria] Kermit può essere configurato per funzionare, a differenza di protocolli come XMODEM che richiedono che la connessione sia trasparente (ovvero che tutti i 256 possibili valori di un byte siano trasferibili ).

Per inciso, Kermit sembra debba il suo nome alla omonima rana del Muppet Show. Ufficialmente il suo nome è comunque uno pseudo acronimo: “Kl10 Error-free Reciprocal Microprocessor Interchange over Tty lines”, in cui KL-10 è il nome della versione del mainframe Digital Equipment Corporation PDP-10 installato presso la Columbia University.

Info