Sono realizzati tramite oggetti serializzabili da inserire nei datagrammi. Discendono tutti da una superclasse astratta che costituisce un generico messaggio serializzabile. Il datagramma è implementato in Java dall'oggetto DatagramPacket.
E' realizzata tramite le socket UDP messe a dispozione tramite l'oggetto DatagramSocket contenuto nel package java.net.
UA e repliche sono realizzate da insiemi di thread che interagiscono tra loro. Questi thread realizzano i vari protocolli, e nell'ambito del progetto sono stati chiamati "gestori".
L'UA è composto da un gestore delle richieste dei clienti che genera un thread (gestore dell'esecuzione) per ogni richiesta del cliente. E' una tipica struttura di un processo che contiene un dispatcher (veloce) delle richieste dei clienti, il quale genera un thread in parallelo per ogni richiesta.
La replica, visti i vari protocolli che deve implementare, è composta da vari gestori:
E' messo a disposizione di ogni potenziale utente del servizio replicato un oggetto chiamato "ServiziReplicati" che fornisce un metodo per ogni tipo di servizio offerto. Questo oggetto funziona come uno stub, perché traduce una richiesta sotto forma di chiamata ad un metodo. Questa chiamata di metodo nasconde tutte le comunicazioni con l'UA locale.
L'UA aspetta una richiesta da un cliente (il quale usa l'oggetto "ServiziReplicati") attraverso il messaggio "MsgClientRequest".
Quando arriva un messaggio di questo tipo viene creato un thread "Esecutore" che si occupa di quella singola richiesta.
L'esecutore comincia con un fase di lookup verso una replica di cui conosce l'indirizzo, inviandole un messaggio "MsgLookUpRequest", ed aspetta la risposta "MsgLookUpReply" che contiene l'indirizzo delle replica meno carica. Successivamente manda la richiesta di esecuzione ("MsgExecute") alla replica meno carica ed aspetta la risposta da quest'ultima. Arrivata la risposta risponde al cliente con il messaggio "MsgClientReply".
La gestione dell'attesa dei messaggi di risposta avviene con meccanismi di timeout, di verifica di stato attivo delle repliche ed eventuali ritrasmissioni. Se fallisce la replica sulla quale sta eseguendo il servizio, verrà ripetuta la procedura a partire da un nuovo lookup.
L'UA è stato costruito in modo che mantenga in memoria gli indirizzi di tutte le repliche di cui viene a conoscenza, in modo che se fallisce la replica verso cui effettua il lookup, abbia a disposizione l'indirizzo di un'altra.
E' composta da vari gestori, come descritto nel paragrafo "Componenti".
Non è stato individuato come una delle parti e dei protocolli di base del progetto, ma è stato necessario realizzarlo per permettere la costruzione della struttura ad anello attraverso l'inserimento successivo di nuove repliche che iniziano la loro esecuzione.
L'inserimento viene permesso "a valle": chi riceve una richiesta di inserimento, deve segnalare al richiedente l'indirizzo della replica che lo precede nell'anello, e deve segnalare a chi lo precede l'indirizzo della nuova replica successiva.
Il gestore dell'inserimento è composto da due thread paralleli ed indipendenti: il gestore "IAmUp", che aspetta una richiesta di inserimento, ed il gestore "YourNewNext" che deve aggiornare il link alla successiva nel'anello.
Chi invece effettua una richiesta di inserimento, aspetta l'indirizzo della replica che lo precederà nell'anello.
Il gestore dell'inserimento deve avere alta priorità perché deve mantenere l'anello in uno stato consistente. L'importante non è la decisione se è più o meno prioritario del recovery, ma che le priorità tra recovery ed inserimento siano diverse così che almeno uno dei due venga eseguito in maniera "atomica".
E' composto da alcuni thread principali , tra cui: ricevitore, segnalatore, recoverer.
Il ricevitore ha il compito di raccogliere i messaggi della replica precedente (MsgIAmAlive o MsgToken), e di sbloccare il segnalatore quando arriva un messaggio di questo tipo.
Il segnalatore effettua un'attesa con timeout ; se viene sbloccato dal ricevitore prima del timeout, manda alla replica successiva un messaggio (Token o IAmAlive), altrimenti (timeout) continua a mandare IAmAlive. Dopo alcuni timeout si è nel caso di rilevamento del guasto della replica precedente, e il segnalatore sblocca il thread che esegue la procedura di recovery del guasto (il recoverer).
Nota: quando il segnalatore invia il token, genera un thread parallelo che aspetta la conferma della ricezione (il token viene "congelato"), mentre per quanto riguarda il "rilascio" del token viene utilizzato un thread indipendente lanciato dal gestore del recovery. Questo gestore del rilascio non fa altro che aspettare un messaggio MsgReleaseToken e cambiare in conseguenza lo stato del token.
Il recoverer, se viene sbloccato dal segnalatore, esegue una delle due seguenti procedure: recovery dell'anello o recovery dei twins.
Il recovery dell'anello (si parla di anello se è composto da più di due repliche, altrimenti di parla di twins) avviene creando un messaggio MsgIAmNewNext che contiene l'indirizzo della replica fallita ed aspettando l'indirizzo (tramite il messaggio MsgIAmNewPrevious) di una replica che sarà la nuova precedente. Questo messaggio MsgIAmNewNext comincia a circolare, e si ferma sulla replica in cui l'indirizzo del failed coincide con il link alla replica successiva. Il messaggio MsgIAmNewNext è gestito da un thread indipendente (gestore IAmNewNext) creato dal gestore del recovery. Questo thread ha il compito di verificare l'uguaglianza descritta sopra, deve aggiornare il link alla replica successiva, e notificare a quest'ultima il proprio indirizzo tramite il messaggio MsgIAmNewPrevious. Questo gestore ha inoltre il compito di indicare al segnalatore di inviare la copia del token se il token è nella fase di "congelamento", perché in questo caso è fallita la replica successiva mentre possiede il token, che va quindi rigenerato.
Il recovery dei twins è invece più semplice, perché in questo caso occorrerà solo settare i parametri che indicano che si è rimasti isolati. Tutti i protocolli di gestione dell'anello, del token, recovery, ecc. vengono bloccati e rimangono in funzione il gestore dell'esecuzione, del lookup e dell'inserimento.
Riceve una richiesta (MsgExecute) da un UA ed esegue oppure accoda il servizio richiesto. I servizi accodato sono gestiti da un thread parallelo, che viene sbloccato quando il ricevitore rileva che è arrivato il token.
Questo protocollo è stato realizzato mediante l'esecuzione di due thread indipendenti: uno è chiamato gestore del lookup, l'altro gestore della ricerca (gestore find).
Il primo riceve una richiesta (MsgLookUpRequest) da un UA e genera un primo messaggio di ricerca (MsgFind); il secondo aspetta un MsgFind: quando lo riceve, verifica se è stato creato su questo host (dal gestore del lookup) e manda la risposta all'UA (MsgLookUpReply); altrimenti può mandare il messaggio inalterato alla replica successiva (caso in cui il numeri di servizi locali in esecuzione è maggiore di quello contenuto in MsgFind) oppure un nuovo messaggio MsgFind con il proprio indirizzo e numero di servizi in esecuzione (se questo è inferiore a quello del MsgFind ricevuto).
Gestore della verifica di stato attivo
E' un supporto agli altri protocolli quando occorre verificare se una replica è ancora attiva quando scatta un timeout nell'attesa di un messaggio di risposta. Riceve un messaggio MsgAreYouAlive e risponde (se la replica è attiva) con un messaggio di conferma (MsgAckAreYouAlive).
