Modica di oggetti passivi

Nella sezione precedente abbiamo descritto come recuperare gli oggetti passivi; analizziamo ora diverse situazioni che si possono vericare per la modica un oggetto.

3.3. GESTIONE DEGLI OGGETTI PASSIVI 85 Peer Oggetto passivo A B C δ r

Figura 3.12: Area critica di un oggetto passivo

E' importante mettere in evidenza che JaDE suppone che un peer possa mo- dicare lo stato di un oggetto solo quando si trova in prossimità di esso. Questa assunzione ci permette di denire un insieme di ottimizzazioni che consentono di ammettere il pluralismo nelle strategie di lettura/aggiornamenti degli oggetti senza sacricare la consistenza.

In prima istanza consideriamo i seguenti aspetti:

ˆ Deniamo l'area di modica di un oggetto passivo come area denita dal disco di raggio r e con centro la posizione dell'oggetto (v. gura 3.12).

ˆ Deniamo l'area di notica dell'aggiornamento di un oggetto passivo: area denita dal disco di raggio δ e con centro la posizione dell'oggetto (v. gura 3.12).

Osserviamo che nel mondo virtuale possono vericarsi situazioni di particolare aollamento delle zone circostanti ad un certo oggetto in quanto i peer sono richiamati dalla presenza dell'oggetto stesso. In questi casi occorre assicurare la corretta sequenza di modica dell'oggetto da parte di un insieme di peer in modo tale da garantire la consistenza dello stato dell'oggetto.

Peer Oggetto passivo

A

B

Figura 3.13: Area critica di un oggetto passivo

ˆ Supponiamo che un peer possa eseguire la modica di un oggetto passivo solo se la sua posizione si trova all'interno dell'area di modica.

ˆ Il raggio δ dell'area di notica aggiornamento viene determinato in modo tale che un peer che si trova fuori dall'area di notica aggiornamento possa ricevere gli eventuali aggiornamenti dell'oggetto prima di raggiunger l'area di modica dell'oggetto stesso. A questo scopo si considera:

 La velocità di spostamento massima consentita ai peer.

 Il ritardo massimo che si verica per la propagazione degli aggiornamenti nella rete.

Bisogna considerare che i tempi medi di propagazione nella rete degli aggior- namenti di oggetti passivi utilizzati per la denizione del raggio δ rappresenta una stima approssimata in quanto i tempi possono variare dinamicamente; in- fatti dobbiamo considerare il traco di rete che può portare a situazioni di congestione della rete e perdita di messaggi.

Dunque si deve trovare un compromesso tra consistenza dello stato degli og- getti e grado di centralizzazione a carico di alcuni peer; infatti se si permettesse

3.3. GESTIONE DEGLI OGGETTI PASSIVI 87

Peer Oggetto passivo

Pi Pj

Figura 3.14: Modiche concorrenti tra i peer Pi e Pj

solo al peer coordinatore di eseguire la modica degli oggetti allora non avreb- bero mai problemi di consistenza in quanto il coordinatore assicura la corretta sequenzializzazione delle modiche agli oggetti. Tuttavia decidiamo di intro- durre l'area di notica dell'aggiornamento a costo di dover sostenere con bassa probabilità l'inconsistenza di oggetti passivi.

Queste assunzioni sul raggio δ ci permettono di fare alcune ottimizzazioni. Sotto queste ipotesi individuiamo diversi casi:

ˆ Se un peer si trova nell'area di modica di un oggetto e non rileva nessun altro peer sia nell'area di modica che nell'area di notica aggiornamenti allora il peer stesso può leggere lo stato dell'oggetto dalla propria cache, eseguire la mo- dica e inviare l'aggiornamento ai peer della regione. Questo comportamento del peer permette di garantire la consistenza dell'oggetto.

Esempio 1: Nella gura 3.12 viene mostrato il peer A che si trova nell'area di modica di un oggetto passivo obj1; il peer A verica che nell'area di notica

aggiornamento di raggio δ non ci siano altri peer, quindi legge l'oggetto dalla propria cache, lo modica, invia l'aggiornamento a tutti i peer della regione.

Il peer A è libero di spostarsi in qualsiasi direzione. La denizione del raggio dell'area di notica aggiornamento garantisce (entro i limiti che abbiamo de- scritto) che eventuali altri peer che successivamente raggiungeranno l'area di modica dell'oggetto sicuramente dispongano dell'aggiornamento dell'oggetto. Esempio 2: caso limite Nella gura 3.13 viene mostrato il peer A che si trova nell'area di modica di un oggetto passivo obj1; il peer A verica che

nell'area di notica aggiornamento di raggio δ non ci siano altri peer, quindi legge l'oggetto dalla propria cache, lo modica, invia l'aggiornamento a tutti i peer della regione. Appena terminate queste operazioni il peer A si allontana subito dall'oggetto (traiettoria retta e velocità massima costante).

Ora notiamo il peer B (che si trovava in posizione prossima all'area di notica aggiornamenti) eseguire uno spostamento in direzione dell'oggetto percorren- do la distanza minima pari al raggio δ; considerando anche la traiettoria e la velocità massima permessa ai peer, il peer B, riceverà con alta probabilità l'aggiornamento dell'oggetto obj1 prima di giungere nell'area di modica (per

quanto detto sopra a proposito della determinazione del raggio δ). Verichia- mo che quando il peer B giunge nell'area di modica dell'oggetto obj1 non

rileva nessun peer (il peer A ha già lasciato la zona). Quindi il peer B può leggere l'oggetto dalla propria cache con la certezza di disporre di informazio- ni aggiornate e consistenti; esegue la modica e invia l'aggiornamento nella regione.

ˆ Se un peer si trova nell'area di modica di un oggetto e rileva uno o più peer nell'area di notica non può assumere di possedere la cache aggiornata perchè la presenza di altri peer potrebbe signicare che sono state eseguite modiche recenti all'oggetto, il cui aggiornamento non è ancora giunto nella cache locale. Quindi il peer non può leggere lo stato dell'oggetto dalla propra cache perchè non ha la certezza di disporre della versione aggiornata.

In questo caso interviene il coordinatore dell'oggetto come il peer che man- tiene la versione aggiornata dell'oggetto. Un peer nella situazione descritta sopra e che intende modicare un oggetto deve leggere lo stato dell'oggetto direttamente dal coordinatore attraverso le seguenti fasi:

3.3. GESTIONE DEGLI OGGETTI PASSIVI 89  Richiede al coordinatore la lettura dell'oggetto inviando un messaggio

attraverso la pipe su cui il coordinatore è in attesa.

 Nell'istante in cui il coordinatore riceve la richiesta esegue il lock sull'og- getto (sia in lettura che scrittura: non accetta le richieste sia di lettura che di modica provenienti dagli altri peer) e invia lo stato dell'oggetto al peer richiedente; la fase di lettura è necessaria in quanto la copia che il peer dispone in cache potrebbe non essere aggiornata perchè l'area criti- ca contiene altri peer che potenzialmente hanno modicato l'oggetto ma l'aggiornamento non è ancora arrivato nelle cache degli altri peer.

 Una volta ricevuto lo stato dell'oggetto dal coordinatore il peer decide se proseguire o meno la modica.

* Nel caso in cui decida di non proseguire nella modica invia un messaggio al coordinatore il quale eseguirà l'unlock dell'oggetto. * Nel caso in cui il peer decida di proseguire la modica dell'oggetto il

coordinatore mantiene il lock.

 Conclusa la modica dell'oggetto il coordinatore invia al peer un messag- gio contenete l'esito.

 Il coordinatore comunica il nuovo stato dell'oggetto ai peer della regione ed esegue l'unlock dell'oggetto.

Esempio 3: inconsistenze Quanto detto in questo paragrafo garantisce la consistenza delle modiche agli oggetti. Senza l'intervento del coordinatore si hanno situazioni di inconsistenze come quella mostrata in gura 3.14 che si descrive di seguito.

Quando due o più peer si trovano entrambi nell'area di modica si verica il problema delle scritture quasi concorrenti. Può vericarsi che due o più peer leggano l'oggetto dalla propria cache locale, lo modichino e inviino l'aggior- namento. Nell'esempio mostrato in gura si verica che il peer Pi modica

l'oggetto e invia l'aggiornamento. L'aggiornamento non giunge tempestiva- mente a Pj, il quale a sua volta, modica l'oggetto letto dalla propria cache

(non consistente!) e invia l'aggiornamento. Si verica quindi che nella regione si propaga uno stato non consistente dell'oggetto.

Il formato dei messaggi di richiesta al coordinatore di modica per un oggetto passivo è il seguente

ˆ Identicatore del peer richiedente. ˆ Nome del peer richiedente.

ˆ Identicatore dell'oggetto richiesto. ˆ Timestamp della richiesta.

Il coordinatore risponde inviando un messaggio contenente le seguenti informa- zioni:

ˆ Identicatore dell'oggetto modicato. ˆ Esito della modica.

Notiamo che nella soluzione proposta sono i peer stessi che, nell'intenzione di mo- dicare un oggetto passivo, rilevano se la loro posizione appartiene o meno all'area di notica dell'oggetto e quindi adottano la corretta procedura. In alternativa, il coor- dinatore stesso, prima di accettare una richiesta, potrebbe vericare se l'area critica dell'oggetto contiene più di un peer; tuttavia per non incrementare ulteriormente il carico del coordinatore preferiamo la prima soluzione.

Modica di oggetto passivo senza coordinatore

Nella congurazione iniziale del mondo virtuale di JaDE sono previsti degli oggetti passivi che vengono collocati in alcune zone del mondo. La mappa del mondo virtuale è ssata e uguale per tutti i peer quindi ogni nodo è in grado di rilevare la presenza di questi oggetti sul territorio. Tali oggetti sono rilevati solo visivamente dai nodi partecipanti come oggetti graci in quanto non hanno una rappresentazione come oggetti dell'applicazione distribuita ma solo come componenti del layer graco. Dal punto di vista della rappresentazione graca questi oggetti sono uguali agli

3.3. GESTIONE DEGLI OGGETTI PASSIVI 91 P3 P2 P1 Peer Oggetto passivo

Figura 3.15: Area di notica di un oggetto passivo con tre peer al suo interno.

oggetti passivi creati dai peer; a dierenza di questi ultimi però essi non contengono l'informazione riguardante il coordinatore.

Un peer entrando in una regione del mondo virtuale e visualizzando la rap- presentazione graca dell'oggetto potrebbe voler modicare quell'oggetto. In quel momento la modica dello stato dell'oggetto deve essere comunicata a tutti gli altri peer ed è per questo motivo che è necessario creare un oggetto nel supporto che rappresenta lo stato dell'oggetto e che può essere trasmesso agli altri peer della rete. Notiamo che le primitive grache fornite dall'interfaccia graca permettono al- l'utente di visualizzare le informazioni associate all'oggetto.

Dal momento che tale oggetto non dispone di una corrispondente struttura dati che descrive l'oggetto si deve stabilire una procedura che consenta a un peer di

modicare l'oggetto e di diventare eventualmente il coordinatore.

Osserviamo che se nell'area di notica aggiornamento dell'oggetto non vi sono al- tri peer fatta eccezione del peer che intende modicarlo, allora quest'ultimo procede alla creazione, quindi diventa coordinatore e modica l'oggetto; la creazione dell'og- getto consiste nel costruire una struttura dati che descrive lo stato dell'oggetto e l'invio di tale struttura a tutti i peer della regione.

Tuttavia possono vericarsi dei casi in cui più di un peer si trovi nell'area di notica aggiornamento dell'oggetto (v. gura 3.15); ognuno di essi rileva l'oggetto graco con l'intenzione di modicarlo. In queste situazioni osserviamo due o più peer competere per ottenere uno stesso oggetto e quindi per diventarne il coordinatore.

Di seguito si illustra una soluzione per risolvere la situazione di conitto tra i peer.

Ogni peer interessato alla modica dell'oggetto esegue le seguenti azioni: ˆ Comunica il proprio timestamp a tutti i peer vicini nell'area dell'oggetto3_.

ˆ Attende un certo tempo t, durante il quale riceve le comunicazioni (i time- stamp) dai vicini.

ˆ Allo scadere del tempo t esegue il controllo sui timestamp ricevuti: se egli stesso è stato il primo peer a fare la richiesta, allora modica l'oggetto e ne diventa coordinatore altrimenti non può fare nulla.

Il valore dell'intervallo t viene deciso in base a quanti peer sono presenti nell'area critica dell'oggetto: se ce ne sono molti occorre prevedere un tempo maggiore anchè si possano ricevere i messaggi da tutti.

Notiamo che le comunicazioni tra peer richieste per l'esecuzione della procedura suddetta vengono eettuate attraverso il canale astratto associato alla regione.

Di seguito si descrive il formato del messaggio inviato dal peer per comunicare agli altri peer il proprio timestamp:

ˆ Identicatore del peer richiedente.

3.4. ARCHITETTURA DEL SISTEMA 93