Gestire lo stato di una regione

Poter gestire lo stato di una regione significa poter controllare le attività di tutti i peer al suo interno e poter modificare la struttura della rete di overlay in cui si trovano tutti i superpeer connessi al sistema: ogni regione viene inserita nella rete al momento della sua creazione e rimuoverla significa modificare la overlay network e privare il sistema di eventuali fonti. Assume un’importanza sostanziale decidere come debba avvenire la gestione dello stato delle regioni del sistema: una soluzione potrebbe essere quella di far riferimento ad un server che abbia a disposizione le informazioni aggiornate sulla struttura complessiva della rete logica su cui è basato il sistema.

3.4.1 Definizione del server

Per poter aggiungere una regione al sistema si deve innanzitutto modificare l’overlay network in modo che il superpeer della nuova regione sia in grado di interagire con gli altri superpeer.

Affinché ciò sia possibile, è necessario che sia presente un’entità la quale abbia informazioni sulla struttura di tutta l’overlay network. Si potrebbe definire un server che ogni superpeer, durante le fasi di avvio, dovrebbe contattare per ottenere i riferimenti ai superpeer vicini nella overlay network (l’indirizzo e il GUID dell’agente AMS).

Nel caso in cui un superpeer non sia più raggiungibile (verifica effettuabile ad esempio tramite dei probe message) o abbia effettuato la disconnessione delle propria regione dal sistema, sarà sempre compito del server mantenere coerente la struttura della rete, notificando ad ogni superpeer eventuali aggiornamenti per esso rilevanti (riguardanti, cioè, i superpeer adiacenti).

Il server potrebbe essere rappresentato (a) dal superpeer di una regione (b) dal superpeer di una regione priva di altri peer (costituita dal solo superpeer) (c) dal superpeer di una regione priva di altri peer, raggiungibile da ogni peer del sistema ma esterna alla overlay network.

a) in questo caso l’efficienza delle funzioni del server (che tra l’altro detiene tutte le tranche di tutti i contenuti che ogni peer dovrà ottenere) potrebbe diminuire a causa delle normali richieste formulate dai peer della regione di cui il server è anche superpeer; b) in questo caso il server dovrebbe rispondere solo alle richieste

provenienti da altre regioni ma, come nel caso precedente, in caso di guasto del server verrebbe danneggiata direttamente la struttura della overlay network;

c) in quest’ultimo caso un guasto del server non inficerebbe la

struttura della overlay network (almeno fino al successivo guasto di uno dei superpeer) e sarebbe possibile evitare che il server venga considerato come fonte plausibile per ogni ricerca effettuata dai superpeer (così come avviene nei due scenari precedenti). Si ritiene che la soluzione (c) sia quella più vantaggiosa5.

Per limitare le conseguenze di un guasto del server sulla struttura della overlay network, potrebbe essere sensato replicare su alcuni superpeer le informazioni sulla struttura della rete. Una strategia più efficace potrebbe consistere nel mantenere una conoscenza distribuita della struttura complessiva o più semplicemente, per ogni superpeer, i riferimenti a superpeer vicini fino ad un livello predeterminato o stabilito dinamicamente.

Qualunque sia la scelta effettuata, dovrebbe essere implementata una strategia per la diffusione iniziale delle prime tranche ai superpeer in base

5 In fase di implementazione potrebbe essere sensato per ragioni di semplicità implementare il server in modo che faccia comunque parte della overlay network. Ottenere una overlay network priva del server non richiederebbe, a quel punto, eccessivo sforzo realizzativo.

alle esigenze dei peer della regione6: in caso contrario il server, nel primo periodo di attività del sistema, verrebbe inondato dalle richieste di tutti i peer che, a seguito delle ricerche extra-regione, individuerebbero nel server stesso l’unica fonte per le tranche richieste.

La presenza di un server non deve essere fuorviante: l’architettura del sistema rimane peer-to-peer e la struttura gerarchica che si viene a creare ha il solo scopo di gertire al meglio quelle attività che richiedono l’interazione fra regioni distinte come la ricerca o l’inoltro delle primitive di amministrazione per peer e regioni.

Il server funge da contenitore per tutti i contenuti potenzialmente fruibili da ciascun peer che ne faccia richiesta e svolge l’attività di coordinatore per quanto riguarda la gestione della struttura della overlay network e l’inoltro delle primitive di amministrazione originate dall’interno di una regione e indirizzate verso altre regioni o peer di altre regioni.

3.4.2 Stati

rADDED

La regione è attiva ed inserita all’interno del sistema. Il superpeer svolge le proprie attività e i peer della regione che sono stati attivati possono eseguire i loro compiti.

rREMOVING

Stato che precede immediatamente lo stato rREMOVED a partire dallo stato rACTIVE.

Il superpeer deve prima inoltrare la primitiva stopP a tutti i peer della regione che attualmente non si trovano già nello stato pSTOPPED e, solo successivamente, interrompere la propria esecuzione passando nello stato rREMOVED.

rREMOVED

In questo stato la regione non è connessa al sistema, quindi non è presente all’inerno della overlay network. Il mainContainer ed il container del superpeer sono in esecuzione; tutti i peer sono nello stato pSTOPPED e

tutti gli agenti dei peer e del superpeer della regione non sono in esecuzione (ad eccezione di quelli di supporto).

Figura 3-4 - Stati di una regione.

rADDING

Stato di transizione dallo stato rREMOVED allo stato rADDED. rFAILURE

Una regione si trova in questo stato quando il superpeer ha rilavato un errore durante l’esecuzione di una primitiva di amministrazione a livello di regione. Dal momento che non è detto che sia possibile conoscere con certezza lo stato di ogni peer della regione, l’unica operazione da compiere è il ripristino tramite la primitiva downR.

rDOWNING

La regione sta tornando allo stato rREMOVED dallo stato rFAILURE.

3.4.3 Primitive

Analogamente al caso dei peer (cfr. par. 3.3.2), anche per le regioni si suppone che:

- nel momento in cui un superpeer viene attivato per la prima volta, verranno avviati il maincontainer ed il container, verranno avviati gli agenti di supporto e la regione rimarrà nello stato rREMOVED; solo a partire da questo momento il superpeer potrà ricevere la primitiva addR;

- eventuali agenti di supporto potranno essere eseguiti all’interno del container a prescindere dallo stato del peer e della regione; - l’utilizzo di thread esterni alla piattaforma JADE dovrà essere

permesso per l’avvio della piattaforma stessa e la relativa gestione (anche a livello di stato degli agenti in essa presenti).

Figura 3-5 – Primitive per una regione.

addR

L’aggiunta di una regione al sistema consiste nell’avvio di un nuovo superpeer che si inserisca tra altri due superpeer all’interno della overlay network. I futuri vicini del superpeer appena aggiunto vengono informati dal server del cambiamento della overlay network; sospendono momentaneamente le operazioni che coinvolgono i vicini e le riprendono considerando il nuovo superpeer.

Come nel caso di un peer, anche per l’avvio di un superpeer potrebbe rivelarsi sufficiente mantenere in esecuzione un processo che si occupi di ricevere l’input di avvio e la posizione all’interno della overlay network (ossia dei GUID e degli indirizzi dei superpeer adiacenti): una volta ricevuto il messaggio, il superpeer informa il server del cambiamento di stato e procede con le normali attività.

Nessun vincolo è imposto sui peer della regione: quando il superpeer riceverà il comando startP dal server per un determinato peer, allora quel peer sarà messo in esecuzione.

removeR

Disconnettere una regione dal sistema è un’operazione riconducibile ad interropere tutti i peer di una regione e, per ultimo, anche il superpeer; deve, inoltre, essere informato il server che provvederà a ristrutturare l’overlay network informando i superpeer adiacenti alla regione che verrà rimossa. Le operazioni necessarie vengono svolte dal superpeer: lo stesso agente citato in precedenza e che si occupa dell’interruzione di un peer, si occupa di far interrompere le attività di tutti i peer della regione.

downR

La primitiva riporta nello stato rREMOVED una regione che si trova nello stato rFAILURE, ripristinando lo stato di ogni peer della regione (downP). Con questa primitiva deve essere anche aggiornata la overlay network, da cui dve essere rimossa la regione in questione.

3.4.4 Considerazioni

Come accennato in precedenza, l’esecuzione di una primitiva, che sia indirizzata ad un peer o sia rivolta ad una regione, richiede che vengano restituite delle informazioni al nodo “creatore” da cui la primitiva stessa è stata lanciata. D E S T I N A T A R I O PEER (locale) PEER (stessa regione del mittente) PEER (altra regione) REGIONE (stessa regione del mittente) REGIONE (altra regione) SERVER M I T T E N T E ^{PEER Sì Sì No No No No} SUPERPEER Sì Sì Sì Sì Sì No SERVER Sì - (7) Sì Sì Sì Sì

Tabella 3-1 – Vincoli per l’esecuzione delle primitive di amministrazione.

7 Come stabilito nel paragrafo 3.4.1, non si prevede la presenza di altri peer oltre al server nella regione del server.

Dal momento che si ritiene poco sensato poter eseguire le primitive di amministrazione solo dal server, si decide di dotare il sistema della possibilità di eseguirle da più punti.

Quindi si prevede di realizzare un insieme di componenti che permettano, nello specifico, di lanciare le primitive indirizzate a peer e regioni secondo la Tabella 3-1 (p.66).