la Tecnologia di Fidonet

Nei primi anni pionieristici dell’avvento dei microcomputer era frequente che novità ed innovazioni, anche significative, nascessero quasi per caso, grazie alla fortunata occasione che vede incontrasi le persone giuste, al momento giusto. La nascita di Fidonet ne è una prova tangibile, e le persone in questo caso sono due. La prima è Tom Jennings, uno sviluppatore professionista, che vive a San Francisco e lavora per Phoenix Technologies, l’azienda di Boston che ha creato il primo BIOS per PC Compatibili. La seconda è John Madill, dipendente della filiale di Baltimora di Computerland, una catena di computer, ed appassionato di informatica.

Madill aveva acquistato un DEC Rainbow 100¹ per usarlo come BBS, ma si rese subito conto del fatto che non era facile trovare software compatibile con quella piattaforma. Girovagando per i vari BBS statunitensi gli fu suggerito di provare a contattare il sysop di “Fido’s BBS”², Tom Jennings, a San Francisco. Tom rispose prontamente e positivamente, dicendogli che aveva sviluppato lui il BIOS e il DOS per il Rainbow, e che aveva già rilasciato una versione per quella piattaforma di due suoi programmi di comunicazione: Telink e Minitel. Tom si disse disponibile a fare lo stesso anche il suo Fido, ma non avendo disponibile un Rainbow per fare il lavoro, aveva bisogno della sua collaborazione. Si accordarono quindi per lavorarci assieme, pur vivendo a circa 4000 km di distanza.
Agli inizi lo scambio avveniva via tastiera attraverso la funzione Yell³ del BBS. La lentezza di questo sistema portò presto a bollette stratosferiche. Passarono quindi a collaborare lasciando messaggi sul BBS del corrispondente. E qui nasce la scintilla. Perché non automatizzare la cosa? “Se la chiave era depositare e-mail su un altro BBS, la soluzione sembrava ovvia. Fai chiamare Fido all’altro Fido … consegna la posta e riattacca.”4,5.

Tom Jennings racconta che l’idea si nacque nel giugno del 1984: “Quando FidoNet fu testata per la prima volta, c’erano due nodi: il mio Fido#1 a San Francisco e John Madill con Fido#2 a Baltimora. John ed io abbiamo fatto tutto lo sviluppo e le prove per attivare FidoNet. Lo scopo era quello di vedere se poteva essere fatto, per puro divertimento, come per l’attività di radioamatore. Divenne rapidamente utile: invece che provare a chiamare gli altri BBS per lasciare messaggi o fare costose chiamate a voce, inviare messaggi FidoNet divenne routine”.

C’è da considerare che, a differenza di quanto spesso si crede, il software Fido nella prima metà dell’84 era già ben diffuso, contando già alcune decine di installazioni. Era un progetto peraltro dinamico, nato nel novembre del 1983⁶, e che in pochissimi mesi era giunto alla versione 7 (rilasciata il 23/4/84). L’offerta di software a quei tempi era, d’altro canto, piuttosto ristretta: l’alternativa più diffusa in ambito DOS era RBBS, che però si fondava su un impianto di stampo hobbistico (a partire dall’uso del linguaggio Basic). Fido era invece scritto in C (Lattice 2) da uno sviluppatore professionista, e le differenze in termini funzionali erano evidenti.

Fino alla citata V7 Fido offriva funzionalità allineate a quelle degli altri programmi che seguivano le orme di CBBS. E’ con la V8, del 1 Giugno ’84, che viene implementato lo scambio automatizzato di messaggi che rivoluzionerà il settore. Per inciso, è molto probabile che il primo contatto fra Fido#1 e #2 si sia in effetti verificato prima di quanto raccontato dallo stesso Jennings. Fido V8 porta, infatti, come data di rilascio il primo giugno 1984, ed ha fidonet già operativo. E dato che lo stesso Tom afferma che “Fido #1 use SEMPRE una revisione successiva a quella rilasciata, per testare nuove funzione o soluzione di problemi”⁷, è quindi molto probabile che si sia svolta effettivamente nel mese di maggio ’84.

Fido V8 è la prima release che ho utilizzato per il mio BBS South Italy CBBS, ancor prima che potessi soddisfare le condizioni tecniche necessari per associarmi alla rete. In questa versione le funzionalità di rete erano implementate con un eseguibile separato: FIDO.EXE gestiva tutte le funzionalità del bbs, e ad orari prestabiliti passava il controllo del modem a NET.EXE, a cui era demandata la gestione delle connessioni di rete per lo scambio della posta elettronica. Entrambi i programmi erano rilasciati per tre distinte piattaforme (Ibm, Dec, Altri)

L’equazione è semplice: Fido+Net=FidoNet.

Chi usava già V7 poteva quindi ritrovarsi in rete con un semplice aggiornamento, e per essere operativi c’era un unico prerequisito: avere a disposizione uno smartmodem. La versione 8, che potete provare qui, implementava un nuovo tipo di aree messaggio, indicato con un ‘*‘ nella lista e con un esplicito ‘Fidonet‘ nel titolo. In questa area era possibile indicare, oltre al destinatario del messaggio, anche il nodo su cui questo era registrato. L’elenco dei nodi era contenuto in un semplice file di testo, ed ognuno dei partecipanti era identificato da un numero sequenziale, a partire dal nodo #1 di Tom Jennings. Già nella prima implementazione era prevista la gestione del costo di invio (per linea di messaggio), con un annesso sistema del credito per gli utenti.

La Fidonet Mail⁸ – è questo il temine usato da Jennings – non veniva distribuita immediatamente, come le email di oggi, ma accantonata fino allo scoccare della mail hour. Da quel momento, e generalmente per un’ora, i BBS della rete sospendevano temporaneamente di accettare collegamenti umani, e si dedicavano allo scambio della posta. Ogni nodo elaborava i messaggi in attesa di invio e predisponeva un pacchetto per ognuno dei nodi di destinazione, che poi chiamava in successione. Era un meccanismo semplice, ma funzionale per il ridottissimo numero di nodi che componevano la rete ai suoi inizi, specie se contigui. Peraltro in quegli anni negli Stati Uniti le chiamate locali erano gratuite, e quelle interurbane si pagavano in base alla distanza. Era una tecnologia che, per quanto rudimentale, funzionava, ed attirava sempre più utenti.

Il veloce incremento delle dimensioni della rete mise in luce i limiti dell’approccio iniziale, e Jennings nel primo anno di vita di Fidonet lavorò alacremente al miglioramento del suo software.

La versione 9 di Fido, rilasciata alla fine di Agosto ’84, portava con se due importanti innovazioni. La prima era la possibilità di allegare file ai messaggi di posta elettronica, sia locali che FidoMail. Oggi è una cosa che diamo per scontato, ma all’epoca era una innovazione significativa, che avrebbe avuto un impatto importante sul futuro di Fidonet, in quanto rendeva la rete idonea al trasferimento di dati, oltre che di messaggi. Anche in questo caso, era una implementazione che rispondeva ad una esigenza interna, che era quella della distribuzione settimanale della nodelist (il file che conteneva la struttura della rete) e di altri file di servizio.
La seconda era il primo passo verso la creazione di una rete organizzata, delineando un primo abbozzo di quello che tecnicamente viene definito routing: è una strategia che consente di ottimizzare i trasferimenti utilizzando dei nodi intermedi di distribuzione. La prima implementazione era a due livelli: i nodi geograficamente contigui venivano raggruppati in un’area associata ad un host. I collegamenti all’interno dell’area erano diretti, mentre quelli destinati ad un’altra area venivano inviati all’host, che li impacchettava assieme per trasferirli in una unica connessione all’host dell’area di destinazione, che avrebbe poi provveduto alla distribuzione ai singoli destinatari.
La nodelist era sempre ad un singolo livello, e le regole di distribuzione erano definite in un file a parte (route.bbs).

Fino alla fine del 1984 le funzioni di rete erano assolte esclusivamente dal Fido di Jennings. Con l’aumento della domanda, e la richiesta di maggiore flessibilità di uso, cominciarono ad apparire programmi alternativi, che implementavano le funzionalità definite dei documenti tecnici pubblicati del FidoNet Technical Standards Committee, e che quindi garantivano interoperabilità fra sistemi di diversi autori.
Erano sviluppati con due approcci diametralmente opposti. Il primo era quella di creare sistemi specializzati che implementavano una sola delle funzioni di Fidonet, mirando ad un approccio più sofisticato di un programma generalista come Fido. Strada tracciata da Seadog della System Enhancement Associated (SEA), un programma commerciale che era focalizzato esclusivamente sulle funzionalità di scambio della posta elettronica. Il secondo approccio era invece quello di continuare sulla strada del sistema integrato, come Fido, ma mirando a realizzare applicativi più configurabili ed usabili, strada tracciata da Opus, di Wynn Wagner.

Sempre nell’85 cominciano a svilupparsi anche programmi di utilità per i sistemi FidoNet. Uno dei più importanti è stato scritto da Vince Perriello: uno strato (che oggi definiremo di astrazione) fra il software di rete e l’hardware dei PC. Mirava a risolvere uno dei problemi più annosi dell’epoca: la citata scarsa compatibilità dei computer alternativi al PC IBM. Il FOSSIL (acronimo di Fido Opus Seadog Standard Interface Layer) isolava le implementazioni specifiche dell’hardware dei singoli PC in un piccolo programma separato. Questo non solo rendeva possibile avere un singola istanza di codice per varie piattaforme diverse (nel 1985 Fido, ad esempio, era rilasciato in cinque distinte versioni), ma anche aprirsi ad implementazioni future. E’ grazie a FOSSIL che i nodi Opus che ho messo in linea possono operare via TCP/IP, una tecnologia che nel 1986 era era riservata alla ristrettissima cerchia di Arpanet.
Con la fidonews del 3 febbraio 92 Jennings se ne assume comunque la paternità tecnologica: “The FOSSIL interface was originally the Fido internal serial library interface; the calls are fairly generic in design.”, specificando che la soluzione tecnica derivata dalla sua esperienza lavorativa in Phenix Technologies.

I primi mesi del 1985 videro un’altre importantissima implementazione per la rete: l’EchoMail. L’idea nasce da Jeff Rush, il sysop di Rising Star (124/206), che è il primo a definire un metodo per implementare su FidoNet un meccanismo di conferenze condivise fra più di nodi, seguendo lo stile delle aree Usenet o Compuserve. Traccia seguita a stretto giro da Bob Hartman con il suo Conference Mail System che farà da base alla definizione ufficiale della procedura nella FTS-0004 dell’anno successivo. L’idea è quella di estendere il formato dei messaggi standard di FidoNet mediante dei tag, campi dati inglobati nel testo del messaggio, che vengono usati per identificare il nome della conferenza e gli elementi necessari alla distribuzione del messaggio. Il programma di gestione dell’EchoMail analizza la base messaggi, estraendo quelli che vanno replicati, e ridistribuendoli a tutti i nodi della rete che implementano quella particolare conferenza. Grazie ad echomail tutti i BBS che partecipano ad una specifica conferenza condividono la stessa base messaggi, rendendo quindi possibili le conversazioni fra utenti di BBS diverse. E’ un successo clamoroso, visto che è la prima volta che una platea così larga di hobbisti ha accesso ad un sistema di conferenza, per di più a costo zero. Cosa che genera un grandissimo interesse ed una valanga di richieste per la creazione di aree dalle tematiche più disparate.

Nell’Agosto del 1985 la versione 11 di Fido implementa la nuova organizzazione della rete a tre livelli (Regioni, Net e Nodi), abbandonando il primo schema ad un solo livello. E’ il passaggio che concretamente sancisce l’ingresso nella maturità della tecnologia di FidoNet. Pur con le ovvie migliorie degli anni a venire, le basi della tecnologia di FidoNet sono rimaste sostanzialmente le stesse per gli oltre tre lustri in cui hanno dominato la telematica amatoriale.

Le operazioni di rete sono raggruppabili in sei funzioni di base.

NODELIST: è il collante principale della rete, che contiene la definizione di tutti i nodi che ne fanno parte. In passato era distribuita ogni venerdì, sia in formato generale (nodelist.xxx, dove xxx era il numero del giorno dell’anno in cui era rilasciata) che come differenza dalla precedente (nodediff.xxx). La disponibilità delle due versioni era importante, in quanto la nodelist negli anni d’oro di FidoNet era arrivata superare (compressa) il megabyte, mentre la nodediff era solitamente sotto i 100k. Questo consentiva di ridurre i costi di distribuzione.
Per ogni nodo sono definiti dei campi fissi, con i dati anagrafici, e dei flag, una serie di campi variabili che contengono delle indicazioni accessorie, come il tipo di modem utilizzato, il protocollo di scambio o l’indirizzo internet del nodo.
La lista è costruita in modo da essere leggibile, e i numerosi commenti, sia in testa che in coda, che ne facilitano la comprensione. Una volta era letta direttamente dal programma del BBS, oggi viene elaborata da software che la convertono in uno dei vari formati binari usati dai vari applicativi compatibili con FidoNet. I nodi sono identificati da un indirizzo, che oggi può essere fino a cinque elementi: <zona>:<net>/<nodo>.<point>@<dominio>. I point sono esclusi dalla nodelist perchè sono considerate sub entità del nodo.

EDITOR: è il software che consente di leggere e scrivere i messaggi. In origine era un compito svolto esclusivamente dai programmi di BBS, ma nel tempo sono apparsi degli applicativi dedicati (come GoldEd o MsgEd). Il formato di memorizzazione dei messaggi non è però unico. In origine c’era MSG di Tom Jenning, dal nome dell’estensione usata (.msg, appunto) in cui è utilizzata una subdirectory per ogni area, ed un file separato per ogni messaggio. Il file ha un header binario di 180bytes ed un corpo in formato testuale terminato da un x00, secondo gli standard del linguaggio C. E’ uno schema di memorizzazione semplice e veloce, ma che però mostra i suoi limiti di pari passo con l’aumentare del numero dei messaggi.
L’avvento dell’EchoMail con il suo volume di traffico ha prodotto la definizione di altri formati.
Uno è l’Hudson, dal nome di Adam Hudson, autore di QuickBBS, che ha optato per memorizzare tutti i messaggi, indipendentemente dall’area, in un singolo file (msgtxt.bbs) a cui sono associati altri file che contengono gli indici ai singoli messaggi. L’approccio è sicuramente più efficiente, sia in termini di occupazione di spazio, che di velocità di accesso, ma anche la struttura unica presentava dei limiti operativi.
Altri due formati – Squish e Jam – hanno un approccio simile: ogni area è memorizzata in un file dati con strutture di indice associate. Potendo scegliere è sicuramente conveniente usare una delle due. Ovviamente tutti i programmi utilizzati devono essere in grado di gestire quella specifica tipologia di formato.

SCANNER: E’ il programma che analizza le aree messaggi marcate come EchoMail: individua i nuovi messaggi, li elabora per predisporli alla condivisione ed organizza l’invio ai nodi con cui devono essere condivisi.

PACKER: I messaggi in attesa di essere inviati devono essere inseriti in un pacchetto per il nodo di destinazione. Il pacchetto (.pkt) è un singolo file, composto da un header di 58 byte, zero o più frame contenete ognuno in singolo messaggio (che può essere sia mail che echo), ed un terminatore (16 byte a zero). Il packer è il programma crea che crea i pacchetti (uno distinto per ogni nodo di destinazione) e che rimangono in attesa di essere trasferiti in un’area definita di outbound. Secondo lo standard originale, i pacchetti non sono compressi. Dato che, però, in larga parte sono formati da testo facilmente comprimibile, per ridurre i costi è stato messo a punto un formato di invio compresso compatibile con lo standard originale: ArcMail di SEA (produttore sia di SeaDog che di ARC), poi diventato uno standard Fidonet. Il file .pkt rimane inalterato, ma i messaggi sono memorizzati separatamente in un file compresso, che viene inviato come allegato.

MAILER: è quello che gestisce il cuore della rete, i trasferimenti di posta. In passato le funzionalità di mailer erano alternative a quelle del BBS – per trasferire posta bisognava bloccare l’accesso umano – ma con lo sviluppo di nuovi protocolli questa limitazione è stata eliminata ed era quindi tecnicamente possibile inviare posta ed EchoMail in qualsiasi momento. Anche in questo caso, sono stati messi a punto nel tempo vari protocolli. Il mailer spedisce i pacchetti presenti dell’area definite come outbound ai nodi di destinazione, e deposita quelli ricevuti in un’area di ingresso (inbound) per la successiva elaborazione.

TOSSER: elabora i pacchetti presenti in area inbound e li inserisce nelle rispettive aree di destinazione. I messaggi di posta sono memorizzati nell’area appositamente designata in configurazione, mentre i messaggi EchoMail sono assegnati in base al tag AREA inserito nel messaggio.

Vi sono poi altre funzionalità accessorie, che dipendono dalle finalità del sistema e non sono indispensabili al funzionamento di un nodo. Cito giusto le più comuni:

TICKER: E’ un modulo che consente di implementare un meccanismo di distribuzione automatica di file (definito in FTS-5006) che sostanzialmente è l’equivalente funzionale delle aree EchoMail per i file.

AREAFIX: Alle aree echomail è associato una attività di configurazione che richiede la cooperazione dei due nodi (quello che distribuisce e quello terminale) coinvolti. Areafix, di Greg Dawson, è stato il primo area manager che consentiva ai sysop di gestire autonomamente la sottoscrizione o la cancellazione dalle aree echomail. Oggi la sua funzione è spesso svolta direttamente dal tosser.

Link utili

1. Il Rainbow era un computer prodotto dalla Digital (DEC) nei primi anni ’80 ed appartiene al gruppo di primi personal basati su 8086 che usavano MsDos ma che non erano direttamente compatibili con il PC IBM. Il Rainbow aveva due CPU, uno Z80 ed un 8086, e poteva usare sia il CP/M che l’MsDos. All’avvio era possibile selezionare la modalità ad 8 o 16 bit, oppure se operare come un terminale VT102. A dispetto del nome, era monocromatico, e con lo schermo gestito come quello di un terminale – con le sequenze ANSI, e non attraverso una memoria mappata come nelle schede video dei compatibili IBM. Anche il formato del floppy non era compatibile.
2. Madill racconta che ‘Fido’ era il nome del miscuglio di hardware MC68000 su cui girava il suo BBS. Ci tiene a precisare che, nonostante la CPU, il BBS operava sotto DOS: “Di quanti 68000 con sistema operativo DOS avete mai sentito parlare?”. Questo la dice lunga sugli skill di Jennings. D’altro canto la Phoenix Technologies, l’azienda per cui lavorava, era licenziataria dei sorgenti dell’86-DOS di Seattle Computer Products, lo stesso codice che sarebbe diventato MsDos e PcDos, e Jennings era fra gli sviluppatori del BIOS Phoenix. Jennings si era fatta una versione del DOS customizzata per il suo hardware.
3. Yell at sysop è una funzione di molti BBS che consente di richiamare con un allarme il Sysop, se è presente nelle vicinanze, per invitarlo ad una chat testuale.
4. Fidonet History su fidonews1332.txt
5. Ben Baker in più occasioni ha sostenuto che l’idea dello scambio di messaggi fra BBS nacque in una telefonata fra lui e Tom Jennings. Le due versioni, comunque, non si contraddicono.
6. Intervista a Tom Jennings, Infoworld 27 Agosto 1984
7. In fidohistory1.txt
8. L’uso del termine posta (mail) ha creato non pochi problemi, perché in quegli anni i servizi postali erano generalmente dei monopoli gestiti direttamente dagli stati, e non era chiaro lo status dell’equivalente elettronico. E’ il motivo per cui la posta elettronica FidoNet è generalmente definita matrix.