Analisi dei requisiti

Di seguito si descrivono le procedure che richiedono una comunicazione inter-regione e che individuano, quindi, i requisiti richiesti dal nuovo sistema per quanto concerne l’interazione attraverso Internet. Le procedure riportate sono le seguenti:

1. inizializzazione della piattaforma e mobilità degli agenti;

2. ricerca extra-regione;

3. selezione delle fonti;

4. trasferimento di una tranche;

5. gestione delle primitive di amministrazione.

Si ritiene necessaria una descrizione di tali procedure affinchè si possano individuare i punti nevralgici su cui porre maggiore attenzione.

Dal momento che si utilizzano gli acronimi definiti per gli agenti, è utile far riferimento al paragrafo introduttivo 1.2.1 per comprenderne il ruolo o la dislocazione.

2.2.1 Inizializzazione della piattaforma e mobilità degli agenti

Ogni regione (che coincide con una AgentPlatform1) è composta da un superpeer e da un numero arbitrario di peer. Su ogni peer risiede un containter, mentre sul superpeer risiedono sia un container (in quanto il

superpeer svolge anche le attività di un comune peer), sia un main container.

Ogni containter viene inizializzato con alcuni parameteri, fra cui ci sono uno o più indirizzi del protocollo MTP2 che permettono agli agenti presenti nel container di comunicare sia con gli altri container della piattaforma, sia con le altre piattaforme (ovviamente anche la migrazione degli agenti verso altre piattaforme -leggasi “regioni”- si basa sulla visibilità dei container).

Di coseguenza si rileva la necessità di rendere in qualche modo raggiungibile - direttamente o indirettamente - ciascun container per tutti gli altri container sia all’interno che all’esterno della regione in cui si trova.

2.2.2 Ricerca extra-regione

RRA - CA - SearchAgent

Quando l’agente RSMA di un peer, analizzando il proprio palinsesto, rileva l’assenza di un contenuto, formula una richiesta per ogni tranche che compone il contenuto stesso; queste richieste vengono inoltrate al SA e raggiungono (Figura 2-1, p.18) [1] l’RRA3 . Questo agente, per ogni richiesta, restituisce una risposta contenente una lista di fonti per quella determinata tranche.

Se non sono presenti fonti all’interno della regione, dà inizio ad una ricerca extra-regione: chiede [2] all’agente CA di creare ([3] e [4]) due SearchAgent affinchè esplorino l’overlayNetwork visitando tutti i superpeer che la compongono e rimane in attesa dell’esito di tale ricerca.

I due SearchAgent - come viene accuratamente descritto nell’elaborato (Biscuola, 2009 p. 124 - 134) - percorrono l’anello nei due sensi ([5] – [10], in Figura 2-1, p.18 e Figura 2-2, p.18 ) e, una volta visitati tutti i superpeer, restituiscono ([11] e [12]) i risultati al CA che li ha creati. Il CA fa la sintesi di tali risultati e li comunica [13] al RRA che li inoltra [14] all’RQMA del peer richiedente.

2 Un esempio di indirizzo MTP, implementato su HTTP, è: http://151.16.149.126:6668/acc

3 L’agente RRA tiene traccia di tutte le tranche possedute dai peer della propria regione.

Figura 2-1 – Ricerca extra-regione (a).

Requisiti

E’ necessario, quindi, che i SearchAgent possano visitare ciascun superpeer della overlayNetwork e restituire i risultati al CA che li ha originati, fornendo dei riferimenti utilizzabili per le comunicazioni successive.

2.2.3 Selezione delle fonti

DMA - MA - UMA

Quando il peer che ha richiesto le fonti per una determinata tranche entra in possesso della lista di tali fonti, l’agente DMA del peer in questione dà inizio alla fase della selezione delle fonti Figura 2-3: genera un agente MA per ogni peer che possiede la tranche e attende che questo migri o verso il container del peer (nel caso di fonte intra-regione) o verso il main container del superpeer (nel caso di fonte extra-regione). Ogni agente MA comunica con l’UMA della specifica fonte per cui è stato creato e si mette in coda prelevando un ticket. Quando l’UMA chiama il ticket, l’MA avvisa il DMA che, sulla base delle risposte inviate dagli altri MA migrati verso le altre fonti, accetta o declina la proposta di download (Figura 2-4).

Figura 2-4 – Selezione delle fonti [extra-regione] (b).

Requisiti

E’ necessario che ogni agente MA riesca e migrare verso il container del peer fonte o verso il main container della regione in cui tale peer si trova.

E’ inoltre necessario che le comunicazioni fra MA e DMA, che possono avvenire all’interno della stessa regione o tra due regioni distinte, vengano garantite in entrambi i casi.

2.2.4 Trasferimento di una tranche

DA - UA

Una volta selezionata la fonte, l’UMA avvisa l’UA che contatta l’agente DA del peer richiedente chiedendo l’indirizzo (IP:port) per la connessione TCP necessaria al trasferimento. Il DA risponde alla richiesta e si mette in ascolto sulla porta comunicata al UA. Quest’ultimo effettua la connessione e trasferisce la tranche. Al termine, l’agente DA sblocca l’agente UMA del peer uploader affinchè possa servire altri MA.

Requisiti

Dal momento che, nella sua nuova versione, il sistema vedrà regioni appartenenti a LAN distinte, è necessario comprendere come gestire la visibilità diretta fra peer in regioni diverse: a meno che non si intenda rendere visibile ciascun peer dall’esterno della LAN in cui si trova4, bisognerà stabilire come gestire le comunicazioni fra DA e UA. A tal proposito, si rimanda al paragrafo 2.4.

4 Ad esempio con il port forwarding di TUTTE le porte utilizzate dal peer stesso (da JADE, dai componenti per la gestione delle primitive, dai componenti per il trasferimento delle tranche).

2.2.5 Gestione delle primitive di amministrazione

Questa funzionalità non è prevista dal sistema nella sua versione attuale. Inoltre non sono ancora state definite le primitive di amministrazione; né è stato definito quale comportamento i nodi del sistema (peer e superpeer) debbano avere durante l’esecuzione di una primitiva.

Nonostante risulti prematuro definire dettagliatamente i requisiti del nuovo sistema relativamente a questo aspetto, si crede necessario fornire comunque alcune linee guida.

Si dovranno progettare, per ogni nodo (peer o superpeer), uno o più componenti in grado di inviare, inoltrare ed eseguire le primitive di amministrazione. Questi componenti dovranno anche gestire gli esiti dell’esecuzione delle varie primitive e darne comunicazione a chi le ha lanciate. Siccome le primitive di stato riguarderanno anche l’avvio e l’interruzione dell’esecuzione di un peer o di un superpeer, si dovrà prevedere l’eventuale funzionamento di uno o più componenti al di fuori della piattaforma JADE e, quindi, senza l’ausilio degli strumenti offerti da JADE stesso (come, ad esempio, lo scambio di messaggi o il sistema di indirizzamento globale).