Nel paragrafo precedente abbiamo descritto le tecniche attraverso le quali un peer viene a conoscenza degli oggetti passivi che si trovano nella propria area di interesse. Dunque applicando una delle tecniche proposte il peer dispone degli advertisement per gli oggetti nella propria cache.
Nella sezione 3.3.5 abbiamo discusso le diverse soluzioni che proponiamo per la modi ca di oggetti passivi al ne di mantenere la consistenza del loro stato in un contesto molto dinamico come quello degli ambienti virtuali distribuiti. Descriviamo ora l'implementazione dei tre casi che possono veri carsi:
Modi ca oggetti passivi con pubblicazione diretta del peer Modi ca oggetti passivi con richiesta al coordinatore Modi ca di oggetti passivi senza coordinatore
4.7.1 Pubblicazione diretta delle modi che
Il peer che non rileva la presenza di altri peer nell'area di noti ca aggiornamento dell'oggetto che vuole modi care deve:
4.7. MODIFICA OGGETTI PASSIVI 115 Modi care l'istanza dell'ObjectAdv corrispondente all'oggetto a cui è interes- sato: assegna alla variabile istanza score il valore precedente diminuito di 20. Ricordiamo che, per semplicità, si è considerato solo il caso in cui lo score di un oggetto è descritto da un valore intero; ad ogni operazione di modi ca si diminuisce semplicemente di 20 il valore dello score.
Esegue la pubblicazione dell'ObjectAdv attraverso il metodo publish() del Discovery Service di JXTA.
4.7.2 Modi ca con richiesta al coordinatore
Se un peer rileva la presenza di altri peer nell'area di noti ca aggiornamento del- l'oggetto che vuole modi care allore deve richiedere la modi ca direttamente al coordinatore; il peer deve eseguire le seguenti azioni:
Il peer cerca nella regione un pipe advertisement con nome uguale alla stringa ottenuta concatenando l'identi catore unico del coordinatore con la stringa ObJRequest.
Utilizzando l'advertisement recuperato crea una JXTA BiDiPipe.
Crea il thread ObjManager (classe interna della classe PeerDve, che imple- menta l'interfaccia net.jaxa. pipe. PipeMsgListener) che esegue le seguenti azioni:
Avvia la connessione con il coordinatore attraverso la pipe: biDiPipe.connect(region, null,
pipeAdv, 30000, this);
Se non è possibile stabilire la connessione con il coordinatore entro il timeout stabilito (in questo caso 30 secondi) l'istruzione di cui sopra lancia una eccezione; ciò signi ca che si è veri cato il fallimento del coordinatore. In questo caso il peer inizia la procedura per diventare coordinatore per l'oggetto, descritta di seguito.
Altrimenti, invia un messaggio di richiesta di lettura dello stato dell'og- getto sulla BiDiPipe.
Il peer rimane in ascolto della risposta dal coordinatore (sulla stessa pipe in quanto bidirezionale).
Ottenuta la risposta dal coordinatore il peer dispone dello stato aggiorna- to dell'oggetto quindi valuta se proseguire o meno nella modi ca dell'og- getto. Invia al coordinatore un messaggio dove indica la sua intenzione di proseguire o meno la modi ca.
Se vuole portare avanti la modi ca il peer attende la risposta di esito dal coordinatore.
Se la risposta contiene esito positivo il thread ObjManager intraprende le azioni conseguenti all'aver ottenuto l'oggetto (ad esempio aumenta lo score associato al peer di 20 punti).
Ogni peer che è coordinatore di almeno un oggetto passivo esegue il thread Coor- dinatorHandler; questo thread è responsabile delle modi che agli oggetti passivi di cui il peer è coordinatore. Il compito principale dei CoordinatorHandler è attendere le comunicazioni dagli altri peer provenienti dalla JXTA BiDiPipe; alla ricezione di un messaggio di modi ca di un oggetto passivo il coordinatore esegue il lock sul- l'oggetto ri utando le richieste provenienti da altri peer per quell'oggetto, mentre continua a servire le richieste riguardanti gli altri oggetti per cui è coordinatore. Dopo aver eseguito il lock sull'oggetto:
Controlla se l'oggetto richiesto fa parte degli oggetti per cui è coordinatore. Controlla se l'oggetto richiesto è valido, cioè se lo score associato è maggiore
di 0.
Invia al peer richiedente lo stato dell'oggetto, utilizzando la stessa BiDiPipe. Attende la risposta del peer; se il peer comunica di voler proseguire la modi ca:
Modi ca l'advertisement per oggetto: decrementa di 20 lo score; assegna alla variabile timestamp il valore rilevato al momento della modi ca. Esegue una nuova pubblicazione dell'advertisement.
4.7. MODIFICA OGGETTI PASSIVI 117 Invia al peer richiedente un messaggio che indica l'esito della modi ca
dell'oggetto.
Tutte le comunicazioni tra peer richiedente e coordinatore vengono ese- guite sulla stessa pipe in quanto bidirezionale.
Se il peer comunica di non voler eseguire la modica oppure se entro un cer- to timeout non risponde, l'operazione di modi ca termina (ovviamente sen- za l'aggiornamento dello score); il coordinatore rilascia il lock sull'oggetto, permettendo ad altri peer di richiede la modi ca.
A seguito della modi ca e nuova pubblicazione dell'oggetto tutti i peer della regione riceveranno un advertisement per l'oggetto modi cato che sostituisce au- tomaticamente il vecchio advertisement dell'oggetto presente nelle loro cache; ciò è possibile in quanto il metodo equals della classe ObjectAdv si basa sull'ugua- glianza degli identi catori; l'advertisement pubblicato dopo la modi ca ha lo stesso identi catore di quello già presente nelle cache remote dei peer, dunque rimpiazza l'advertisement già presente.
A causa dei ritardi che si possono veri care sulla rete, potrebbe veri carsi che i peer ricevano gli advertisement in sequenza sbagliata. Consideriamo il seguente esempio.
Esempio 5.2: i peer A, B, C appartengono alla regione Rk; la regione contiene
anche l'oggetto obji. Inizialmente l'oggetto viene modi cato dal peer A, che pubblica
l'advertisement modi cato obji(1); successivamente il peer B esegue una modi ca
su obji(1), pubblicando obji(2). Un peer C potrebbe ricevere prima obji(2) e solo
successivamente obji(1), che va a sostituire la versione corretta dell'oggetto ricevuta
precedentemente. Al ne di evitare questa situazione ogni peer, prima di rimpiazzare l'advertisement che possiede in cache con quello che riceve confronta i timestamp. Se l'advertisement appena ricevuto ha un timestamp maggiore rispetto a quelli che ha in cache signi ca che si sta ricevendo una modi ca consistente dell'oggetto e si esegue il rimpiazzo; altrimenti signi ca che l'advertisement appena arrivato rappresenta un aggiornamento precedente rispetto a quello che si ha già in cache che non viene rimpiazzato.
4.7.3 Modi ca oggetti sulla mappa
In questa sezione vengono descritte le tecniche utilizzate per l'implementazione della modi ca di oggetti passivi che non hanno rappresentazione come oggetti condivisi, ma costituiscono solo oggetti gra ci della mappa del mondo virtuale (v. sezione 3.3.5).
Distinguiamo due casi:
L'area di noti ca aggiornamento dell'oggetto non contiene altri peer oltre al peer interessato alla modi ca dell'oggetto. Questa situazione non crea proble- mi in quanto il peer non si trova in con itto con nessun altro peer, dunque diventa coordinatore dell'oggetto: crea una istanza della classe ObjectAdv, inserisce il proprio identi catore come peer coordinatore dell'oggetto, esegue la modi ca sull'oggetto, pubblica dell'advertisement nella regione attraverso il DiscoveryService.
L'area di noti ca aggiornamento dell'oggetto contiene altri peer oltre al peer interessato alla modi ca dell'oggetto. La coordinazione tra i peer si ottiene mettendo in pratica una richiesta di consenso: il peer che intende richiedere l'oggetto passivo invia una comunicazione su una JXTA propagate pipe. Il messaggio inviato contiene il timestamp dell'istante dell'invio e altre informa- zioni. Inoltre il peer si mette in attesa di ricevere lo stesso tipo di comuni- cazione dagli altri peer: i messaggi vengono mantenuti in una struttura dati. Allo scadere di un certo timeout il peer esegue un controllo sui messaggi rice- vuti per veri care se lui stesso è stato il primo peer ad eseguire la richiesta di modi ca. In tal caso diventa coordinatore dell'oggetto, esegue la modi ca e pubblica l'advertisement nella regione.
Il metodo candidateForCoordinator() della classe PeerDve implementa la procedura descritta.