Il caching introduce l’overhead e la complessità di dover assicurare la consistenza, il che può ridurre i benefici alla performance introdotti con esso; in un sistema distribuito, bisogna inoltre far fronte alle complicazioni per le comunicazioni e alla caduta di hosts.

I protocolli per la consistenza della cache sono stati intensamente studiati nelle architetture multiprocessore, i quali però suppongono un mezzo di comunicazione sicuro, il bus di sistema. In un sistema distribuito, tuttavia, possono accadere dei guasti, si può perdere un messaggio e un controllo normale porta ad una perdita di prestazioni.

Il protocollo Leases [5] si occupa di mantenere la consistenza utilizzando dei clock fisici. Il modello matematico associato, indica che utilizzando contratti di durata breve, le prestazioni sono pressoché quelle ottimali.

2. Leases

Un lease è un contratto che da al suo possessore specifici diritti su una proprietà per un certo limitato periodo di tempo.

Nel nostro contesto di caching, un lease garantisce al suo possessore il controllo della scrittura di un certo dato, fino alla scadenza del contratto, il server deve chiedere il permesso all’attuale possessore del lease il permesso per poter scrivere quel dato. Quando il possessore approva una scrittura, invalida la copia locale del dato.

La cache utilizzante leases, richiede un valido contratto sul dato (in aggiunta al tenere il dato stesso) prima di dichiarare valido il dato per la lettura. Quando il dato è caricato dal server (che è la locazione primaria dei dati) esso deve ritornare un lease che garantisce che il dato non sarà scritto da nessun client fino alla scadenza del contratto, a meno che il server non riceva la "delega" dal possessore del contratto.

Se il dato è letto entro i termini del lease, (e se il dato è ancora in cache) la cache stessa dà accesso al dato senza comunicare niente al server.

Quando un lease espira, una lettura sul dato, richiede che la cache prima estenda il contratto sul dato, poi ci sia l’update del dato (se c’è stata modifica). Se un cliente scrive un dato, il server deve posticipare la richiesta a quando ha ottenuto approvazione oppure il contratto scade.

Come esempio consideriamo una stazione di lavoro senza disco utilizzata per la produzione di documenti di testo.

Quando la stazione esegue latex per la prima volta, ottiene un lease sul file binario contenente latex per (diciamo) un decina di secondi. Un altro accesso allo stesso file allo stesso file 5 sec. dopo può usare la versione in cache del file, senza richieste al server. Una richiesta dopo 10 sec. porta ad una domanda al server. Quando una nuova versione di latex è installata, la scrittura è posticipata fino a che il possessore del contratto dà la sua approvazione; se il possessore per qualche ragione è irraggiungibile, il ritardo continua fino alla scadenza del contratto.

I contratti con scadenza a breve termine hanno alcuni vantaggi.

Il primo è di minimizzare il ritardo dovuto ad una caduta di un client o di un server, perché in caso di caduta bisogna aspettare la scadenza naturale del contratto prima della scrittura (per evitare una starvation di scritture, il server non dà nuovi lease su un file se si sta aspettando la scadenza del contratto). Se un server si recupera prima della scadenza, allora deve comunque onorare il contratto (di solito si tiene un record con tutti i traffici effettuati).

Un contratto a breve termine inoltre minimizza le false scritture condivise che possono accadere. Con falsa scrittura condivisa, si intende un conflitto di contratti, quando in realtà non esiste nessun conflitto di accesso; di solito essi possono accadere quando un client scrive un file coperto da contratto mantenuto da un altro client che però non sta accedendo attualmente al file. Se il contratto non è di breve durata, si possono creare overhead a causa si messaggi inutili scambiati tra client, quando non esiste un vero conflitto.

Infine un contratto di breve durata riduce la capacità di memorizzazione del server (si cancellano prima i record dei contratti), anche se il tenere i record di tutti i traffici porta ad un modesto overhead, ad esempio per un client che detiene un centinaio di contratti, la somma totale è di circa 1 Kbyte.

La scelta del termine del contratto è quindi di primaria importanza: è un compromesso tra minimizzare l’overhead da lease vs. minimizzare false condivisioni.

Questo compromesso si applica sia alla carico del server che alle risposte dei client.

Il modello analitico matematico associato porta ad alcune formule per la determinazione della durata del contratto, che però noi non vedremo.

3. Fault tolerance in leases

Leases assicura la consistenza tenendo conto che tutti i terminali e la rete possano soffrire solo dei seguenti tipi di guasto: perdita di messaggi (inclusa la partizione della rete), errori del client o del server (supponendo che le scritture siano persistenti una volta fatte sul server).

Tuttavia leases dipende molto dal clock, quindi tutti i malfunzionamenti ad esso relativi sono critici. In particolare se il clock di un server "corre", si possono verificare degli errori, perché il server stesso può consentire una scrittura prima che il termine del contratto sia scaduto presso il client. Analogamente, se il clock del client sbaglia rallentando, il client è convinto che il contratto sia ancora valido, mentre esso è già scaduto.

L’errore opposto (un clock lento di un server, oppure il clock veloce di un client) non porta nessuna inconsistenza, ma genera traffico extra (i contratti sono più brevi).

I guasti relativi al clock sono però meno comuni rispetto alla caduta delle comunicazioni e di un server ed inoltre sono facilmente rilevabili da un protocollo di sincronizzazione oppure includendo un esplicito timestamp nei messaggi di contratto.

Inoltre si può fare la ragionevole assunzione che i clock dei nodi siano sincronizzati entro un e che è piccolo relativamente ai tempi del protocollo leases. Al massimo, si può pensare che i clock dei vari nodi oscillino al più in un intervallo definito, quindi basta inserire tempi di guardia.

4. Conclusioni

Oltre alla consistenza della cache, leases si può applicare a sistemi multiprocessore con memoria condivisa anche su larga scala, tuttavia in questo caso bisogna fare un’analisi adeguata costi - benefici, soprattutto riguardo all’introduzione di timer nella memoria e all’abilità del software di gestire i guasti.

Si stanno studiando inoltre possibili inserimenti dei lease all’interno di protocolli di gestione delle transazioni e di protocolli di trasporto.