progettazione e realizzazione in java di una rete peer to peer ...

More documents

Recommendations

Info

$Il favoloso mondo di LaTeX - DEI - Dipartimento di Ingegneria dell ...$

2.1 CORE pari, semplicemente inserisce la sua richiesta nella coda del destinatario. L’even- tuale risposta gli verrà recapitata direttamente nella propria coda. Il ricevente deve continuare a fare polling della propria coda in attesa di messaggi diretti a lui. Questo ciclo infinito tenderebbe a sprecare le risorse del sistema; proprio per questo abbiamo scelto di usare la PriorityBlockingQueue. Questa struttura dati già presente nelle JDK dalla versione 1.5, porge due caratteristiche molto in- teressanti. In primo luogo incorpora nella coda già un monitor. Questo permette al thread, che controlla la coda in attesa di nuovi messaggi, di andare in uno stato di wait in caso di coda vuota e di non sprecare risorse. In secondo luogo poi, la coda gestisce un sistema di priorità definibile sulla base di un comparatore che abbiamo noi stessi specificato. In questo modo, in caso di congestione del core, si può sperare che i messaggi con priorità più alta arrivino comunque a destinazione, consentendo al core stesso di mantenere le sue normali funzionalità. Da alcune prove che abbiamo eseguito, questo sistema sembra comportarsi secondo le attese. Tuttavia possono sorgere problemi nel caso i plug-in produca- no messaggi a una velocità molto maggiore della velocità con cui li consumano. In tale evenienza, infatti, le code si riempiono e tendono a saturare la memoria della JVM. Questo comporta il lancio di un’eccezione e l’arresto di tutto il core. Per fronteggiare il problema, si è provveduto a limitare il numero di messaggi che possono essere contemporaneamente in una coda, scartando gli ulteriori even- tuali messaggi in arrivo. Questo escamotage, che sembra funzionare secondo le previsioni, è tuttavia ampiamente migliorabile. Sarebbe auspicabile, infatti, un controllo sulla priorità del pacchetto prima di decidere se scartarlo, o meno o anche un approccio di tipo RED[2]. Questa struttura con un grosso monitor dotato di code è stato scelto per ov- viare ad alcune limitazioni di Java. Se i plug-in avessero comunicato direttamente tra loro senza passare da un monitor, ci sarebbe stato sicuramente un incremento delle prestazioni (ci sarebbe stato, infatti, un passaggio in meno). In C/C++ si sarebbero probabilmente potuti usare i puntatori per affrontare il problema. In Java ci siamo invece affidati all’uso di un monitor opportunamente modificato: una soluzione che permette anche di controllare i flussi di messaggi tra i plug-in. Vediamo ora cosa sono esattamente questi messaggi. I messaggi trasmessi tra i vari plug-in sono dei pacchetti caratterizzati quasi come dei datagrammi di networking. Ognuno di questi pacchetti è formato da diversi campi che servono ad indicare la provenienza e la destinazione del pacchetto, la priorità e il pay- lod. Questi pacchetti, che abbiamo chiamato cocoon, corrispondono, se vogliamo continuare il nostro parallelo col mondo delle reti, a datagrammi ip. Il payload 17
2. LE COMPONENTI poi si differenzia a seconda della funzione che ha il messaggio e a seconda del plug-in da cui proviene o a cui è destinato. Se, ad esempio, si tratterà di un cocoon destinato a Connectivity, incapsulerà un oggetto flux che a sua volta incapsulerà un oggetto triplaDati. flux corrisponderebbe quindi al protocollo tcp e triplaDati ad un datagramma http. Figura 2.2: L’incapsulamento dei messaggi. Nel pacchetto core sono anche inseriti i manager per le risorse. Questi moduli hanno il compito di assegnare e, in caso di conflitto, arbitrare le risorse. Queste operazioni però, non dipendono esclusivamente dal resource manager competente. L’assegnazione, infatti, si basa su un meccanismo che coinvolge il plug-in richiedente e il modulo per la gestione dei crediti. Il plug-in che vuole usufruire, ad esempio, di una certa quantità di spazio su disco, deve, infatti, richiederne l’uso al gestore locale ma deve anche “pagare” al modulo per la gestione dei crediti. La transazione tende a complicarsi nel caso in cui è un altro nodo della rete a interrogare il client locale per usarne lo spazio. Infatti, il nodo remoto, deve prendere contatto col plug-in locale per controllare la disponibilità del servizio, e, poi, deve interagire col modulo di gestione crediti per accordarsi sul prezzo. In locale, il plug-in accetta di fornire il servizio al nodo remoto previa verifica di pagamento presso il modulo gestione crediti. Successivamente si fa carico di chiedere l’allocazione della risorsa presso il gestore della risorsa competente. Il gestore dovrà quindi, oltre ad accettare le richieste dei plug-in, controllare pre- 18
Page 1 and 2: PROGETTAZIONE E REALIZZAZIONE IN JA
Page 4: Ai miei genitori chi mi hanno sempr
Page 7 and 8: INDICE A.1.4 Datagrams . . . . . .
Page 10 and 11: Introduzione In questo elaborato si
Page 12 and 13: gradualmente costruita una galassia
Page 14 and 15: Capitolo 1 Le caratteristiche pecul
Page 16 and 17: 1.2 SERVERLESS della rete (ad esemp
Page 18 and 19: dimensione array in KB ms per RSA m
Page 20 and 21: 1.4 I CREDITI garantire l’accresc
Page 22 and 23: Capitolo 2 Le componenti Come prece
Page 26 and 27: 2.1 CORE ventivamente la possibilit
Page 28 and 29: 2.1 CORE il file, mandano un segnal
Page 30 and 31: 2.2 KADEMLIA Successivamente il nod
Page 32 and 33: 2.2 KADEMLIA interroga un suo pari,
Page 34 and 35: Figura 2.4: Il sistema del predilet
Page 36 and 37: 2.3 ALTRI PLUG-IN tempi di latenza.
Page 38 and 39: 2.3 ALTRI PLUG-IN grande rete di fi
Page 40 and 41: Capitolo 3 Management Per affrontar
Page 42 and 43: cumentazione. Abbiamo scelto di ado
Page 44 and 45: Conclusioni Abbiamo già notato, in
Page 46 and 47: Appendice A Documentazione del prog
Page 48 and 49: Appendice an empty tripla. So the e
Page 50 and 51: Ping The PING RPC probes a node to
Page 52 and 53: Find - favorite mode Appendice This
Page 54 and 55: Find Node Find Node Byte Use Note 8
Page 56 and 57: A.2.2 Resource manager Appendice Th
Page 58 and 59: dataStorage a wrapper class to star
Page 60 and 61: Bibliografia [1] Petar Maymounkov a
Page 62 and 63: Elenco delle figure 1 La rete e gli
Page 64 and 65: Elenco delle tabelle 1.1 Crittograf
Page 66: Ringraziamenti • Daniela perchè

progettazione e realizzazione in java di una rete peer to peer ...

Create successful ePaper yourself

Delete template?

Save as template?