Argomenti trattati: reti neurali, network, interfacce autoorganizzanti
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 proposta da Mainman, ovvero una struttur 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.
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.
GAIA come organismo digitale
Rendere una net il piu' possibile autossuficiente, ed escludere la
possibilita' che esista controllo di uomini su uomini significa spostare
le funzioni di controllo lontano dalle persone.
Ma il bisogno di controllo rimane. A questo scopo possiamo equiparare una
rete in standard GAIA ad un animale digitale, autocosciente ed
autosufficente.
Tra le capacita' di GAIA quella fondamentale e' la percezione di se'.
Tutto il lavoro che viene fatto sul re-routing e' il lavoro che assicura
la sopravvivenza di GAIA, e questo lavoro si basa tutto sulla correttezza
delle impressioni che GAIA ha di se'.
Struttura ecologica
Se pensiamo a GAIA come ad un organismo pluricellulare vediamo una
societa' composta da due classi di individui: An-Res e Pub-Res.
Le prime hanno la funzione di "impollinare" le seconde.
Credo la metafora sia sufficiente ad esplicarne la filosofia.
La Add-Res: DNA di GAIA
La Add-res e' un comportamento che qualsiasi Pub-Res puo' mettere in
atto, prima o poi. Si tratta di rispondere alle chiamate provenienti da
nuovi nodi che chiedono validazione ed attribuire loro un indirizzo
valido, provvedendo ad aggiornare il database.
Molto del suo ruolo e' stato ridimensionato dall'ingresso dell'algoritmo
di controllo topologico che impedisce a spezzoni della net di staccarsi.
La sua funzione di DNA puo' estendersi in varie direzioni: potrebbe
prendere decisioni automatiche di qualsiasi genere, se ci servissero.
Tempi e criteri di implementazione
Il discorso, una volta definito COSA vogliamo, non puo' che spostarsi sul
COME realizzarlo. E' evidente che tempi e risorse umane non sono
infinite, quindi occorrera' fissare con attenzione una lista di priorita'
di realizzazione che ci consenta di lavorare con calma e senza drammi.
Object-wrapper
Come si e' gia' detto la similarita' con le eredita' degli ambienti COBOL
rende interessante la soluzione Object-wrapper, ovvero la definizione
della SuperClass Resource, che ci permetta di virare, almeno formalmente,
ad oggetti l'intera Fido-Tech esistente.
Lo scopo di questo primo step sta tutto nel cambiare la forma del
software senza alterarne le funzionalita'.
A questo scopo occorre definire bene la struttura comune a qualsiasi
implementazione pratica di BBS o point attuale. Il tutto puo' ridursi ai
batch di struttura da chiamarsi tramite delle shell a sistema. La cosa
importante e' delineare un'interfaccia che si mantenga stabile nel tempo
e dietro a cui poter innestare le novita' senza traumi.
Linguaggio di sviluppo
A grande maggioranza e' stato scelto il C++, con indicazioni riguardo a
GNU come miglior compilatore ai fini della portabilita' del codice
generato.
Modularita'
Gli step di realizzazione proponibili potrebbero essere:
1) Object-wrapper
2) Implementazione delle utilities di supporto quali PGP
handler, aree riservate per traffico Files e msgs di
sistema.
3) Implementazione del traffico di aggiornamento dei database
4) Implementazione del rerouting
5) Implementazione della possibilita' di creare gruppi
invisibili (solo a rerouting certificato)
6) Implementazione della struttura ipertestuale
7) Implementazione dell'editor grafico
La modularita' e' stata strutturata in modo da garantirci il massimo di
sicurezza nelle fasi di lavoro.
... La stanza era vuota,ma un miagolio rompeva il silenzio....
Blue Wave/RA v2.12 [NR]
* Origin: ECN TORINO 39-11-6507540 (45:1917/2.0)
@PATH: 1917/2 1 9/1 1100/1