Alle otto di sera del 2 Novembre 1988,
mimsy.umd.edu, un server del Dipartimento di Informatica dell'Università
del Maryland, Stati Uniti, stava ricevendo un messaggio di posta elettronica.
Un'operazione apparentemente innocua, che veniva svolta parecchie centinaia
di volte al giorno. In realtà il mittente stava sfruttando un bug
del programma sendmail per riuscire a guadagnare l'accesso come superutente.
Dopo aver violato i meccanismi di protezione, un programma si inserì
furtivamente nel sistema, cancellò accuratamente le tracce del proprio
passaggio e si mise subito in cerca di nuove macchine da infettare. Era
nato il primo virus su Internet: quello che sarebbe stato conosciuto in
seguito come Internet Worm riuscì a diffondersi negli USA, dalla
costa orientale a quella occidentale, prima che qualcuno potesse rendersi
conto di cosa stava accadendo. Come conseguenza, un buon numero di centri
di calcolo negli Stati Uniti rimasero bloccati per qualche giorno ed a
parecchi amministratori di sistema venne un gran mal di testa...
L'Internet
Worm è stato il primo programma in grado di "propagarsi"
autonomamente su una rete geografica di computer. Sebbene non fosse stato
costruito per produrre dei danni permanenti, rese le macchine infettate
inutilizzabili per qualche tempo, e la sua ingombrante presenza non fu
certamente gradita. Dal 1988 in poi la gente si rese conto come Internet
potesse rappresentare una minaccia alla sicurezza delle reti informatiche,
associando ai cosiddetti "vermi" una valenza decisamente minacciosa:
perciò si moltiplicarono gli studi sui meccanismi per proteggersi
da questo tipo di attacchi. Ma in questo articolo non parleremo di sicurezza
informatica. Infatti, dopo un po' di anni da quel fatidico 1988, la tecnologia
sembra oggi essere matura per consentire la realizzazione di programmi
che, come l'Internet Worm, possono spostarsi autonomamente da una macchina
all'altra su Internet, ma per scopi costruttivi e, soprattutto, senza porre
problemi di sicurezza. Questi programmi sono noti con il nome di Agenti
Mobili.
Esecuzione
di programmi remoti
Mandare in esecuzione un programma su una macchina
remota, cioè su una macchina diversa da quella su cui si sta operando,
non è certo una novità. Nel momento stesso in cui state leggendo
questa pagina, voi state facendo qualcosa del genere: la richiesta inoltrata
dal vostro browser è arrivata sulla macchina www.programmers.net
che, per gestirla, ha lanciato un programma apposito, il demone httpd,
il quale ha letto dal disco remoto il file che voi avete richiesto
e ve lo ha inviato (le cose in realtà probabilmente sono un po'
diverse ed un po' più complesse, ma il concetto base è questo).
Pertanto si può dire che, in qualche modo, avete "comandato"
l'esecuzione di un programma su una macchina diversa da quella su cui operate.
Lo stesso tipo di operazioni avviene in genere ogni volta che si usa un
servizio di Internet, come e-mail, FTP, Telnet e così via: ogni
richiesta di servizio attiva un particolare programma in grado di gestirla.
Questo primo modello di esecuzione remota ha evidentemente dei vincoli
strettissimi: non si può scegliere di mandare in esecuzione un programma
arbitrario, ma ad ogni tipo di servizio corrisponde quel ben preciso programma
che è stato installato dall'amministratore del sistema sul server,
e solo quello. Per passare a qualcosa di più flessibile, nel mondo
UNIX, con i servizi Telnet e rlogin, è possibile eseguire programmi
arbitrari su una macchina remota. Tuttavia questo tipo di operazione si
configura di fatto come l'implementazione di un "terminale" virtuale,
cioè è come se venissero stesi dei lunghissimi "cavi
virtuali" tra la tastiera ed il monitor dove si trova l'utente e la
macchina remota. I programmi lanciati sono quelli già pre-esistenti
sul disco del server, dove la loro esecuzione rimane confinata.
Con gli applet di Java ed i programmi in JavaScript o VisualBasic,
integrati nelle pagine WWW, la situazione diventa un po' più interessante:
infatti gli eseguibili non esistono preventivamente sul client,
ma vengono prelevati e mandati in esecuzione "in un colpo solo".
Tuttavia la loro esecuzione rimane ancora confinata in ogni singola macchina
che ospita il browser e non vengono mai eseguiti sul server,
dove esistono solo in forma di codice "latente". Gli Agenti Mobili
sono una cosa ben diversa: essi sono programmi in grado di navigare autonomamente
su Internet. Possono decidere, in un certo momento, di trasferirsi su una
macchina diversa da quella su cui stanno girando, e proseguire su di
essa la loro elaborazione partendo dal preciso punto in cui erano arrivati.
A
cosa servono gli Agenti Mobili?
Probabilmente molti di voi in questo
momento si stanno chiedendo quali sono i possibili usi degli Agenti Mobili.
Prima di affrontare l'argomento con un taglio più tecnico, concediamoci
una divagazione discorsiva e facciamo qualche esempio... Ricerca di
informazioni. Internet è un vastissimo insieme di informazioni
e risorse, in continua crescita e sempre più difficile da gestire
e da usare. Se fino al 1994/1995 era abbastanza facile cercare e trovare
informazioni per mezzo dei search engines, ultimamente le classiche
strategie di ricerca per "parola chiave" stanno dimostrando la
loro inadeguatezza: agli utenti finali è richiesta sempre più
abilità e, soprattutto, tempo per trovare quello che cercano. Prima
o poi questo compito diventerà troppo pesante per poter essere gestito
esclusivamente da un essere umano. Agenti Mobili di Ricerca opportunamente
programmati possono svolgere questo compito autonomamente ed in maniera
asincrona: possono continuare a lavorare anche quando il loro "padrone"
si è scollegato dalla rete ed ha spento la sua macchina, e produrre
i loro risultati, se necessario, anche parecchi giorni dopo essere stati
attivati. Sul loro cammino possono incontrare altri Agenti Mobili che perseguono
lo stesso fine ed eventualmente mettere in contatto tra loro i rispettivi
"padroni" umani. Possono clonarsi ed applicare strategie del
tipo divide et impera per produrre più velocemente i loro
risultati. C'è addirittura chi sta studiando l'applicazione di algoritmi
genetici e di artificial life per favorire la "procreazione"
degli Agenti Mobili di Ricerca più efficienti: in questo modo essi
sarebbero in grado, col progredire delle successive "generazioni",
di "imparare" con l'esperienza quale sia il miglior modo di servire
il loro padrone...
Motori
di Ricerca distribuiti.
Anziché esplorare Internet da un unico
sito centralizzato (come Lycos od Altavista), i motori di ricerca basati
su Agenti Mobili potranno muoversi attivamente attraverso i vari siti WWW,
raccogliere le informazioni trovate in loco e poi riportarle su un database
centralizzato, con due evidenti vantaggi: la riduzione del traffico di
rete (l'indice di un sito WWW è generalmente più piccolo
dei contenuti del sito stesso) e la ripartizione del carico computazionale
sull'intera Internet.
Ubiquitous
computing.
Le applicazioni installate da un utente potranno seguirlo
nel caso la sua login venga trasferita su un'altra macchina. Questa
può essere vista come una futuristica estremizzazione del concetto
di Zero Administration Computing, descritto nel numero di Dicembre di Mokabyte.
Amministrazione
remota di sistemi distribuiti.
Opportuni Agenti Mobili potrebbero essere
spediti in giro per Internet o per la propria Intranet privata per trovare,
segnalare e gestire da un'unica postazione problemi di varia natura (stampanti
senza carta, interconnessioni non funzionanti, programmi mal configurati
e via dicendo), proprio come, per esempio, le compagnie di telecomunicazioni
mandano i propri ispettori in carne ed ossa a verificare lo stato delle
linee telefoniche.
Messaggi
Interattivi.
Sarà possibile spedire dei messaggi di posta elettronica
che interagiscono in maniera più diretta con i destinatari. Pensiamo
per esempio ad un wizard che gestisca una ricerca di mercato
facendo domande mirate, magari differenziandole in base alle risposte già
ottenute, oppure ad una segretaria elettronica che interroghi ciclicamente
i membri di un gruppo di lavoro per fissare la data di una riunione.
Piazzista
Virtuale(!).
Pensiamo ad un rappresentante di elettrodomestici che,
per vendere la sua merce, contatta i potenziali clienti con un suo Agente
Mobile. Può estendere il raggio d'azione del suo mercato a tutto
il mondo (altro che globalizzazione dell'economia...) e magari andare esplicitamente
in cerca delle persone che, in qualche modo (per esempio lanciando un loro
personale Agente Mobile), hanno comunicato di essere intenzionate ad acquistare
un elettrodomestico. Tutto ad orario continuato, 24 ore su 24, anche mentre
il rappresentante "umano" sta tranquillamente dormendo nel suo
letto... L'Agente Mobile può essere programmato per apparire sullo
schermo con le sembianze di una persona "virtuale", in grado
di parlare e interagire con l'utente, una sorta di Max Headroom, tanto
per intenderci. Potrebbe essere in grado di farci vedere una rappresentazione
in Realtà Virtuale dell'oggetto che ci vuol vendere e magari anche
in possesso di una strategia di vendita (ad esempio, potrebbe essere opportunamente
istruito per offrire delle riduzioni di prezzo ai clienti più ostinati).
Una volta raggiunto un accordo, l'Agente Mobile potrebbe concludere l'acquisto
"in linea", via carta di credito e senza alcun rischio (già
oggi molti siti WWW sono protetti da opportune tecniche crittografiche).
Debugging
di applicazioni.
Supponiamo che alcune applicazioni in fase di beta
testing vengano distribuite sotto forma di Agenti Mobili: nel caso venga
rilevato un errore, anziché generare un mero report da rispedire
al programmatore, l'applicazione potrà clonarsi e spedire indietro
una copia "congelata" di se' stessa! In questo modo il programmatore
avrà a disposizione molte più informazioni per il debugging.
Terminata questa panoramica, se a questo punto avete deciso che gli Agenti
Mobili vi interessano, procediamo e vediamo come funzionano.
Un
esempio banale
Un Agente Mobile, per definizione, è un "programma
che può spostarsi tra varie macchine conservando il suo stato",
dove con stato si intende l'insieme dei valori assunti dalle strutture
dati del programma. Perché si possa parlare di Agenti Mobili è
fondamentale questa conservazione dello stato, che è la loro "memoria
a lungo termine" (che qualcuno chiama ironicamente "suitcase",
cioè "valigia"). Da questo punto di vista, l'Internet
Worm non poteva essere considerato un Agente Mobile: era sì in grado
di replicarsi da una macchina all'altra, ma di questo fatto non aveva "coscienza",
perché ogni volta che arrivava su un nuovo computer ricominciava
la sua esecuzione dall'inizio (lo stato posseduto dall'istanza che generava
una copia non veniva propagato nella copia generata). Per capire meglio
questo concetto, facciamo un esempio banale: supponiamo di avere un programma
che si limita ad incrementare una variabile chiamata counter, ed ogni tanto
decide di spostarsi su una macchina diversa. In linguaggio C questo programma
potrebbe essere qualcosa del genere:
void main()
{
int stay_here = 10;
int counter = 0;
while (stay_here--)
counter++;
/* migrate() fa spostare il programma su una nuova macchina. */
migrate(new_IP_address);
}
Questo non è un Agente Mobile: infatti,
ogni volta che raggiunge un nuovo computer, ricomincia a contare partendo
da zero, "dimenticando" a che punto era arrivato sulla macchina
precedente. Se supponiamo che, passando alla funzione migrate()
il valore del contatore, essa sia in grado di spedirlo alla prossima macchina,
sulla quale sarà possibile recuperarlo, per esempio, con una funzione
get_previous_value(), allora otteniamo un primitivo Agente Mobile:
void main()
{
int stay_here = 10;
int counter = get_previous_value();
while (stay_here--)
counter++;
migrate(new_IP_address, counter);
}
Lo
stato del programma (in questo semplice caso costituito solo dalla variabile
counter) è ora correttamente preservato. Supponendo di sostituire
l'incremento di counter con un calcolo più sofisticato (ed utile!),
il significato di questo Agente Mobile potrebbe essere quello di eseguire
dei conti ripartendo il carico computazionale su più macchine, ad
esempio spostandosi di volta in volta su quella più "scarica".
Oppure, supponendo che il programma rappresenti un calcolo che richiede
parecchi giorni per completarsi, l'Agente potrebbe essere in grado di abbandonare
la macchina su cui risiede nel caso questa debba essere fatta bootstrappare
per ragioni di manutenzione.
Requisiti
tecnologici
Ovviamente la parte più interessante (e difficile!)
del programma consiste proprio nell'implementazione delle funzioni migrate()
e get_previous_value(). Esse devono ordinatamente: ."preparare
la valigia", cioè mettere da parte l'insieme delle variabili
che rappresentano lo stato del programma; .spedire il codice eseguibile
dell'agente e la sua "valigia" sulla macchina-destinazione; .una
volta a destinazione, "aprire la valigia" e ripristinare lo stato
del programma; .far ripartire il codice eseguibile. Ovviamente tutto ciò
implica la presenza su tutte le macchine coinvolte di un programma di supporto
(agent server) che sia in grado prima di tutto di ricevere gli agenti,
e poi di coordinare tutte queste operazioni. Un primo grosso problema da
risolvere è la compatibilità del codice, che deve
essere eseguibile su tutte le macchine visitate, anche se di diversa architettura.
L'Internet
Worm poteva girare solo su due architetture (Sun3 e VAX) e viaggiava portandosi
dietro entrambe le versioni del codice eseguibile, più il sorgente
di un piccolo programmino di lancio che veniva ricompilato su ogni macchina
infettata... Un approccio decisamente complesso ed impraticabile per programmi
più complessi. La miglior soluzione è utilizzare un linguaggio
interpretato, sia esso un semplice script, oppure un qualcosa di
più raffinato come Java. La seconda questione da affrontare è
la "preparazione" e l'"apertura" della valigia. Apparentemente
è semplice: sembra che basti leggere in blocco la memoria dati del
programma e spedirla, ma le cose in pratica sono molto più complicate.
Infatti bisogna evitare qualsiasi riferimento "fisico" all'ambiente
di esecuzione, come ad esempio gli indirizzi di memoria (in generale ogni
macchina rilocherà l'agente ricevuto ad indirizzi diversi) e gli
handle dei file aperti, e preservare le relazioni tra le varie strutture
dati (per esempio i link di una lista o di un grafo). Queste operazioni
prendono il nome tecnico di serializzazione, in quanto consistono
nella traduzione di una struttura dati complessa in una semplice sequenza
(o serie) di byte e viceversa. Essendo operazioni piuttosto sofisticate,
in genere tutti gli ambienti di sviluppo per Agenti Mobili sono in grado
di eseguirle automaticamente, senza alcun intervento da parte del programmatore.
Sicurezza
Un aspetto molto delicato relativo alla gestione di Agenti Mobili è
la sicurezza della macchina che li ospita. Pensando a come già
gli applet spaventino oggi molta gente, è facile immaginare
che l'idea di ospitare un programma "estraneo" spesso senza
rendersene conto incontrerà inizialmente poco successo: gli
applet sono più o meno visibili ed arrivano in risposta ad
una richiesta di una pagina WWW, mentre gli Agenti Mobili viaggiano di
loro iniziativa e quindi possono arrivare anche quando l'utente non se
l'aspetta. È fin troppo immediato associare questi famigerati Agenti
Mobili ad oggetti insidiosi come l'Internet Worm con cui è stato
aperto questo articolo, anche se questo, lo ribadiamo, è un concetto
errato. In realtà, quanto le opportune tecnologie saranno andate
a regime, non ci sarà nulla di cui preoccuparsi. Essendo gli Agenti
Mobili basati su linguaggi in qualche modo interpretati, è abbastanza
semplice per gli Agent Server costruire ambienti isolati per la
loro esecuzione, per esempio evitando l'accesso al file system locale,
come già avviene per gli applet Java grazie ai Security
Manager. Per mezzo delle digital signatures sarà possibile
certificare la provenienza degli Agenti Mobili, eventualmente ponendo restrizioni
al loro accesso; opportuni meccanismi di accounting potranno limitare
la quantità di risorse di sistema loro disponibili ed eventualmente
ottimizzarne la schedulazione (per esempio sfruttando le ore notturne quando
il carico è minore). Semmai esiste il problema opposto, quello della
secrecy: è l'Agente Mobile, ed in particolare il suo
algoritmo, ad essere vulnerabile. Torniamo ad uno degli esempi precedenti,
quello del rappresentante che invia il suo Agente Mobile per vendere un
elettrodomestico. Abbiamo detto che l'Agente Mobile, in questo caso interattivo,
può contenere al suo interno una "strategia" di vendita
che, eventualmente, può proporre degli sconti. Un cliente piuttosto
abile potrebbe impadronirsi del codice, disassemblarlo, ricostruire gli
algoritmi su cui è basato e trovare i suoi punti deboli (se non
addirittura modificarlo), per ottenere le condizioni di vendita più
favorevoli.
Questo
è un problema non risolvibile neanche con le tecniche crittografiche
attualmente in uso: esse infatti servono a proteggere il canale di comunicazione
tra due partner, mentre questi ultimi sono sempre considerati "trusted",
cioè fidati. Il codice dell'Agente Mobile deve per forza apparire
in chiaro, prima o poi, nelle virtual machine dei computer che lo
ospitano, altrimenti non potrebbe essere eseguito. È opinione diffusa
che non esistano soluzioni a questo problema implementabili in puro software:
molto probabilmente ci si dovrà affidare ad Agent Server
realizzati almeno in parte in hardware.
Sviluppo
di Agenti Mobili: Java e le Aglets
Gli Agenti Mobili sono oggetto di
ricerca già da parecchi anni ed in molti laboratori sono stati creati
degli appositi linguaggi ed ambienti di sviluppo per il loro studio (il
fatto che spesso si definisca un nuovo linguaggio per risolvere un particolare
problema spiega l'esistenza delle diverse migliaia di linguaggi di programmazione
oggi esistenti...). Da un punto di vista più commerciale, la società
statunitense General Magic, fondata nel 1990, ha messo a punto un linguaggio
chiamato Telescript ed un sistema di sviluppo per Agenti Mobili, chiamato
Tabriz AgentWare. L'idea originale era di creare reti per scopi commerciali
e permettere ai potenziali acquirenti di lanciare degli agenti per cercare
e valutare la merce da comprare; i risultati sarebbero stati poi rispediti
al mittente via posta elettronica o fax. Siccome questo genere di reti
dedicate non ha preso piede, la General Magic si è recentemente
convertita ad Internet, aggiungendo il supporto per interfacciarsi con
il WWW. La tecnologia Telescript viene attualmente supportata da alcuni
"grandi nomi" della telematica, come AT&T, Motorola, Sony,
Fujitsu e NTT (Nippon Telephone & Telegraph). Ci sono però alcune
incognite sul futuro di Telescript: la tecnologia è proprietaria
e la General Magic è l'unica produttrice di Agent Server
adatti (disponibili sia per UNIX che per Windows). Questo fatto non ne
favorirà certo una diffusione capillare... L'unica opzione alternativa
praticamente utilizzabile è Java, anche se ci vorrà del tempo
perché la piattaforma si stabilizzi: come abbiamo visto negli esempi
precedenti, la tecnologia degli Agenti Mobili richiede la serializzazione
degli oggetti, che è stata introdotta ufficialmente solo nella recentissima
versione 1.1 del JDK (Dicembre 1996), peraltro ancora una beta soggetta
a rifiniture. Dal canto suo, la General Magic può invece offrire
una soluzione già consolidata. Comunque, visto il grande successo
di Java, che ha letteralmente invaso Internet ("Java took Internet
by storm", dicono gli anglosassoni), la maggior parte degli esperti
pensa che, nel lungo termine, Java diventerà la tecnologia dominante
anche nel campo degli Agenti Mobili. Il fatto che General Magic abbia annunciato
il supporto Java per il suo Tabriz AgentWare potrebbe essere interpretato
come una conferma a questa opinione.
L'attuale
supporto di Java per la serializzazione degli oggetti non è però
sufficiente per implementare un Agente Mobile: per questo motivo l'IBM
ha proposto delle estensioni API chiamate Aglets ("aglet"
in inglese vuol dire "pungiglione" e quindi, per estensione,
"ape", "vespa": ogni riferimento ad insetti sociali
che si distribuiscono e collaborano insieme ad un fine comune non è
certo casuale...). Le Aglets di IBM sono un'architettura aperta e sono
state proposte come standard all'Object Management Group. Essendo ancora
un alpha 4, passerà un po' di tempo prima che gli standard
siano approvati definitivamente e che vedano la luce ambienti di sviluppo
in grado di supportare il Rapid Application Development (RAD), cosa
che appare abbastanza fondamentale perché gli Agenti Mobili possano
fare breccia sul mercato. Il codice e la relativa documentazione delle
Aglets può essere scaricata dal sito http://www.trl.ibm.co.jp/aglets,
quindi si possono provare già da subito. Per motivi di spazio non
è possibile parlarne più diffusamente in questa puntata,
ma già dalla prossima esamineremo la loro struttura, vedremo come
installarle su una macchina Windows o Solaris e come implementare qualche
semplice Agente Mobile.
Il
futuro degli Agenti Mobili
La tecnologia degli Agenti Mobili potrebbe
rivoluzionare Internet come la intendiamo oggi, ancora più di quanto
il WWW non abbia cambiato l'Internet di qualche anno fa. C'è già
chi, descrivendo nuovi scenari nei quali questi "componenti attivi"
avranno un ruolo fondamentale, ha proposto il nuovo termine ActiveNet...
Frenando gli eccessivi entusiasmi iniziali, gli sviluppatori che intendano
perseguire la strada degli Agenti Mobili dovranno trovare un "valore
aggiunto" rispetto alle attuali tecnologie di programmazione, dal
momento che molti problemi possono essere risolti utilizzando soluzioni
classiche (ed attualmente meno complesse) e gli utenti finali potrebbero
non capire la motivazione di scelte più impegnative. Poi bisognerà
attendere che i problemi di cui si è parlato in questo articolo
vengano risolti definitivamente e con tecnologie consolidate, specialmente
per quanto riguarda la sicurezza; e ciò non accadrà domani.
Ma, come già detto precedentemente, è probabile che nelle
Intranet, ambienti generalmente meno "delicati", gli Agenti Mobili
facciano la loro comparsa in tempi non troppo lunghi.
Riferimenti
bibliografici .
"Agents to roam the Internet"
-http://www.sun.com/sunworldonline/swol-10-1996/swol-10-agent.html
."Mobile Agents: a good idea?" - http://www.research.ibm.com/massive/mobag.ps
."Migratory Applications" - http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-138.html
."ActiveNet RFC" - http://www.tns_lcs.mit.edu/publications/rfc96/rfc96.html
.General Magic, USA - http://www.genmagic.com
.Telescript - http://www.genmagic.com/Telescript
.Aglets - http://www.trl.ibm.co.jp/aglets
 |
|
|
|
|
|
MokaByte
rivista web su Java
MokaByte ricerca nuovi
collaboratori
Chi volesse mettersi in contatto con noi puņ
farlo scrivendo a mokainfo@mokabyte.it
|
 |
|
