Evento: “Elabora risposte secondo l’algoritmo R1”

L’evento “Elabora risposte secondo l’algoritmo R1” (Figura 3.31) esegue le seguenti operazioni:

− estrae dal messaggio di risposta tutti gli oggetti recuperati, − aggiorna l’insieme delle risposte raccolte,

− verifica se sono stati recuperati tutti gli oggetti appartenenti alla stored interpretation dell’insieme delle entrate raccolte, nel caso affermativo:

o crea l’evento “Fine calcolo query” (vedi Paragrafo 3.4.3.8), e o setta a free l’attributo state_compute,

− altrimenti:

− setta a free l’attributo state_compute.

Figura 3.31 Diagramma di flusso dell evento Elabora risposte secondo l algoritmo R1

Aggiornamento dell attributo:

state_compute := FREE

Creazione dell evento:

Fine calcolo query

Aggiornamento dell insieme delle risposte raccolte

SE

(fine recupero risposte raccolte) Si

Capitolo 4

Scelta dei parametri di

configurazione del sistema

La fase di progettazione dei simulatori si pone come ponte tra la fase di specifica (definizione dei modelli discreti) e la fase di codifica (scelta del linguaggio di programmazione e scrittura del codice).

Nei capitoli precedenti abbiamo descritto la tassonomia della rete e i modelli discreti di simulazione, senza definire i criteri adottati per la scelta dei dati di partenza.

I modelli proposti sono sufficientemente astratti per poter essere agevolmente adattati alle differenti scelte progettuali di realizzazione dei simulatori.

Per la loro esecuzione è necessario disporre di dati in input che siano una adeguata rappresenta- zione delle caratteristiche rilevanti del sistema su cui si effettua la simulazione; tali caratteristi- che possono essere rappresentate con opportune variabili casuali, come a esempio il tempo di interarrivo fra due richieste successive.

E’ ragionevole supporre, ed è nel nostro caso, che su queste variabili siano disponibili dei dati sperimentali, ossia dei dati raccolti durante il funzionamento del sistema. Tali dati scaturiscono da indagini statistiche, utilizzate per costruire funzioni di distribuzione teoriche oppure empiriche necessarie per definire l’input di simulazione.

Il capitolo è organizzato nel seguente modo:

– il Paragrafo 4.1. illustra le tecniche di generazione dei dati di partenza adottate nel processo di implementazione dei simulatori, settando i seguenti parametri:

o la dimensione della rete, o la distribuzione delle query, o il grado di connettività delle peer, o la banda,

o la latenza e

o le variabili aleatorie utilizzate nella generazione casuale della tassonomia della rete.

Nel programma di simulazione è stata introdotta un’interfaccia grafica che permette di settare manualmente tali parametri, garantendo all’utente la piena libertà nella loro definizione. La configurazione così ottenuta è memorizzata in un file XML, da cui viene letta dal simulatore all’inizio del processo di simulazione.

– i Paragrafi 4.2. e 4.3. descrivono i criteri con cui sono fissate, rispettivamente: o la dimensione media degli oggetti scambiati e

o la dimensione media di ciascun termine.

4.1. Generazione dei dati di partenza

I dati di partenza, che vengono utilizzati dal simulatore, sono il risultato di indagini statistiche sulla rete Internet, effettuate dall’Università di Washington dal 6 al 14 marzo 2001, nell’ambito di uno studio sulle caratteristiche fondamentali dei Sistemi P2P File Sharing che aveva come scopo, la comparazione delle reti P2P più famose: Gnutella e Napster ( rif.: [2] e [3] ).

I dati ottenuti in questo ambito rappresentano un punto di riferimento per la definizione delle reti P2P dei nostri simulatori. Pur riferendosi a ricerche condotte nel 2001, forniscono un interessante studio sull’affluenza della rete Gnutella e sul comportamento dei suoi utenti. Non è stato possibile reperire dati più recenti.

Sono stati lanciati dei crowler che, attraverso il protocollo ping-pong, hanno raccolto informa- zioni sugli host connessi alla rete, utilizzando appositi strumenti software per misurare il tasso di malfunzionamento del sistema e il tempo di esecuzione e trasmissione dei dati.

Inizialmente i crowler si sono connessi alle peer più importanti di Gnutella (gnutella-hosts.com e router.limewire.com) per poi individuare le altre peer della rete attraverso un processo di iterativo che consta dell’invio di messaggi ping con uno specifico TTL.

Attraverso questa raccolta di informazioni, è stato possibile tracciare un grafico delle connessioni che ha permesso di definire una distribuzione statistica sul tasso di affluenza del sistema in un determinato intervallo di tempo.

La distribuzione delle connessioni è calcolata su dati statistici raccolti dal protocollo ping-pong, attraverso i quale è possibile individuare:

– l’indirizzo IP delle peer connesse,

– la cardinalità dei file condivisi,

– il numero della porta del software client dell’utente e

– tutte le informazioni sull’utente che sono derivabili dal software in uso.

Le informazioni raccolte ci serviranno per stimare il ritardo totale nel calcolo delle query, cioè il tempo richiesto per risolvere una query e inviare il messaggio di risposta alla peer che ha formu- lato l’interrogazione.

Questo valore è influenzato: dal tempo di creazione e ricomposizione dei pacchetti e dal tempo di esecuzione della query. Dipende sostanzialmente dalla potenza di calcolo della peer e dalla complessità degli algoritmi utilizzati.

Alcuni dei ritardi di elaborazione si riferiscono a operazioni svolte al livello di trasporto. Infatti, la creazione dei pacchetti e la loro ricomposizione sono operazioni implementate dal protocollo TCP. Più precisamente, il ritardo totale è così strutturato:

– Ritardo di coda è il tempo di attesa nelle code d’appoggio di ciascuna peer. Questo ritardo dipende dalla condizione di traffico della rete e dal grado di congestione delle code. E’ influenzato dalla funzione di distribuzione delle query e dal tempo di arrivo dei messaggi nelle code. Se la coda è vuota e non ci sono messaggi in fase di elaborazione, il ritardo di coda è zero.

– Ritardo di elaborazione, è il tempo necessario per evadere una richiesta di elaborazione di una query. Comprende i seguenti ritardi:

o il ritardo di elaborazione e ricomposizione dei messaggi in cui è organizzata la richiesta di elaborazione,

o il ritardo di risoluzione della query sulla peer locale, e

o il ritardo di creazione dei pacchetti in cui il risultato della elaborazione è organizzato per poter ritornare alla peer che ha effettuato la richiesta.

– Ritardo di trasmissione. E’ il tempo richiesto per trasmettere tutti i bit dei pacchetti che compongono il messaggio trasmesso. Dipende da un insieme di fattori, quali: la dimen- sione dei pacchetti trasmessi e la larghezza della banda di trasmissione.

– Ritardo di propagazione. E’ il tempo necessario per trasmettere un messaggio da una peer a un’altra, il suo valore coincide con la latenza della rete (Paragrafo 4.1.2).