Argomenti trattati: reti neurali, network, interfacce autoorganizzanti
"GAIA"
Di Peter Paper
Messaggio tratto dall'area Cyberpunk del network telematico Cybernet
(3227) Fri 1 Oct 93 16.28
By: Peter Paper
To: All
Re: GAIA - File 1/9
St:
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 Peter 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 <mittente>. 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
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
mantengono 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
parametro 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.
(segue)