Ä CYBERNET: progetto GAIA (65:1600/1.27) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ GAIA.IT Ä Msg : 24 of 28 From : Zeus Kissakie' 65:1400/7 28 Feb 96 09:46:54 To : All 29 Feb 96 20:42:22 Subj : [1/4] Gaia ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ >>> Part 1 of 4... .------------------------------------------------------------------------------ Generazione Automatica di Interfacce Autoorganizzanti Ver 3.00 INDICE 1) Indice 2) Introduzione Terminologia Il Software esistente 3) Certificazione delle identita' di rete C-spazio vs Spazio Reale 4) Cosa si intende per Risorse La SuperClasse Resource Le Classi derivate da Resource, ovvero stati funzionali del nodo 5) Topologia Autoorganizzante Files sulla struttura NetBase HyperBase FileBase MailBase EventBase Rerouting Crash-Recovery L'algoritmo di controllo per il rerouting delle Pub-Res Ottimizzazione di spesa Ottimizzazione di traffico File Requests Ottimizzazione dei percorsi Richieste periodiche 6) Soluzioni Tecniche HandShaking Addressing Non-GAIA systems Scambio netmail di controllo 7) E-mail Univocita' e rintracciabilita' System Mail Il messaggio L'albero ipertestuale La GIF echo 8) GAIA come organismo digitale Struttura ecologica La Add-Res: DNA di GAIA 9) Tempi e criteri di implementazione Object-wrapper Linguaggio di sviluppo Modularita' Premessa Il lavoro mi lascia pochissimo spazio per le attivita', diciamo cosi', creative... e quindi sono costretto a chiedere scusa per l'enormita' di tempo che mi e' occorsa per produrre questi piccoli philes... a parte le scuse, il fatto suona come avvertimento... e' necessario che il lavoro di produzione del codice sia spezzato in tasks di dimensioni affrontabili, in quanto credo il problema-tempo sia comune a quasi tutti noi. Questo documento, appena riconosciuto come esaustivo degli argomenti trattati, sara' mantenuto aggiornato ed espanso via via che proseguiamo nel lavoro, finendo per costituire una sorta di "GAIA reference guide". Introduzione Il progetto GAIA e' nato per risolvere un problema frequente nelle reti ad organizzazione gerarchica: la paralisi della distribuzione postale dovuta al crash di un nodo. Il dibattito in rete ha apportato tali e tante variazioni al timido concetto originale che non ha ormai piu' senso cercarne un autore specifico, l'analisi e' stata svolta da CyberNet osservando se stessa. E la firma e' da considerarsi a tutti gli effetti collettiva. Due prime versioni si sono condensate nella relazione che state leggendo, in modo che e' apparso sensato reiniziare una nuova numerazione nel dare una prima esposizione sistematica. Il senso del versioning e' dunque soprattutto quello di fissare un contesto per il dibattito. Terminologia Notazione Insiemistica di minima: ˇ = Qualsiasi sia / = Tale che Analisi ad Oggetti: I termini sono cosi' prefissati: O_xxxxxx : classe di riferimento AXxxxx, AnXxxx : istanza della classe; Ove per classe si intende la definizione generale di un tipo di oggetto (Es. prodotto, marca, sapore, etc.) e per istanza si intende il concreto verificarsi un oggetto in particolare (Es. quei biscotti del Mulino Bianco al gusto di mela che stanno sul tavolo ). Il Software esistente La proposta 3.00 si e' stabilizzata in un superset dello standard Fido, verso cui mantiene compatibilita'. Viene posta grande attenzione a compiere il minor numero di sostituzioni di pacchetti, orientandoci piuttosto ad ottenere un comportamento conforme allo standard che stiamo disegnando attraverso la riconfigurazione dei pacchetti gia' esistenti. Cio' puo' aiutarci a minimizzare sia il tempo di scrittura del codice che quello di Beta-testing. A questo comportamento si fa riferimento ogni volta che si parla di "programmazione ad alto livello". Alto si riferisce al fatto che ci si trova separati dall'hardware da un layer multistrato di softwares che assicurano vasta compatibilita'. Via via che si raggiungono nuovi accordi sulle richieste tutti sono pregati di segnalare i pacchetti gia' esistenti su cui e' possibile implementare i nuovi standard attraverso una semplice variazione di parametri. Certificazione delle Identita' di Rete Tramite l'inclusione di PGP ver 2.3 nel software di GAIA e' stato possibile pensare ad un meccanismo di certificazione delle Identita' di Network che non violi la privacy degli utenti. All'ingresso in GAIA il nodo genera il proprio paio di chiavi PGP ed estrae il Public Key Block da inviare agli altri nodi. Cio' costituisce la base per la certificazione della sua identita'. Non e' necessaria la criptazione dei messaggi, in quanto PGP e' in grado di valutarne la provenienza a partire dalla semplice signature. Cio' si riferisce ai messaggi di sistema, fermo restando il diritto alla criptazione della posta personale. C-Spazio vs Spazio Reale Una delle FAQ apparse nel dibattito e' all'incirca riconducibile alla forma: "ma se nessuno esercita controlli su chi ha diritto di stare in rete, come faccio ad evitare di essere coperto da messaggi a me sgradevoli?" Il problema e' stato finora considerato in modo improprio. Nel mondo reale noi abbiamo scarso accesso alla nostra interfaccia percettiva, possiamo decidere di ignorare una persona, ma questo, oltre ad essere scortese, non ci evita di percepirla. Nel C-spazio la situazione e' diversa: noi abbiamo accesso alla nostra struttura percettiva e quindi la possiamo programmare. Molti gia' usano filtri e keywords per selezionare la posta, non c'e' ragione alcuna per cui questi filtri non possano essere attivati per selezionare anche le persone. In questo modo ognuno puo' strutturare una propria mappa del C-Spazio in cui si trova, ammettendo nella propria realta' solo chi vuole ammettere. Il problema degli alias falsi viene eliminato dalla certificazione emessa via PGP, ed e' anche possibile pensare a strutture di *presentazione* tramite lo stesso meccanismo. All'atto di ricevere una nuova chiave l'utente puo' valutare da chi essa e' certificata e decidere di conseguenza. Generalmente il nuovo utente sara' presentato solo da se stesso, avendo ricevuto il software da una connessione piu' o meno casuale con un nodo di GAIA, e la sua chiave sara' certificata dalla User_Id "GAIA". Ma e' possibile che il nuovo utente sia presentato da un introduttore gia' noto agli utenti, che garantisce per lui/lei. In questo caso l'accettazione o il rifiuto espresso da ogni singolo nodo verso l'introduttore si trasnmettera' al nuovo utente. Cio' consente di strutturare gruppi chiusi all'interno di GAIA, per coloro che amassero tale genere di socialita'. Su questo punto rimando alla necessita' di studiare attentamente l'impiego di PGP e la/le forme di msgbase da adottare. Infatti la possibilita' di aree chiuse, ovvero invisibili, presume che si possano criptare interi pkt postali con una specifica chiave di gruppo, che sara' necessariamente diversa da quella di default ('GAIA'). Chi e' fuori da un gruppo chiuso non puo' leggerne la posta ne' inviarne al gruppo, di cui semplicemente non percepisce l'esistenza. Si permette in tal modo la presenza di un infinito numero di reti parallele che possono evolversi nello stesso spazio funzionale trattando contenuti anche totalmente incompatibili tra loro. Questo aspetto garantisce la sicurezza di eventuali aree "tecniche" che volessero evolversi verso dibattiti troppo pericolosi da svolgere in pubblico, cfr h/p, ma anche quella di chiunque, QUALSIASI siano le sue attivita' o intenzioni. GAIA processa strutture, non contenuti. La posta pubblica e' invece inviata alla User_Id generica "GAIA", che e' nota in qualsiasi nodo di rete. In questo modo si possono strutturare e destrutturare i gruppi privati con la massima dinamicita'. Veniamo ad esempi pratici: a) Nuovo utente auto introdotto L'utente Paper entra in rete per la prima volta in modo del tutto autonomo. Invia posta solo alla User_Id "GAIA" firmandola con la User_Id "Peter Paper". Chi lo trova sgradevole puo' flaggare questa User_Id fuori dalla sua lista di ammissione e scartarne la posta a priori, in una, piu' o tutte le aree. Da quel momento cessa di percepirne l'esistenza. Se cio' avviene il nodo "Peter Paper" ne viene informato. La collaborazione tecnica tra le macchine che costituiscono i nodi fisici non ne viene minimamente intaccata, garantendo sia il diritto ad ammettere in casa propria solo ospiti graditi che la necessita' di ampia collaborazione nel gestire la struttura. b) Nuovo utente presentato. L'utente "Paper Peter" entra in rete presentato dalla User_Id "Peter Paper", gia' nota alla rete. La nuova User_Id viene automaticamente associata a quella di "Peter Paper", il che fa si' che egli possa essere sia automaticamente ammesso nei gruppi chiusi di cui "Peter Paper" fa parte che escluso da quelli di cui "Peter Paper" non fa parte. Ogni nodo sceglie fino a che punto questo automatismo debba "fare di ogni erba un fascio", lasciando totale liberta' di impiego o esclusione dello stesso come stabilito dalle regole di presentazione per PGP. A questo proposito vi invito a leggervi la documentazione del pacchetto. c) Creazione di gruppo chiuso. Almeno due nodi si accordano sulla necessita' di istituire un'area invisibile. A questo punto il pacchetto la istituisce creando una Public Key di default per l'area, per la signature, e quindi una lista di partecipanti. La Public di default viene usata per una prima signature del pkt postale, che verra' poi rifirmato con la 'GAIA' signature. La net intera si occupa di distribuire la posta, senza neppure saperlo. Ogni pkt viene inviato come -sea (parametri PGP) all'intera lista di partecipanti, con -u . Occorrono quindi inserzioni di batch files per criptare e decriptare la posta dei gruppi invisibili. L'eventuale chiusura di queste aree avviene, una volta che divengono deserte, in modo automatico. Non avendo esse lasciato traccia di se' nei nodes che non ne facevano parte, il cambiamento, per la net intera, si limita ad una diminuzione di traffico. Cosa si intende per Risorse Intendiamo per Resource un qualsiasi nodo di rete capace di adeguarsi pienamente allo standard implementando: a) Protocollo di trasmissione bi-direzionale b) Certificazione di Identita' via PGP signature Esiste la possibilita' che all'interno della nuova struttura si mantengano aree 'arcaiche', che possono seguitare a funzionare come set limitati, ma non hanno accesso pieno al nuovo standard. Questo sara' particolarmente agevole all'inizio, cioe' quando l'object-wrapper avra' inglobato il software attuale in un oggetto, senza peraltro mutarne le funzionalita'. In questa fase una Pub-Res puo' tranquillamente continuare a comportarsi come una BBS, fermo restando che gli user di una BBS non sono di alcun aiuto nel diminuire le spese di gestione, al contrario delle An-Res. La SuperClasse Resource Siamo di fronte ad una situazione assai prossima a quella di coloro che si trovano ad affrontare transizioni da sistemi COBOL-based a tecnologie ad oggetti: la mole del software preesistente e' enorme. Esso consente svariate operazioni a cui non si vuole rinunciare, ne' si vuole correre il rischio di una sostituzione globale dello standard. Dal mio personale punto di vista cio' e' un primo passo, che si puo' utilizzare per raggiungere una certezza sulla funzionalita' operativa di alcuni algoritmi di rerouting, ma che non sara' mai in grado di darci il pieno salto di funzionalita' che il modello di GAIA potrebbe offrirci. Tuttavia il tempo a disposizione e' poco, le risorse umane limitate, e la necessita' di implementare velocemente il rerouting esiste. Di fronte a questa situazione la scelta di creare un cosiddetto >>> Continued to next message... --- Blue Wave/DOS v2.20 * Origin: Running FREE bbs, 0141/34481 [SOLO dalle 19:00 alle 09:00] (65:1400/7) Ä CYBERNET: progetto GAIA (65:1600/1.27) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ GAIA.IT Ä Msg : 25 of 28 From : Zeus Kissakie' 65:1400/7 28 Feb 96 09:46:54 To : All 29 Feb 96 20:42:22 Subj : [2/4] Gaia ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ >>> Part 2 of 4... object-wrapper, come da esperienze nella trasposizione object-oriented dei sistemi COBOL mi pare la via piu' praticabile. Un object-wrapper si colloca "al di sopra" del software layer pre-esistente, al posto dei batch files che oggi normalmente connettono le sequenze tra mailers, editors ed environments. In questo modo la prima stesura del wrapper si limita ad integrare tutto cio' che esiste in un common-object senza alterarne le prestazioni, ma istituendo una Public Interface che permanga attraverso le modifiche successive del package. Da qui, in seguito, si partira' ad immettere modifiche strutturali sempre piu' complesse, sino ad ottenere lo standard voluto. Cio' dovrebbe permetterci di "operare a cuore aperto", ovvero di lavorare sul soft che usiamo senza smettere di utilizzarlo. Veniamo ai dettagli di cio' che vogliamo ottenere. Possiamo pensare ad una superclasse (una sorta di protocollo comune) che definisca cio' che qualsiasi nodo possiede e sa effettuare nello standard tecnologico di GAIA. Dal punto di vista pratico cio' ci consente di creare un common background tra tutti i tipi possibili di comportamento dei nodi in GAIA, inclusi quelli che future implementazioni dovessero rendere necessari. La struttura della classe Resource e' grossolanamente indicabile in: ----------------- ------------- --------------- | NetBase M.ger |<-- | Resource | -----------> | Interfaccia | ----------------- ------------- --------------- ----------------- ||| | | | | --------------- | FileBase M.ger|<----+|| | | | +------------> | PGP handler | ----------------- || | | | --------------- ----------------- || | | | --------------- | MailBase M.ger|<-----+| | | +--------------> | Net Address | ----------------- | | | --------------- ----------------- | | | ---------------- | Events M.ger |<------+ | +----------------> | Address M.ger| ----------------- | ---------------- | ---------------- +------------------> | Msg Editor | ---------------- Ove le frecce indicano oggetti posseduti. Le quattro strutture raggruppate a sinistra gestiscono files di dati strutturati a records omogenei, per cui e' pensabile di raggrupparle a loro volta in una SuperClasse che ne faciliti gestione e sviluppo. Sono i metodi che inizialmente saranno implementati attraverso semplici chiamate ai soft gia' esistenti, e che poi verranno mano a mano sostituiti e sofisticati. In dettaglio abbiamo: a) Interfaccia: classe di oggetti capace di identificare e configurare il modem. (Cfr msg da Nuke) b) PGP Handler: classe di oggetti capaci di pilotare PGP in modo da facilitare il rapporto con gli upgrades del pacchetto e da renderne totalmente trasparente l'utilizzo. In pratica implementa una libreria di comandi per PGP. (cfr msgs da Peter e Mainman) c) Net Address: classe di oggetti depositari dell'indirizzo del nodo e della sua identita' in genere. L'indirizzamento utilizzato e' il 5D, per compatibilita' verso gli standard Fido, anche se in pratica l'ultimo campo non viene utilizzato, data la mancata presenza di gerarchie paragonabili a quella BBS/Point. (cfr Mainman) d) Address Manager: classe di oggetti capace di attribuire indirizzi e identita' univoche ai nuovi nodi che entrano in rete. Normalmente non viene utilizzato. Contiene un campo privato che specifica uno dei tre stati seguenti: 1) Active. Ha questo stato il nodo che attualmente svolge le funzioni di Add-res (vedi in seguito) 2) Alert. Stato attribuito al nodo pronto a rilevare le funzioni di Add-Res se necessario. 3) Waiting Stato di tutti gli altri nodi. e) Msg Editor : classe di oggetti che implementa la compressione del quoting e ammette l'inserimento di modalita' grafiche nei messaggi. Il formato e la risoluzione massima dei GIF sono da stabilirsi. Inizialmente la gestione della posta, come si e' detto, restera' invariata. --------------------- f) Data M.ger : superclasse delle successive, stabilisce le modalita' di colloquio tipiche della gestione file. Le funzioni sono specificate piu' che altro per forzare un vocabolario comune, costringendo le classi derivate all'overriding di metodi astratti. Cio' puo' costare alcune difficolta' iniziali, nell'interfacciare il vecchio soft, ma risultera' in una facilita' di implementazione del nuovo standard verso cui siamo diretti. g) NetBase M.ger: classe di oggetti che gestiscono il file contenente la mappa topologica di rete, con le specificazioni sullo stato funzionale, la connettivita' e l'identita' di ogni nodo della rete, nonche' il numero dell'ultimo messaggio immesso per ogni area postale e il numero del ultimo messaggio giunto on-line da quella risorsa. Questi due dati hanno fonti differenti: 1) LastWritten : viaggia sulla echo di sistema e viene immesso da ogni nodo all'atto dello scarico della posta. 2) LastRead : viene aggiornato all'atto del carico fisico della posta. La divergenza tra le due fonti consente di verificare il grado di efficienza dei links attivi, innescando i meccanismi di rerouting in caso di risultati non soddisfacenti. Questi dati sono allocati su una lista dinamica, data la continua variabilita' del formato. Conterra' sempre n record per lista, con n pari alla filesize di Mailbase M.ger. h) FileBase M.ger: classe di oggetti che gestiscono il file contenente la directory di rete, che specifica dove siano reperibili quali files, e una breve descrizione del loro contenuto. i) MailBase M.ger: classe di oggetti che gestiscono il file contenente l'elenco delle aree postali. I primi due record sono fissati rigidamente (hard-coded) per le aree: 0) Traffico di sistema 1) Traffico Files Ogni area postale successiva contiene la descrizione dell'area e tutti i dati necessari alla sua gestione. k) Events M.ger : classe di oggetti che gestiscono il file contenente la lista degli eventi di sistema. Gestire qui significa sia crearli, che valutarne la necessita', che mutarli, che annullarli (vedi ReRouting) Le Classi derivate da Resource, ovvero stati funzionali del nodo In pratica nessun nodo e' soltanto un oggetto della classe Resource. Un nodo e' *come minimo* questo, ma il suo comportamento locale puo' variare di molto, esattamente come possiamo dare per scontato che qualsiasi animale respiri, ma poi bisogna controllare se gli servano branchie o polmoni per farlo. Le classi che sembra attualmente necessario derivare da Resource sono quattro: 1) Pub-Res 2) New-Pub-Res 3) An-Res 4) New-An-Res Se e' evidente che la classe due e la quattro esprimono stati temporanei di un nodo occorre specificare cosa si intenda con le classi uno e tre. Pub-Res: le Public Resources sono nodi che rendono pubblico il loro indirizzo telefonico, e accettano di fungere da dispositivi di storage fisico per la rete. Esse rendono inoltre pubblico un orario di accessibilita'. In cambio di queste loro prestazioni l'intera filosofia di GAIA si occupa di minimizzare le loro spese di gestione del traffico, ripartendolo tra gli utenti anonimi. An-Res: le Anonymous Resources entrano in rete solo come handles, e man- tengono la privacy piu' stretta. Non vanno in answer alle chiamate e si occupano di distribuire sia la posta che la posta di sistema durante le loro operazioni di carico/scarico e-mail e files dalle pub-res. La loro collocazione geografica ed il loro numero telefonico restano ignoti. New-XX : sono stati temporanei che l'oggetto Nodo-GAIA assume al lancio della procedura in attesa di ricevere un indirizzo definitivo dalla Add-Res attiva. In questo stato il nodo puo' solo chiamare l'add-res e fornire i propri dati di ingresso ricevendo un indirizzo valido in cambio, alla cui ricezione si muove verso lo stato definitivo. Topologia Autoorganizzante Come si e' detto GAIA nasce come soluzione al problema delle paralisi causate dal crash di uno o piu' nodi. La soluzione individuata consiste nel dotare la topologia connettiva di network della capacita' di mutare adeguandosi alle circostanze in corso. Cio' richiede che la Network abbia dei sensori che la mettono in grado di processare ricorsivamente il proprio stato di efficienza. Dopodiche' applichiamo all'organizzazione di network il concetto di rete neurale, con esplicito riferimento alle teorie di Hebb sul mutamento di connettivita' nelle strutture cerebrali, ovvero, cio' che funziona meglio acquista sempre maggior peso come struttura associativa, mentre cio' che funziona male viene mano mano a cadere ed essere sostituito. In questo modo la rete non raggiunge mai una configurazione stabile, trasformandosi continuamente per mantenere aderenza sia alle necessita' che gli utenti esprimono nel tempo che allo stato della rete SIP e a quello dell'efficienza hardware della Pub-Res. Le proposte di aree percettive per l'organismo digitale GAIA sono: a) efficienza storica dell'evento ad ogni evento viene associata una media pesata che ne valuta: 1) costo unitario (Tempo/Bytes*Tariffa) 2) convenienza (Percentuale di traffico gestita dalle An-Res sull'evento. Questo para- metro ha valore solo per le Pub-Res) 3) praticabilita' (Numero di retrys per il link) 4) affidabilita' (Numero di crash storici del nodo) b) attuabilita' immediata, ovvero esistenza in attivita' del nodo. Questo e' il parametro che rileva i nodi in crash. Cio' definisce quello che e' attualmente il campo percettivo di un nodo GAIA su ciascuno dei propri eventi. Poiche' la sequenza di eventi di tutta la rete e' nota in ogni nodo della stessa esiste un'altra sequenza percettiva di GAIA che ci interessa: la collocazione della Add-Res. Chiameremo da qui in poi CICLO di GAIA l'elenco completo degli eventi che la costituiscono. E' limitativo pensare che abbia cadenza giornaliera, come vedremo in seguito, l'estensione temporale di CICLO puo' estendersi e restringersi liberamente. Per la precisione CICLO si estende nel tempo quanto la cadenza dell'evento postale meno frequente. Dal punto di vista matematico CICLO e' una relazione in GAIA, ovvero un insieme di coppie ordinate in cui al primo coefficiente compare il chiamante e al secondo il ricevente la comunicazione telefonica. Quindi l'insieme dei chiamanti costituisce il Dominio di CICLO e quello dei riceventi il Codominio di CICLO. Poiche' la frequenza temporale degli eventi e' diversa (cosi' come la modulazione di frequenza delle cellule nervose) ogni nodo avra' un diverso coefficiente di carico connettivo. ------------------------------------------------------------------------------ Files sulla struttura Di seguito descrivo i files che mantengono l'informazione sullo stato di GAIA ad un istante dato, ognuno di questi files esiste localmente su ogni nodo ed e' aggiornato dalla lettura della echo di sistema. NetBase La template di un'oggetto O_Node (che costituisce il contenuto della NetBase) e': Class : (Pub-Res, An-Res); Handle : String[40]; Address : O_Fido_Address { oggetto per la gestione 5D style Fido Addressing } Phone : String[40]; Connectivity : Lista dinamica di oggetti { O_Event, cfr EventBase } LastRead, LastWritten : Liste dinamica di Integers (uno per area echo pubblica esistente) Le liste dinamiche si intendono indicizzate dal numero di area, come ora. Sono metodi di O_Node: IsPublic : Boolean; Is2BeRead : Boolean; { paragone LastWritten vs LastRead } IsCalled : String; { restituisce l'handle } PhoneNo : String; Reaches( ANode : O_Node ) : Boolean; { e' sulla route per ANode } Esistono poi, naturalmente, altri metodi dedicati all'aggiornamento dei campi. Qui ho indicato solo una struttura di massima relativa ai campi di interrogazione possibili. HyperBase Questa superclasse ha il solo scopo di implementare la struttura ipertestuale >>> Continued to next message... --- Blue Wave/DOS v2.20 * Origin: Running FREE bbs, 0141/34481 [SOLO dalle 19:00 alle 09:00] (65:1400/7) Ä CYBERNET: progetto GAIA (65:1600/1.27) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ GAIA.IT Ä Msg : 26 of 28 From : Zeus Kissakie' 65:1400/7 28 Feb 96 09:46:56 To : All 29 Feb 96 20:42:22 Subj : [3/4] Gaia ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ >>> Part 3 of 4... proposta da Mainman, ovvero una struttura ad albero che ammetta links agerarchici predefiniti. Lo metto come SuperClasse di FileBase e MailBase per assicurare la piu' stretta compatibilita' tra l'ipertestualita' di entrambe le gestioni. O_FileBase e O_MailBase sono dunque discendenti di HyperBase, da cui ereditano il comportamento ipertestuale. Hyperbase gestisce indirizzi, con la seguente template: Identity : String[50]; PhisicalID : String[68]; { DOS path or equivalent } UpperLevel : AnHyperBase LowerLevel : Lista dinamica di AnHyperBase SideLinks : Lista dinamica di AnHyperBase Identity : String[15]; { DOS Name } Contents : String[80]; { Abstract } NetLocation : Lista dinamica di Address; A parte SideLinks si tratta di una struttura ad albero identica a quella delle directories DOS. Sidelinks istituisce una sorta di APPEND, ovvero una lista di altre collocazioni fuori sequenza gerarchica che si intendono allacciate al sito corrente. La portabilita' del codice ci richiedera' con ogni probabilita' di sostituire al campo PhisicalID un metodo di calcolo, in modo che ogni piattaforma possa implementare la sua gesione del medium fisico locale, mantenendo un'intyerfaccia compatibile a tutti i sistemi. La seconda zona di campi definisce un DOS_Name locale, un abstract dell'item scritto dal primo creatore dell'area postale o file e una lista di disponibilita' lungo la matrice. FileBase Discendente di HyperBase, FileBase aggiunge alla sua eredita' una lista dinamica di file Headers. La template di O_FileHeader e': Size : LongInteger; Poiche' ogni spostamento di File viene segnalato dalla mail di sistema tutti sanno sempre dove si trovi qualsiasi file. (cfr. System Mail) MailBase Altro discendente di HyperBase. La sua template e': Rules : ( System, Echo, GIFEcho, Matrix ); Pvt : Boolean; I campi System bloccano l'editing. GIFEcho indica le echo annesse alle aree echo testuali. Il campo Pvt dice se sono ammessi msgs privati nell'area in questione. EventBase Gli oggetti O_Event descrivono eventi di sistema. La loro template e': Last : Date, Time of last occurrance. Timing : Minutes before next occurrance. Target : Address; Cio' ci consente di elencare in modo pratico tutti gli eventi che compongono la topologia di GAIA. Sono noti a tutta la rete quelli relativi alle Pub-Res, mentre la An-Res conservano la massima imprevedibilita' di comportamento. Il campo Last viene updatato automaticamente dal sw residente sul nodo senza bisogno di alcun msg di conferma. Appena un crash viene rilevato il nodo che lo rileva informa la net via System Mail (vedi) della mancata effettuazione di un evento, e l'update viene riportato indietro su tutte le event-bases distribuite. Le probabilita' che entrambi i nodi interessati da un evento vadano in crash simultaneamente sono tanto basse da poter escludere la cosa, ed in ogni caso la rilevanza dell'imprecisione ai fini pratici sarebbe minima. Rerouting Crash-Recovery La nostra filosofia base include la suddivisione di due ruoli (Pub-Res e An-Res) che hanno comportamenti e finalita' di utilizzo differenti, dunque ci occuperemo innanzitutto di mantenere coerente la struttura di quella che sara' la "back-bone" di GAIA: la topologia degli eventi tra Pub-Res. Cio' impone il vincolo che ogni nuova scelta di rerouting tra Pub-Resources sia agibile se e solo se mantiene la net "chiusa". Facciamo un esempio: P1<------------------->P3 <--------->P5<-------->P6 ^ ^ ^ ^ | | | | P2<-----+ +----------->P4<------+ P7<-+ Poniamo che questa topologia perda funzionalita' (aka vada in crash) al nodo P3. P5 resterebbe isolato, e dovrebbe scegliere un evento sostitutivo, come pure P6 e P7. Gli eventi P5<>P6, P5<>P7 e P6<>P7 non chiuderebbero la net, in quanto la posta emessa dal gruppo P5/6/7 raggiungerebbe il gruppo P4/1/2. Si tratta quindi di sapere se un crash ha prodotto due insiemi sconnessi oppure no, e di reagire di conseguenza. A cio' e' deputato un algoritmo di certificazione che risiede on-line su tutte le risorse, ovvero un Metodo della Superclasse Resource detto RouteIsValid, che restituisce un valore boolean. Il ruolo delle An-Res, viceversa, e' quello di massima liberta', in tutto e per tutto assimilabile a quello degli insetti nell'impollinazione. Le An-Res vanno a leggere la posta presso una Pub-res. Nel farlo comunicano lo stato di aggiornamento della loro msg-base e travasano cio' che manca nel senso corretto. Nulla del loro comportamento e' data per scontato, semplicemente GAIA si mette in grado di sfruttare "qualsiasi" evento. Il loro metodo RouteIsValid restituisce sempre True. L'algoritmo di controllo per il rerouting delle Pub_Res Siamo giunti ad una prima stesura di algoritmo per il metodo RouteIsValid delle Pub-Res. E' probabile che sia migliorabile e si attendono suggerimenti. In pratica si tratta di utilizzare le informazioni sugli eventi contenute nella NetBase, assegnando la situazione ipotetica in cui ogni nodo abbia scritto uno e un solo nuovo messaggio. Alla fine del ciclo degli eventi i messaggi presenti su ogni nodo saranno maggiori o uguali a 1, e se il crash ha spezzato la rete ci saranno due famiglie di risultati. Vediamo un esempio pratico: P1<...................>## <.........>P5<-------->P6 ^ ^ ^ ^ | | : | P2<-----+ +----------->P4<......+ P7<-+ Il crash della Pub-Res P3, come nell'esempio precedente, ha isolato la net in due insiemi sconnessi: Isola1 : { P1, P2, P4 } Isola2 : { P5, P6, P7 } Contando i nodi rimasti attivi dopo il crash di P3 si scopre subito che sono in numero pari (ovvero 6 nel nostro esempio). Cio' rende possibile la situazione in cui le isole siano di pari dimensioni, prontamente visualizzata nel nostro esempio. A cio' si ovvia con un Dummy-link, ovvero inserendo un nodo addizionale (immaginario) per riportare il conto ad un numero dispari. Il Dummy deve avere un solo evento di connessione bidirezionale su UN SOLO NODO REALE. Se ne avesse su piu' nodi potrebbe, infatti chiudere la net. P1<...................>## <.........>P5<-------->P6 ^ ^ ^ ^ | | : | P2<-----+ +----------->P4<......+ D<--------->P7<-+ La scelta del nodo a cui connettere il Dummy non e' influente sul risultato, e quindi puo' essere condotta in qualsiasi modo. Inoltre e' possibile evitare l'inserzione vera e propria del link partendo direttamente dal risultato della sua presenza, ovvero settando a due il numero di messaggi presenti su uno qualsiasi dei nodi. A questo punto, una volta che si fa girare la matrice degli eventi per il tempo indicato da CICLO (vedi sopra), si ottengono due famiglie di risultati: Isola1 : { ˇ x / x = 3 }; ovvero ( P1, P2, P4 ) Isola2 : { ˇ x / x = 4 }; ovvero ( P5, P6, P7 ) A questo punto basta fissare la regola per cui qualsiasi mossa setta True il metodo RouteIsValid se e solo se e' riferita a due elementi che non appartengono alla stessa isola. ------------------------------------------------------------------------------ Ottimizzazione di spesa Tra le sofisticazioni pensabili per l'algoritmo c'e' la possibilita' di filtrare ulteriormente le mosse legali, ovvero solo quelle che chiudono la net per le Pub-Res e tutte senza limiti per le An-Res. Questo filtro e' ottenibile scegliendo un ordinamento che faccia emergere gli eventi che hanno un costo/byte minore. Le Pub-Res tengono conto anche, qualora l'evento sia gia' stato utilizzato in tempi precedenti, di quanta convenienza ci fosse stata nell'utilizzarlo, ovvero di quanto del lavoro sull'evento venisse svolto dalle An-Res. Ottimizzazione di traffico Come secondo criterio di scelta (a parita' di criterio economico), si puo' utilizzare il rerouting verso il nodo che appare BUSY meno di frequente, ridistribuendo il traffico in modo omogeneo. ----------------- FILE REQUESTS La file request tradizionale e' diretta ad un nodo. L'idea di GAIA e' quella di rendere il materiale accessibile nonostante il suo essere sparso lungo i nodi. Se questo fosse implementato su strutture molto piu' grandi di Cybernet andrebbero probabilmente cercate strade alternative, ma al nostro livello di complessita' la cosa e' ancora gestibile. All'eventuale crescere delle nostre dimensioni si potranno cercare soluzioni nuove. E se, come credo, sara' possibile farlo senza alterare l'interfaccia delle classi questi mutamenti saranno del tutto trasparenti. Questo e' il dominio dei Database distribuiti, un campo in cui la ricerca e' apertissima a tutt'oggi, per cui ci possiamo aspettare tools molto piu' efficienti del nostro nel giro di pochi anni o mesi. A questo scopo l'intero colloquio relativo al movimento dei files, nonche' il movimento vero e proprio, viene gestito sull'area postale 1 (traffico files), in modo da isolarne le prestazioni ed evitare complicazioni in caso di future necessita' di modifica. Ottimizzazione dei percorsi Se alcuni nodi emettono una file Request sul canale postale 1 (traffico files) verso un dato address, quest'ultimo tratterra' la richiesta piu' vicina, emettendo matrix verso i piu' lontani per informarli dell'arrivo di una copia del file in posizione piu' conveniente ad una certa data. La file request viene evasa quattro giorni dopo, a meno che non sia in modalita' diretta, ovvero che non si tratti di andare a linkare l'address e dnlodare il file come si fa ora, e si potra' fare anche in seguito. Allo scadere del quarto giorno dalla prima richiesta il file viene caricato dalla res piu' vicina sia alla sorgente che agli altri richiedenti. E' possibile che piu' di un trasferimento sia necessario, nel caso di richieste ad un nodo in posizione centrale che provengano da Nord e da Sud. Richieste periodiche E' possibile indirizzare domande per una distribuzione di periodici, ovvero di files che vengano revised o ripubblicati, come nel caso di CUD, Phrack, Nodelists, etc. (cfr system Mail) Soluzioni Tecniche Le prime soluzioni tecniche per implementare lo standard GAIA sono di seguito listate. HandShaking Rimane EMSI, viene specificato "GAIA" nel campo capability. Addressing Indirizzamento Fido-Compliant in 5D. zone:net/node.point.domain Il domain di GAIA e' unico: gaia.net, il campo point ha valore costante 0 per tutti i nodi GAIA. Non-GAIA systems Se il chiamante non fa parte di GAIA la sessione procede normalmente. I sistemi non-GAIA ( sistemi Fido ) possono essere solo downlink o gateways. Viene inviata normalmente la netmail e i pacchetti di posta. Per semplicita' puo' essere supportato solo ZedZap; solo in un secondo tempo si implementeranno i protocolli piu' vecchi. Cio' di fatto rende GAIA non Fido-compliant, sebbene all'atto pratico non compaiano problemi, per il fatto che tutto il software recente utilizza ZedZap. ------------------------------------------------------------------------------ Scambio netmail di controllo La tecnologia Fido limita i trasferimenti possibili durante una sessione. In pratica il chiamante prima trasmette e poi riceve. Tra i sistemi GAIA e' definito un tipo di sessione esteso, in cui la direzione del trasferimento puo' variare piu' volte. L'utilizzo di ZedZap e' valido anche in questo caso. >>> Continued to next message... --- Blue Wave/DOS v2.20 * Origin: Running FREE bbs, 0141/34481 [SOLO dalle 19:00 alle 09:00] (65:1400/7) Ä CYBERNET: progetto GAIA (65:1600/1.27) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ GAIA.IT Ä Msg : 27 of 28 From : Zeus Kissakie' 65:1400/7 28 Feb 96 09:46:56 To : All 29 Feb 96 20:42:22 Subj : [4/4] Gaia ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ >>> Part 4 of 4... Ad inizio sessione avviene lo scambio della netmail di controllo. I pacchetti non sono compressi o criptati ma solo firmati, in modo da velocizzare le operazioni. E-mail Nello standard GAIA l'efficienza della e-mail ha un ruolo fondamentale, per cui sono state poste molte precauzioni nell'assicurarne l'efficienza. Il fatto di utilizzare un canale tecnico comune sia all'efficienza di sistema che alla prestazione del servizio ci mette in condizione di restringere le aree fonte di possibili problemi all'efficienza della posta. Cio' puo' ridurre il tempo di beta-testing e la quantita' di lavoro per il team di sviluppo. Univocita' e rintracciabilita' La PGP signature apposta su ogni messaggio ci assicura sulla sua provenienza, provvedendo inoltre a datarne la spedizione. Assicurarci sulla sua provenienza significa soltanto sapere che la Res che lo ha emesso ne e' effettivamente responsabile, e non dove la res si trovi o a chi fisicamente corrisponda. La PGP signature non e' utilizzabile per rintracciare la provenienza della e-mail. System Mail I pacchetti di colloquio servono ad aggiornare il database disponibile su ogni nodo, aggiornando GAIA sul proprio stato. Il formato dei pacchetti resta, per ora, da definire. Si tratta comunque di un semplice protocollo, che non presenta problemi di sorta, una volta raggiunto l'accordo sulla struttura di base. Il messaggio L'identificazione di ogni messaggio in modo univoco, che e' una caratteristica fondamentale per l'autocontrollo di GAIA, ha ricadute positive anche nell'utilizzo pratico: 1) Diviene possibile comprimere il quote in una Kludge che indichi soltanto il messaggio di provenienza, startByte e lastByte. Cio' diminuisce di molto i volumi in trasmissione. 2) Diviene possibile aggiungere un'area echo di supporto grafico per la mail normale, in modo che ogni area abbia il proprio canale grafico disponibile. I GIF (ridotti in formato e uuencodati) sono trasmessi lungo questo canale di appoggio, mentre una kludge nel body-msg provvede a identificarne la posizione. Il punto 1 consente la creazione di un apparato di multiquote, per cui sia possibile utilizzare TUTTI i messaggi dell'area in quoting e non solo quello a cui si risponde, implementando una sorta di delayed-chat esteso a piu' persone. Viene inoltre soppressa la definizione automatica del Soggetto, che spesso si rivela fuorviante nei risultati, in quanto messaggi ormai completamente fuori contesto vengono costantemente collegati al tema su cui era nato il discorso. Ovviamente il punto 2 parte dal presupposto di realizzare un editor grafico e una possibilita' di configurare la grafica "fuori" dal proprio nodo. (cfr Tempi di realizzazione) L'albero ipertestuale Come da struttura proposta nel dibattito viene implementata una stuttura ad albero con collegamenti ipertestuali: +-----------------> S11<-----------------------------------+ | | S1+-----------------> S12 +--------------->S131 | | | | +-----------------> S13 ---+--------------->S132 | | | +--------------->S133-----------+ Ovvero e' possibile definire collegamenti esterni alla gerarchia per connettere aree altrimenti lontane lungo criteri differenti. Si possono eventualmente studiare piu' paths associativi simultanei che consentano di strutturare l'ipertesto anche localmente. [continua...] Peter Paper 45:1917/2 cya Z@K ---------------> http://www.alpcom.it/infonet ... I giornali esagerano... io dicevo dieci... dieci posti di lavoro... --- Blue Wave/DOS v2.20 * Origin: Running FREE bbs, 0141/34481 [SOLO dalle 19:00 alle 09:00] (65:1400/7) Ä CYBERNET: Conferenza Cyberpunk (65:1600/1.27) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ CYBER_PUNK Ä Msg : 3151 of 3309 +3239 From : Satchmo 65:1400/6 20 Jun 96 19:22:06 To : All 24 Jun 96 19:59:24 Subj : Lovelock, Asimov e Gaia ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ *** SATCHMO SALUTA ALL Leggendo a sprazzi "La new age" di A.de Luca, mi e' venuto in mente un parallelo tra l'"ipotesi Gaia" di Lovelock e "L'orlo della Fondazione" di Asimov: vi ricordate Pelorat e Trevize alla ricerca della Seconda Fondazione e della Terra, del pianeta Gaia e i suoi abitanti che sono in collegamento empatico gli uni con gli altri e con tutti gli altri esseri viventi e non viventi del pianeta? Beh.. l'Ipotesi Gaia di Lovelock parla piu' o meno della stessa cosa... Il romanzo di Asimov e' stato scritto nel 1982: sarebbe interessante scoprire in che anno e' stata scritta "l'ipotesi Gaia" da Lovelock (il suddetto libro la cita ma non dice la data, anche se un riferimento fa pensare al 1986) per vedere quale pensiero ha influenzato l'altro. Se qualcuno di voi ne sa di piu'... aspetto impaziente notizie... Intanto riporto il brano dal libro dove si parla di questa Ipotesi Gaia: ------------------------------ inizio testo ----------------------------------- L'ECOLOGIA DELLA NEW AGE Nel vasto movimento di sintesi spirituale sviluppato dalla N.A. confluiscono ancora nuove visioni di espansione della consapevolezza e terapie dell'anima collegate a una nuova *coscienza planetaria*. Lo scopo dichiarato di questa concezione e' ricondurre a unita' valori spirituali, filosofici e scientifici in una *ecologia mistica* che riesca a fondere le nuove scienze biologiche e geografiche in una visione magica del mondo. Tra le varie manifestazioni consideriamo l'*ipotesi Gaia* di Lovelock, il riemergere dell'archetipo della grande madre [...] L'IPOTESI GAIA La Geofisiologia e' l'ultima arrivata nelle scienze ecologiche d'avanguardia, che gli scienziati della vita hanno elaborato per studiare le condizioni di sussistenza del nostro pianeta. L'Ipotesi Gaia e' stata elaborata da J.Lovelock scienziato, biologo e inventore inglese, che ha prestato la sua opera di consulente alla Nasa per molti anni con competenze nel campo della medicina, della fisica e della cibernetica applicate alla geologia. [...] L'I.G. [...], riferendosi al mito greco della Grande Madre Gaia, venerata come archetipo della vita e della procreazione delle specie, afferma che ogni mancanza di rispetto o alterazione dei preziosi equilibri vitali del nostro pianeta ha conseguenze profonde sull'intero habitat fisico e biologico delle specie viventi, come negli ambienti che collaborano alla sua esistenza. La teoria Gaia avanza l'ipotesi che il clima della terra e la struttura biochimica della superficie terrestre siano controllati direttamente dalla vita e dalle interazioni delle piante, degli animali e da altri organismi che la abitano. Alla luce di questa ipotesi, il nostro pianeta e' tutt'altro che una sfera inorganica di acqua e terra, [...] si tratta invece di un superorganismo biologico, capace di autoregolazione e persino di difesa rispetto ad eventuali fattori che possano minacciarne l'equilibrio [...]. La Terra e' ritenuta da Lovelock come un unico grande sistema che si muove nello spazio cosmico, seguendo leggi precise di vita e di equilibrio. [...] "...la materia vivente e non vivente, il se' e l'ambiente, sono accuratamente interconnessi. In questo senso, una visione secondo Gaia e' potenzialmente molto piu' forte delle ideologie dell'egoismo" (Sagan-Margulis, Gaia and the evolution of machines, 1986, p.13) L'effetto Gaia potrebbe allora farsi sentire con conseguenze di proporzioni gigantesche proprio sulla specie umana. Per troppo tempo l'uomo ha strumentalizzato la natura [...], adesso il pianeta e' sul punto di riaffermare la propria autonomia. -------------------------------- fine testo ----------------------------------- Note: il testo in corsivo e' preceduto e seguito da * il testo tagliato e' indicato da [...] Azveduma! ---><--- Satchmo ... CyberWhore for pleasure contact CNET144-782-918-9818 --- Blue Wave/RA v2.12 [NR] * Origin: ZERO! 011,6507540 24h/day (65:1400/6)