Protocollo per la gestione dell'anello e del recovery
Ogni replica manda, a intervalli di tempo regolari, un messaggio del tipo "IAmAlive" alla replica che la segue nella struttura ad anello, per segnalare il proprio stato attivo. Contemporaneamente deve ricevere un analogo messaggio dalla replica che la precede: se non arriva entro un certo lasso di tempo, si assume che la replica precedente sia fallita, e quindi deve essere eseguita una procedura di recovery dell'anello.
Il recovery viene realizzato in questo modo: chi rileva una situazione di guasto (vedi sopra) manda in circolo nell'anello un messaggio del tipo "IAmNewNext" che contiene l'indirizzo della replica fallita. Quando una replica riceve questo messaggio, controlla che l'indirizzo della replica fallita non corrisponda alla propria successiva; se non corrisponde di passa il messaggio tale e quale, mentre se corrisponde si assume come nuova replica successiva quella che ha generato il messaggio, alla quale si manda un messaggio di notifica del tipo "IAmNewPrevious", per ricostruire così l'anello.
Il recovery tiene conto anche della rigenerazione del token, nel caso in cui fallisca la replica che lo possiede. La rigenerazione viene realizzata in questo modo: il token viene ricevuto, e in questo istante diventa un token posseduto (lo si usa per eseguire i servizi in attesa). Quando viene finita l'esecuzione dei servizi in coda, il token aggiornato è pronto per essere spedito alla replica successiva. Quando viene spedito (e viene confermata la ricezione da parte della replica successiva) il token entra in uno stato congelato (è una copia "vecchia"), finché non arriva la notifica, sempre dalla replica successiva, che può essere rilasciato. Se una replica riceve un messaggio "IAmNewNext", vuole dire che la successiva è fallita, e se il token è nello stato congelato, deve essere ritrasmesso alla nuova replica successiva.
Nota: il recovery, nel caso in cui l'anello è composto solo da due repliche, è molto più semplice, infatti chi rileva un guasto rimane isolato (non occorre più gestire l'anello...).
Un UA richiede ad una replica, tramite un messaggio "LookUpRequest", l'indirizzo della replica meno carica su cui eseguire un servizio. L'UA riceve un messaggio di risposta "LookUpReply" che contiene tale indirizzo, ed invia una richiesta di esecuzione "Execute" a tale replica. Questa replica risponderà all'UA con il messaggio "Executed" contenente il servizio eseguito.
La replica che riceve il messaggio di richiesta di lookup, fa circolare nell'anello un messaggio "Find" che contiene il proprio numero di servizi in esecuzione. Chi riceve un messaggio "Find" controlla dapprima che non sia stato generato localmente (in questo caso crea la risposta "LookUpReply" con l'indirizzo contenuto in "Find"); se il messaggio non è stato generato localmente, allora verifica che non ci siano meno servizi in esecuzione; in tal caso "sovrascrive" il proprio indirizzo e il proprio numero di servizi in esecuzione e manda il messaggio alla replica successiva.
Protocollo per l'esecuzione e la gestione del token
Se la richiesta riguarda un servizio che non ha bisogno del token, va eseguita subito. Altrimenti la richiesta viene accodata in attesa dell'arrivo del token. Quando arriva il token i servizi accodati sono eseguiti in sequenza, ed al termine dell'esecuzione il token aggiornato viene spedito alla replica successiva. Nota: se arriva il token e non ci sono servizi da eseguire, il token va tenuto per un tempo minimo prima di spedirlo, al fine di evitare che nell'anello vi sia un token che circola senza mai fermarsi, con conseguente aumento del traffico di rete.
Ottimizzazione della gestione dell'anello e del token.
Confrontando i due protocolli descritti sopra, è naturale pensare di utilizzare il protocollo che serve per segnalare il proprio stato attivo per fare circolare anche il token. L'idea è questa: il messaggio con cui si segnala il proprio stato attivo può essere "IAmAlive" oppure un token. Così può succedere che nell'anello circolino solo messaggi "IAmAlive" quando il token è posseduto da una replica che lo sta usando, oppure possono esserci tanti messaggi "IAmAlive" ma un solo token.