• Non ci sono risultati.

3.4. I modelli di simulazione realizzati

3.4.2. Le componenti del sistema

3.4.2.2. Struttura della peer

Ogni peer dispone di tre code: SRIN, SROUT e QP, utilizzate per memorizzare le informazioni necessarie per il calcolo delle query. Assumeremo che abbiano capacità illimitata per ridurre le problematiche relative alla loro congestione.

SRIN e SROUT sono code di pacchetti, rispettivamente in ingresso e in uscita. I messaggi spediti alle code sono suddivisi in pacchetti. La dimensione massima di ogni pacchetto è uguale a 64KB, in accordo con lo standard del protocollo TCP [7].

I pacchetti hanno un corpo (o body) nel quale sono memorizzati i dati, e un preambolo che contiene le informazioni necessarie per la ricomposizione del messaggio, ossia: l’indice del pacchetto, il numero dei pacchetti che compongono il messaggio, il numero della porta sorgente e il numero della porta di destinazione del pacchetto, che assumeremo coincidano con l’indirizzo IP della peer sorgente e l’indirizzo IP della peer di destinazione.

Il preambolo di ciascun pacchetto contiene dei campi utilizzati per implementare il protocollo TCP, che effettuano il controllo del flusso dei pacchetti e della congestione dei router.

Figura 3.6 Struttura di un pacchetto TCP

Queste informazioni sono utilizzate per implementare il livello di trasporto dei pacchetti e non sono rilevanti ai fini della gestione delle code dei nostri simulatori.

numero porta sorgente preambolo numero porta destinazione Dati (64KB) body 32 bits

indice del pacchetto cardinalità dei pacchetti

I segmenti TCP hanno un preambolo a formato fisso di 20 byte, che può essere seguito da opzioni di preambolo. Dopo le opzioni possono seguire fino a 65.495 byte di dati.

La Figura 3.6 mostra la struttura di un pacchetto TCP.

Ogni coda dispone di un processo di ingresso, un processo di servizio e di una disciplina di coda, come illustrato nella Figura 3.7.

Il processo d’ingresso delle coda è descritto dal tempo di arrivo di ciascun oggetto, che nella fase di inizializzazione del simulatore è il risultato di un processo di generazione casuale degli eventi di partenza. Analizzeremo dettagliatamente il processo di ingresso di ogni coda nei paragrafi successivi e nel Capitolo 4.

I processi di servizio implementano le attività associate alla gestione delle code, sono descritti da una variabile che identifica il tempo di servizio associato al processo, ossia il tempo speso per servire le richieste memorizzate nella coda corrispondente. Il processo di servizio della coda SRIN è il “servente di ricomposizione dei messaggi”, mentre quello della coda SROUT è il “servente di invio dei pacchetti”.

Figura 3.7 Sistemi a coda

Per entrambe le code, la disciplina di coda è la politica FIFO: il primo pacchetto in ingresso nella coda è il primo a essere servito.

Il “servente di ricomposizione dei messaggi” ha il compito di elaborare i pacchetti appartenenti al medesimo messaggio, per ricomporre il messaggio di partenza e inserirlo nella coda QP.

A tale scopo, ogni “servente di ricomposizione dei messaggi” dispone di un struttura dati, utilizzata per raggruppare i pacchetti appartenenti al medesimo messaggio e ricomporne il contenuto. Disciplina di coda Processo di ingresso Processo di servizio

QP è una coda di query nella quale ogni messaggio contiene le seguenti informazioni:

l’insieme dei termini che devono essere elaborati

l’insieme dei termini già elaborati

l’insieme dei risultati dell’elaborazione

Ogni termine è definito dalla coppia: indice termine e indirizzo IP della peer; mentre i risultati dell’elaborazione, ossia gli oggetti della stored interpretation, sono definiti da un insieme di indirizzi URL.

Nella fase di valutazione iniziale della query, il messaggio di risposta contiene soltanto i termini che appartengono alla query di partenza, il secondo e il terzo parametro sono insiemi vuoti che verranno aggiornati a tempo di simulazione.

Nella fase di riscrittura dell’approccio R1, il terzo parametro è sempre vuoto, il processo di valutazione delle risposte è calcolato nella seconda fase di implementazione dell’algoritmo.

Il processo di servizio della coda QP è il servente di elaborazione delle richieste e la disciplina di coda di QP è la politica FIFO.

Il servente di elaborazione delle richieste ha il compito di risolvere tutte le elaborazioni locali, aggiornando il messaggio di risposta e propagandolo a un’altra peer della rete.

Se la peer corrente coincide con la peer sorgente della query, l’interrogazione viene propagata a una nuova peer, scelta in funzione di un opportuno criterio di valutazione dell’insieme dei termini da elaborare. Viceversa, se la peer corrente è la peer di destinazione della query, il

servente di elaborazione delle richieste invia il messaggio di risposta alla peer sorgente.

Nel momento in cui ha ultimato il processo di valutazione e di risoluzione della query aggiornando il messaggio di risposta, il servente di elaborazione delle richieste verifica se la peer di destinazione del messaggio è connessa oppure disconnessa dalla rete.

Se la peer di destinazione del messaggio è connessa (state_peer = active) il messaggio di risposta viene suddiviso in un insieme di pacchetti da un processo di servizio, il servente di decomposizione dei messaggi , che ha il compito di creare dei pacchetti TCP e inviarli alla coda SROUT della peer corrente.

Il “servente di invio dei pacchetti”, preleva tutti i pacchetti TCP dalla coda SROUT e li invia alla coda SRIN della peer di destinazione del messaggio, ossia all’indirizzo IP memorizzato nel preambolo del pacchetto.

Figura 3.8 Architettura di una peer SRIN SROUT non locale locale Servente di ricomposizione dei messaggi Struttura dati appoggio per la ricomposizione dei messaggi Servente di elaborazione delle richieste Servente di decomposizione dei messaggi Servente di invio dei pacchetti Gestore dei messaggi locali peer di destinazione connesso peer di destinazione disconnesso tentativi < max_tentativi Servente di modifica dei messaggi tentativi = max_tentativi QP

Se la peer di destinazione è disconnessa (state_peer = inactive oppure state_peer = offline) il gestore dei messaggi locali verifica se il numero di tentativi di invio del messaggio è inferiore al limite massimo dei tentativi.

Nel caso affermativo (tentativi < max_tentativi) il servente invia il messaggio alla coda QP della peer corrente, altrimenti (tentativi = max_tentativi) il messaggio viene spedito al servente di modifica dei messaggi che ha il compito di aggiornare il messaggio eliminando dall’insieme dei termini da elaborare tutti i termini appartenenti alla terminologia della peer inattiva, e di inviare il messaggio modificato alla coda QP della peer corrente.

La Figura 3.8, mostra l’architettura di un peer e l’iterazione fra i processi di servizio delle code.

Documenti correlati