Agente:
Appena è generato, l’Agente legge da un file i parametri per inizializzare i propri contatori ( per esempio quelli di uso risorse).
Ma il principal può gestire l’Agente ed i suoi parametri con
un Front End grafico in Java.
partendo dal Place del suo Principal quando vuole muoversi chiede
al Server del Principal un lista (query ) di Place (Sicuri ed eventualmente
Non).
Il Place del Principal può avere una lista di Place oppure può
appoggiarsi ad un Name Server esterno.
Si fa generare una chiave simmetrica (one time password), la aggiunge alle credenziali e si fa crittare il tutto con la chiave pubblica del primo Place su cui vuole andare.
Poi apre una comunicazione col primo Place, per la negoziazione:
gli manda il pacchetto con le credenziali, la chiave ed il Flag=0 (negoziazione
normale) (tutto crittato) come richiesta di connessione.
Un Semplice Datagramma UDP. (Nota post – implementazione: si usa la primitiva di send )
(Vedi
Figura Riassuntiva Negoziazione)
Se le risorse disponibili per lui sul server (dalla risposta di connessione) fossero sufficienti ( almeno un canale di comunicazione per poter fare richieste ad altri server, la memoria sufficiente per se stesso ( requisiti minimi per poter lavorare e spostarsi su un altro place), ed eventualmente dei servizi che gli servono ( in base alla politica del Principal) ), annuncia al Server (su cui si trova) di doversi spostare (passandogli AgentID, indirizzo e porta dell’altro server, chiave simmetrica e metodo da riattivare ), e quindi il server lo critta con la chiave simmetrica e manda all’altro Server l’URL da cui prelevare l’Agente con il metodo da riattivare.
Quindi rimane nel Server finché dall'altra parte non arriva
la richiesta di caricamento ( o scade il Time - Out, nel qual caso l'Agente
viene "spacchettato" e avvisato del time out (mediante l’esecuzione del
metodo "standard per gli errori"), lasciandolo in esecuzione per il tempo
rimanente (concessogli in precedenza)).
Il Server di Partenza gestisce la terza fase della Negoziazione. L’Agente chiama un metodo dell’Agent Server, ed è quest’ultimo che si occupa di gestire il tutto.
Questo metodo, inoltre è un try/catch per il contatore di time
– out.
Arrivato dall'altra parte (nel nuovo place), dopo tutti i controlli è rimesso in esecuzione con un certo metodo stabilito dall’Agente prima della partenza.
Ci deve essere un metodo che viene eseguito in caso di problemi,
passandogli il codice d'errore ( come nel caso precedente di time out )
Sul nuovo Place l'Agente potrebbe voler mandare un Agente su un Place insicuro:
prima si fa generare un valore casuale (Alias), e l’aggiunge al "pacchetto" con le credenziali, e si fa cifrare questo pacchetto con la chiave pubblica del Server stesso (servirà quando lo Slave vorrà "tornare" su questo Place per "mandare" i dati al Master, che l’ha generato), quindi inizia la negoziazione col Place insicuro, e se va a buon fine, chiede al server di farsi clonare ( genera uno Slave) e di mandare lo Slave al Place voluto, e di mettere in esecuzione lo Slave con un certo metodo.
( Ovviamente lo Slave deve avere in una variabile l’indirizzo del Place Sicuro di partenza)
Poi si fa decrittare il "pacchetto" e conserva il valore casuale, con il quale si fa creare un Alias di Mail dal Server.
(Uso la chiave simmetrica della negoziazione per crittare l’Agente)
Il Server ha un TTL associato ad ogni Alias, che il Thread ci controllo Risorse verifica periodicamente.
Quando ha finito di lavorare, o dopo aver esaurito i contatori di
uso risorse (inizializzati dal Principal), rimane in attesa della risposta
dallo Slave (clone), controllando la MailBox.
L’Agente ha vari contatori inizializzati dal Principal: spesa massima
(pagamento risorse e servizi) e per il max mun di Place sui quali passare
(ttl), quantità max di dati che può raccogliere su un Place
(?).
Il server gli comunica il Time-Out (ovviamente un certo tempo prima) con un messaggio nella MailBox, e quindi l’Agente ripete la procedura di clonazione e di Copia su un altro place e attiva la copia.
Poi lascia nel log del Server un messaggio con il nuovo indirizzo (per il forward della Mail) ed il numero di Alias, e infine si suicida.
La Copia continuerà il lavoro nello stesso modo del primo
Agente (quindi diventa il nuovo Master).
La comunicazione tra Server è Agente è realizzata tramite la MailBox dell’Agente.
E’ quindi compito dell’Agente controllare periodicamente la MailBox.
Quando lo Slave, alla fine del suo lavoro, vuole mandare dei dati al Master, apre la negoziazione col Place si Provenienza, e manda il pacchetto crittato in precedenza ( con le credenziali ), più un pacchetto con i dati da spedire al Master, crittato con la chiave Privata del Place di partenza.
Il pacchetto dati è composto da: URL, Oggetto(dati).
(l’URL ci servirà per decrittare i dati (con la chiave pubblica associata a quell’URL))
( in Realtà nell’Ottimizzazione finale, si manda solo il pacchetto
di negoziazione con l’indirizzo (URL) dello slave, sarà il Server
destinazione a fare la recv del pacchetto dati)
E quindi lo Slave si suicida.
Alla fine di tutto il suo lavoro( o alla fine delle risorse che poteva "spendere"), l'Agente Master (chiunque esso sia, a questo punto), torna sul server del Principal e gli consegna i dati.
NB: l’Agente in ogni istante sa quanto gli è rimasto da spendere, perché gli Slave non possono spendere niente ( o meglio sui Place Insicuri possono spendere quello che vogliono, tanto non pagano), ed in ogni istante, si assume che l’Agente Master sia unico, altrimenti prima della clonazione bisogna decrementare i contatori fino al valore che si vuol dare al Clone, poi clonarsi, e rimettere a posto i contatori scalando dai valori originari quelli dati al Clone (cioè si "spartiscono le risorse").
Il tempo può essere visto come una risorsa da gestire => controllo.
Associata ad ogni richiesta di una risorsa c’è anche il controllo sulla risorsa stessa.
Per la gestione del tempo si può usare il Timer del Server che alla scadenza lascia un messaggio nella mailbox.
Questa gestione del tempo è "a scalare", ed è molto imprecisa.
Si potrebbe anche implementare sul server la gestione del tempo con "beat" (il tempo unico di Internet, proposto da Negroponte). In questo modo il controllo sarebbe sull’orario, e non sul tempo rimanente.
In questa implementazione dell’Agente, comunque, si farà sempre
riferimento al l’ora rispetto il GMT (+0), cioè il Server convertirà
l’ora locale in ora del GMT.
Soluzione al Problema della consegna dei dati raccolti dallo Slave,
al Master :
Un Metodo dell’Agent Server ci permette di creare un valore di Alias ed associarlo alla nostra MailBox
Quando arrivano dei dati per quell’Alias, questi vengono copiati sulla
mailbox dell’Agente (se è presente, altrimenti si fa il forwarding).
E’ il Server che fa tutto il lavoro: alla richiesta di consegna mail,
l’Agent Server, nel caso in cui l’Agente non sia presente sul Place, crea
un nuovo Thread che si occupa della consegna del messaggio
C’è un max mun di Place che il Master attraversa lasciando nel log il riferimento di forward, oltre il max, non lascia più riferimenti, e quindi i pacchetti vengono persi.
Così il pacchetto con le credenziali può essere utilizzate Solo per mandare un messaggio ( e non per spostarsi), e solo una volta.
( Anche se il sistema così potrebbe essere soggetto ad attacchi
a forza bruta, provando tutti i possibili valori del campo numerico, fino
a trovare lo zero (crittato) ).
Due tipi di credenziali => due coppie diverse di chiavi pubbliche
– private. (Place Sicuri e Non)
Tutto questo Overhead potrebbe sembrare molto pesante, in realtà è proporzionato al numero di Place Insicuri che vogliamo visitare, e quindi è più che giustificato.
( l’Overhead compare solo nel momento in cui mandiamo uno Slave su
un Place Insicuro)
Ottimizzazione:
Solo il pacchetto di negoziazione arriva fino al Place del Master. Da questo si estrae indirizzo e porta del Place mittente (cioè dello Slave) e si richiede direttamente da questo il pacchetto dati.
( cioè si risponde alla richiesta, mandando la porta (tre interi) del nuovo thread in attesa dei dati)
Il Master, quando si sposta su un nuovo Place deve mandare al Place precedente un Pacchetto di tipo nextAlias, coiè dice al vecchio Place qual è il suo Alias sul nuovo Place.
Questione aperta :
Nuovi Obiettivi:
In questo caso però, l’Agente si deve portare dietro la propria
chiave pubblica (firmata con la privata), per la crittazione dei dati raccolti.
