Per quanto riguarda l' implementazione del servizio va sottolineato che il progetto non ha alcuna intenzione di proporsi ad esempio per una gestione efficente di Data Base, tant' è che tale DB è stato implementato molto semplicemente con un file ad accesso sequenziale nel quale sono memorizzate le entries
< nome utente - numero telefonico > .
La tolleranza ai guasti non può essere ottenuta se non con la replicazione, che a sua volta implica consistenza. Questi tre aspetti del mondo delle reti consentono differenti soluzioni rea- lizzative a seconda di come si intende affrontare la replicazione.
In questo progetto sono trattati due differenti modelli di replicazione:
- a copie effettive applicato ai Servers Telefonici (STs)
- a copia fredda applicato ai Name Servers (NSs).
Come specifica realizzativa del progetto è richiesta la tolleranza ad UN SOLO crash conse- guentemente sia il ST che il NS sono stati replicati in un' unica copia.
Le due copie dei STs sono effettive nel senso che nel sistema sono presenti due entità che gesti- scono DB privati e mettono a disposizione lo stesso servizio. Questo tipo di replicazione ha come conseguenza il fatto di poter realizzare la ridistribuzione del carico fra le copie presenti, a patto però che per esse venga mantenuta la consistenza.
Ridistribuzione del carico e consistenza sono due ulteriori aspetti dei sistemi distriduiti che, a differenza dei precedenti, non vengono trattati in questo progetto in un ottica generale estendibile a qualsiasi applicazione, bensì le loro soluzioni implementative sono specifiche, conseguentemente poco interessanti se non addirittura insufficienti in termini generali.
In effetti nell' applicazione il NS realizza una ridistribuzione del carico trivial in quanto, nel caso di sistema a regime dunque due ST registrati, invia alternativamente ai Clients (Cs) l' indirizzo dei STs senza considerare il carico presente su di essi; intendendo per carico il numero di connessioni aperte sui STs verso altrettanti Cs. Questa scelta è motivata fondamentalmente da ragioni di efficienza cosiderata la natura del servizio: supponendo una durata media costante di servizio, alternare l' assegnamento dei STs ritengo sia una buona strategia di ridistribuzione di carico in termini di rapporto costi benefici ( overhead ).
La funzionalità di gestore dei nomi, in base alle specifiche del progetto, è stata realizzata con un sistema di nomi piatto, utilizzando una semplice tabella di due elementi nella quale i NSs memorizzano le informazioni inviate dai STs durante la fase di registrazione
Per quanto riguarda la consistenza dei due DB gestiti indipendentemente dai rispettivi STs, va detto che l' applicazione presuppone il fatto che il tentativo di registrazione di un ST avvenga col proprio stato consistente rispetto allo stato del ST eventualmente presente in rete; cioè al momento della registrazione di un ST non viene effettuata nessuna verifica che il DB da esso gestito sia consistente col DB dell' eventuale ST già attivo in rete.
Le motivazioni che hanno portato a questa scelta sono fondamentalmente analoghe alle precedenti. La consistenza dei DB non è una specifica stringente del progetto: penso non ci siano dubbi sul fatto che servizi di questo tipo debbano mirare alla availability piuttosto che alla reliability.
Un minimo di controllo è invece garantito a run time durante la fase di aggiornamento del servizio effettuato da un' ulteriore elemento dell' applicazione: il Terminale (T) col quale è anche possibile, su richiesta dell' utente, effettuare l' inserimento di nuove o l' eliminazione di vecchie entries nel DB.
D' altra natura è la replicazione effettuata sui NSs. Le due copie presenti nell' applicazione a regime non sono effettive, cioè con le medesime capacità di escuzione, ma possiedono ruoli differenti, assumendo una relazione di tipo MASTER-SLAVE. La copia master è quella che effettivamente svolge le attività che competono al NS, mentre la copia slave verifica che il NS effettivo sia attivo, pronto a sostituirlo nel caso si presenti un malfunzionamento. Questo tipo di replicazione si discosta dalla precedente per la mancanza della capacità di ridistribuzione del carico fra i NSs, limite che rappresenta però l' arma vincente di questo modello perchè non è necessario il controllo reciproco che i due NS devono effettuare per il mantenimento della consistenza. Solamente la copia fredda deve controllare quella calda e questa unidirezionalità nel controllo realizza la consistenza per questo modello di replicazione.
Credo sia opportuno spendere qualche parola in più sulla unidirezionalità del coordinamento tra i NSs. Precedentemente ho introdotto questo termine facendo esplicitamente riferimento al mantenimento della consistenza intendendo sottolineare il fatto che il NS effettivo, essendo il manager dell' applicazione, non ha bisogno di acquisire lo stato del servizio da qualcun' altro come invece accade per il NS riflesso, il quale non ha modo di modificare lo stato se non acquisendolo dal NS effettivo. D' altro canto è evidente che entrambi i NSs debbano verificare la presenza dell' altro: il NS freddo deve garantire la continuità del servizio in caso di crash del NS caldo, il NS caldo deve mantenere la specifica di tolleranza ad UN guasto per cui deve essere predisposto ad accettare un nuovo NS freddo nel caso di crash di quello attuale.
Quanto detto può essere identificato come un protocollo di elezione al quale devono sottostare i NS attivi nel sistema.
Per questo modello di replicazione esiste dunque una bidirezionalità di comunicazione al fine di garantire la tolleranza al guasto, entrambi i NS si inviano messaggi, ma unidirezionalità di coordinamento. Mentre il messaggio che il NS freddo invia al NS caldo non ha nessun contenuto informativo ma segnala semplicemente il suo corretto funzionamento, il messaggio che il NS caldo invia al NS freddo ha il duplice effetto di segnalare il suo corretto funzionamento e mantenere la consistenza dei due NS in quanto il contenuto informativo rappresenta lo stato del servizio nella rete cioè le informazioni relative ai STs attivi in rete.
La sola registrazione dei STs al NS caldo non è sufficiente per realizzare correttamente la ridistribuzione di carico, ma occorre una trasmissione periodica di segnali di probe, affinchè il NS caldo possa inviare ai Cs indirizzi di STs effettivamente presenti nella rete.
L' aspetto più interessante del protocollo di elezione, conseguenza diretta del modello di replicazione adottato per i NSs, è il crash del NS caldo. In corrispodenza di tale evento il NS freddo non riceve più il messaggio contenente lo stato del servizio, conseguentemente scaduto un time-out di attesa si autoelegge NS caldo e si predispone per gestire le richieste di ST disponibile dei Cs e le richieste di registrazione dei STs essendo già a conoscenza dello stato del servizio. Ciò che il NS autoeletto non è in grado di fare è mantenere lo stato del servizio: i STs non sono in grado di rilevare il crash del NS caldo per cui continuano erroneamente ad inviare i segnali di probe ad una entità che non c' è più. Il nuovo NS, non ricevendo i segnali di probe inviati dai STs, li considera erroneamente in crash quando scadono i corrispondenti time-out. La soluzione a questo comportamento errato, adottata in questo progetto, consiste nel fare in modo che il nuovo NS comunichi ai STs presenti il nuovo indirizzo di rete al quale ridirigere i segnali di probe.
La reperibilità del NS è stata risolta utilizzando il broascast: ogni ST che intende registrarsi e C che richiede l' indirizzo di un ST attivo effettuano un Bcast su di una specifica porta predisposta dal NS. Nel caso nessun NS risponda a tale Bcast scatta un time-out al mittente per segnalare la condizione di servizio non abilitato, mentre SE È PRESENTE IL NS CALDO esso risponde con un messaggio contenente le due porte utilizzate per rispondere rispettivamente alle richieste dei STs e a quelle dei Cs.
Per conferire al progetto le caratteristiche di servizio di rete sia i ST che i NS sono stati im- plementati come demoni così facendo però si è persa la possibilità di poter avere una verifica di- retta a video del comportamento dell' applicazione nel merito dei managers (NSs) e dei fornitori (STs) del servizio. Per evitare di rendere oscuro il comportamento dell' applicazione ma anche per fornire ulteriori funzionalità si è introdotta nel progetto un ulteriore componente: il Terminale (T). Oltre a svolgere la funzione di monitoring del servizio in termini di NSs presenti e STs registrati, consente l' aggiornamento del servizio in seguito ad una interrogazione del NS effettivo per verificare la presenza di STs attivi in rete.