ADPnetwork... e l'AI 🤔
Ho chiesto a NotebookLM di scrivere un pezzo sull'argomento... dandogli 'in pasto' miei articoli dell'epoca. Buona lettura.
«Il progetto ADPnetwork nasce come un avanzato sistema di rete (software e, successivamente, hardware) progettato per i computer della famiglia Amiga (500, 1000 e 2000). Sviluppato inizialmente con finalità didattiche da Andrea de Prisco, il progetto si è evoluto in una piattaforma professionale per la creazione di applicazioni e file system distribuiti, grazie anche alla collaborazione di Marco Ciuchini e Andrea Suatoni (autori del Net-Handler) e di Giuseppe Cardinale Ciccotti e Luciano Macera (autori della scheda hardware dedicata). L'intero software di rete è stato scritto sfruttando l'ADPmttb 2.0, un toolbox per la gestione del multitasking.
Architettura e Topologia di Rete - L'architettura di ADPnetwork si basa su una topologia rigorosamente circolare (o "a maglia"), in cui ogni macchina possiede un nodo precedente dal quale riceve il flusso di dati e un nodo successivo al quale trasmette. A differenza di reti come Ethernet o Token Ring, l'infrastruttura di ADPnetwork è "Token Free" e deterministica.
Non esiste un "gettone" da possedere per poter trasmettere: ogni nodo è proprietario fisico del collegamento verso la macchina successiva e può immettere pacchetti in rete in qualsiasi momento, senza dover attendere la liberazione di risorse condivise o rischiare collisioni dovute all'arbitraggio non deterministico. Per le connessioni fisiche a due nodi era sufficiente un cavo "Null Modem", mentre per reti più estese venivano utilizzati speciali "sdoppiatori passivi" terminati agli estremi per chiudere l'anello.
Hardware: Dalla Seriale al Transputer - L'evoluzione del progetto si divide in due fasi hardware:
Fase Software (RS-232): Inizialmente, la rete utilizzava la normale porta seriale dell'Amiga a 31250 baud. La gestione di tutti i flussi e dell'impacchettamento gravava sulla CPU dell'Amiga.
Fase Hardware (Transputer T222): Per ovviare ai limiti di banda e sgravare il processore principale, è stata sviluppata una scheda di rete intelligente basata sul microprocessore Transputer Inmos T222, affiancato da 64K di SRAM. Questa scheda, gestita tramite processi paralleli in linguaggio OCCAM, ha permesso una velocità di trasferimento circa 100 volte superiore e una gestione totalmente indipendente dal traffico passante non destinato al nodo locale.
Protocollo, Frammentazione e Struttura dei Pacchetti - I dati non vengono inviati come flussi continui, ma vengono suddivisi in "frame" di lunghezza variabile compresa tra 128 e 5120 byte. Questa frammentazione è fondamentale per gestire la tolleranza ai guasti: in caso di errore, viene ritrasmesso solo il frame corrotto, non l'intero file.
La struttura del pacchetto di rete (StandardFrame) è molto complessa e include:
Lunghezza, Mittente e Destinatario: I campi base per l'instradamento.
MsgID e Offset: Utilizzati per rimettere in sequenza i frame frammentati, dato che in rete non è garantita la sequenzialità d'arrivo.
Checksum e CRC: Un byte di checksum controlla l'integrità dei primi 22 byte (header), mentre un controllo CRC (Cyclical Redundance Code) a 32 bit verifica l'integrità del corpo del messaggio.
Stamp: Un campo speciale che i nodi "marchiano" al passaggio di un frame. Se un pacchetto ritorna a un nodo che lo ha già marchiato, significa che il destinatario non esiste più in rete. Il frame (definito pacchetto "zombie") viene quindi "ucciso" ed eliminato per evitare che circoli all'infinito.
Il Software di Rete (SdR) e la Tolleranza ai Guasti - La vera potenza di ADPnetwork risiede nel suo sistema di tolleranza ai guasti (Fault Tolerance). Anche in caso di interruzione fisica dei cavi nel mezzo di un trasferimento (ad esempio, durante la stampa o la copia di un file), il sistema semplicemente si "congela"; non appena i cavi vengono ricollegati, l'operazione riprende automaticamente dallo stesso punto, senza perdere dati.
Questo miracolo informatico è gestito da processi cooperanti:
Su Amiga: Il processo Packer frammenta il messaggio e lo cede al Sender per l'invio fisico. Contemporaneamente, il Replay salva una copia del messaggio e un Timer viene attivato.
Su Transputer: Il Dispatcher analizza il frame in arrivo. Se è per il nodo locale, lo passa al buffer SenderAmiga e genera istantaneamente un pacchetto di conferma (ACK). Se è per un altro nodo, lo reinoltra ciecamente.
Gestione degli errori: Se il processo Replay sull'Amiga mittente non riceve tutti gli ACK previsti prima dello scadere del Timer, ritrasmette automaticamente i pacchetti mancanti. In ricezione, il processo Recomposer si occupa di riordinare e riassemblare i pacchetti per ricostruire il messaggio originario.
Autoconfigurazione Dinamica - La rete non necessita di un server centrale per assegnare gli indirizzi IP o ID. Ogni macchina, all'avvio, si autoconfigura scegliendo un NetID a 16 bit tramite un algoritmo pseudo-casuale basato sull'orologio di sistema. Il nodo invia quindi un pacchetto di "proposta" su tutto l'anello: se il pacchetto fa il giro completo senza che nessun altro nodo segnali un conflitto (collisione di ID), il NetID viene adottato in via definitiva.
L'Integrazione col Sistema Operativo: Il device "NET:" Lato utente, la rete è completamente trasparente grazie al Net-Handler, che introduce ad AmigaDOS un nuovo device chiamato net:. L'utente può navigare nelle macchine collegate esattamente come se fossero dischi locali, digitando da Shell comandi come dir net:platone/dh0. Anche a livello grafico (WorkBench), la rete appare come un'icona ad anello. Cliccandola, appaiono le icone di tutte le macchine remote, e al loro interno i vari dischi e volumi (RAM, DF0, DH0). I file possono essere aperti, lanciati o trascinati (copiati) tra macchine diverse in totale naturalezza.
Per i programmatori, scrivere applicazioni distribuite per ADPnetwork risultava estremamente semplice: bastava utilizzare le chiamate di sistema SendBlock e ReceiveBlock indirizzandole a specifiche porte MTTB (es. "pitagora/pippo"), delegando tutto l'instradamento e il controllo di errore ai livelli sottostanti del sistema».
---- 👀----
Che dire? L'esperimento, che avevo in pectore da tempo, mi ha convinto e... rassicurato. In particolare sul fatto che all'epoca scrivessi articoli comprensibili, spero anche dagli utenti umani.
Detto questo, come spesso capita con i ChatBot, noto un tono forse troppo accondiscendente e poco critico (ma ufficialmente lui non sa che erano articoli miei e, si sa, le AI tendono sempre ad allisciare - come fa il diavolo - l'utente) tant'è che l'ho stuzzicato anche in questo e la sua risposta, senza bit 1 sulla lingua, la trovate nel riquadro a seguire.
Buon proseguimento di lettura!
AdP
Punti critici e limiti del progetto
(sempre da NotebookLM)
«Sebbene il progetto ADPnetwork fosse estremamente innovativo per l'epoca, presentava alcuni punti critici e limitazioni, legati principalmente alla natura dell'hardware disponibile e a specifiche casistiche della sua architettura distribuita. I principali punti critici emersi dallo sviluppo del sistema erano i seguenti:
1. Limiti di velocità e sovraccarico della CPU (nella versione Software) - Nella sua prima incarnazione senza hardware dedicato, ADPnetwork utilizzava la porta seriale standard dell'Amiga, che imponeva un limite di velocità di 31250 baud. Questa larghezza di banda era sufficiente solo per carichi leggeri e piccole operazioni, come il trasferimento di piccoli file di testo. Inoltre, poiché la rete era gestita interamente via software, ogni Amiga doveva occuparsi di ricevere, analizzare e reinoltrare i pacchetti in transito non destinati a sé stessa: questo gravava sulla CPU principale, causando un lieve rallentamento generale delle operazioni sulla macchina dell'utente. Questo limite fu poi superato con l'introduzione della scheda hardware dedicata basata su Transputer, che sgravava completamente il processore dell'Amiga da questo compito ed era 100 volte più veloce.
2. Il rischio dei pacchetti "Zombie" (Loop infiniti) - A causa della topologia ad anello, se una macchina immetteva un pacchetto in rete e poi andava in crash, o se la macchina destinataria scompariva improvvisamente, il pacchetto rischiava di circolare all'infinito poiché nessun nodo lo riconosceva come proprio. Per risolvere il problema, fu introdotto un campo "Stamp" (Timbro): un nodo intermedio, inoltrando il pacchetto, lo marchiava con il proprio ID; se il pacchetto faceva un giro completo tornando allo stesso nodo, quest'ultimo capiva che il destinatario non esisteva più e "uccideva" il pacchetto. Il punto critico, tuttavia, persisteva in un caso limite: se anche la macchina che aveva apposto il timbro (lo Stamp) moriva, il pacchetto rimaneva in vita, continuando a girare a vuoto. Per ridurre al minimo questa eventualità, la struttura del pacchetto fu aggiornata per contenere due campi Stamp distinti da far settare a due macchine diverse, abbassando enormemente (ma non eliminando del tutto) le probabilità che questo errore si verificasse.
3. Conflitti nell'autoconfigurazione degli ID di rete - Essendo un sistema completamente distribuito e privo di un server centrale, all'avvio ogni macchina sceglieva il proprio identificativo (NetID) in modo pseudo-casuale e mandava un messaggio di "proposta" sulla rete per verificare che nessun altro lo stesse usando. Il punto critico si presentava nel caso rarissimo in cui due macchine generassero esattamente lo stesso ID nello stesso momento. Quando le rispettive proposte si incrociavano sull'anello, ogni macchina credeva che fosse la propria proposta ad aver fatto il giro, adottando l'ID e causando gravi malfunzionamenti all'intero sistema. Per evitare questo collasso, il pacchetto di autoconfigurazione fu arricchito con dati molto specifici (memoria libera in quell'istante, ID del processo in esecuzione e tick dell'orologio interno), rendendo una collisione quasi matematicamente impossibile, a meno che le macchine non fossero identiche e avviate nello stesso identico istante al millisecondo.
4. Saturazione dei Buffer di ricezione - In situazioni di carico elevato sulla rete, poteva verificarsi che tutti i buffer di una macchina si riempissero contemporaneamente. Quando il buffer del processo di ricezione (SenderAmiga) era pieno, la macchina non era in grado di accettare il pacchetto in arrivo e, di conseguenza, non generava il pacchetto di conferma (ACK). Questo costringeva la macchina mittente ad attendere lo scadere del suo "Timer" per poi rispedire nuovamente i dati, causando ritardi e inefficienze nel traffico.
5. L'interruzione fisica dell'anello - Essendo una rete a maglia circolare "Token Free", l'infrastruttura dipendeva dalla continuità fisica dei collegamenti. Se un utente spegneva una macchina e voleva estrarla fisicamente dalla rete, doveva ricordarsi di staccare i due cavi (ingresso e uscita) e collegarli tra loro per chiudere nuovamente l'anello. Sebbene il sistema Fault Tolerant mettesse semplicemente "in pausa" le trasmissioni in caso di rottura dei cavi senza perdere dati, un'interruzione fisica non ripristinata bloccava di fatto le comunicazioni per tutte le altre macchine».
---- 👀----
MI CONSENTA🤣: Forse la mia domanda breve, «Quali erano i punti critici, se ne esistevano?», non era molto chiara. In particolare, mi chiedo: come fai a considerare un punto critico qualcosa che il progetto aveva previsto implementandone la soluzione?
Ad esempio, punto 1, i limiti di velocità della porta seriale, abbondantemente superati con l'utilizzo della scheda Transputer. Idem per il secondo punto (pacchetti Zombie), per non parlare del terzo (autoconfigurazione ID di rete).
Infine, sull'ultimo punto: le saponette (ricordate questo nomignolo ai tempi di AppleTalk?) prevedevano un relè interno che chiudeva automaticamente ingresso e uscita seriale (e lo stesso sarebbe avvenuto anche per la versione Transputer) in caso di spegnimento o disconnessione fisica della macchina.
Banalmente perché, se così non fosse stato, il problema si sarebbe presentato con il semplice spegnimento di una postazione: anche in questo caso un pacchetto non sarebbe mai arrivato alla successiva macchina, interrompendo l'anello e il funzionamento stesso di ADPnetwork.
So' ragaaaaaazzi! 🤣
AdP
Video generato da NotebookLM, fornendogli solo i link agli articoli su ADPnetwork.
