SnippetSearch Database di snippet bilanciato e replicato di Gianluigi Salvi 172653 Reti di calcolatori LS – Prof. A.Corradi.

Presentazione sul tema: "SnippetSearch Database di snippet bilanciato e replicato di Gianluigi Salvi 172653 Reti di calcolatori LS – Prof. A.Corradi."— Transcript della presentazione:

1 SnippetSearch Database di snippet bilanciato e replicato di Gianluigi Salvi 172653 Reti di calcolatori LS – Prof. A.Corradi

2 Cosa sono gli snippet? Uno snippet non è altro che del semplice codice in un qualsiasi linguaggio di programmazione. Solitamente molto riutilizzabile, anche in contesti molto diversi tra loro. Uno snippet può essere un semplice ciclo foreach, un if…then…else o anche un codice molto lungo, come quello per la serializzazione di un oggetto o l’invio di una e-mail.

3 Introduzione Gli snippet sono stati da poco introdotti negli editor IDE più noti, ma sono disponibili già da anni, sotto forma di plugin o scaricabili via web. Quello che manca è la centralizzazione e la standardizzazione del servizio: le interfacce dei tanti siti web sono non standard e inserire o ricercare uno snippet su tutta rete internet è un’operazione che richiede un certo tempo.

4 Obiettivi Realizzare un servizio che permetta di cercare o inserire su un server lo snippet desiderato Efficienza: Il servizio deve essere load balanced Affidabilità: Il servizio deve essere replicato Correttezza: I dati forniti dal server devono essere affidabili Trasparenza: La gestione del collegamento e del recovery deve essere trasparente al client

5 Modello lato client I vari client non si conoscono tra loro, ma inviano il codice su un server unico che provvede a salvarlo in memoria e renderlo disponibile per tutti gli altri. L’architettura scelta è quindi quella di client/server tradizionale. La scelta di reti peer to peer, non era adatta in quanto sarebbe stato necessario implementare un file system distribuito su cui salvare gli snippet.

6 Modello lato server Efficienza: Per garantire velocità di risposta ai client connessi è necessario smistare le richieste su più server, questo introduce però un problema di sincronizzazione al momento dell’aggiornamento del database. Affidabilità: Per garantire tolleranza ai guasti i server devono essere in grado di controllarsi ed effettuare rielezioni in modo trasparente. Per rispondere al client anche in caso di caduta del server è necessario che tutti i server si sincronizzino ad ogni richiesta da parte del client. È stato implementato un modello di replicazione a copie attive. Correttezza: Per garantire la correttezza delle risposte i server di uno stesso gruppo si coordinano tra loro prima di fornire una risposta ai client. Trasparenza: Le operazioni di riconnessione avvengono in maniera trasparente sia in fase di connessione (bilanciamento) del client, sia in caso di rielezione del master.

7 Descrizione del sistema Il sistema è diviso in client che si connettono ad un server centrale che li smista verso il master meno carico. I vari master comunicano con degli slave per sincronizzare lo stato e verificare la correttezza delle risposte prima di inviarle al client.

8 Architettura La replicazione è a copie attive, ciò significa che master e slave eseguono contemporaneamente tutte le operazioni richieste dai client. Il dialogo tra master e slave è del tipo client/server, così pure come quello tra client e master server. Sono previsti due protocolli di recovery degli slave in caso di caduta del master: se il DNS è ancora attivo la rielezione avviene in modo centralizzato, altrimenti gli slave si coordinano tra loro.

9 Master e slave Il sistema è diviso in gruppi coordinati da un server centrale denominato DNS. Ogni gruppo risponde ad un master che raccoglie le richieste degli utenti Gli slave si registrano presso il master I client inviano richieste al master che le invia a sua volta agli slave registrati presso di lui Successivamente il master e i vari slave iniziano a computare la richiesta e registrano presso il master il risultato. Il master provvede a inviare al client la risposta esatta dopo aver verificato che tutte le risposte coincidano.

10 Coordinamento tra server Il DNS controlla continuamente che i server master siano online I master controllano il loro gruppo di slave e i client registrati Gli slave controllano (più raramente) che il DNS sia ancora attivo.

11 Registrazione client Il client si registra presso il DNS che, in modo trasparente, lo redirige verso il master con meno client connessi. Il master comunica agli slave che è entrato un nuovo client.

12 Ricerca nel database Il client invia una Search al master Il master invia la Search agli slave e inizia a eseguire il calcolo Gli slave eseguono la ricerca e registrano il risultato sul master Dopo che tutti gli slave hanno comunicato il risultato del calcolo si controlla che tutte le risposte coincidano e si invia la risposta al client

13 Invio di snippet Il client invia uno snippet di codice Il master invia la notifica di update agli slave e al DNS Il DNS invia la notifica di update a tutti i master dei vari gruppi

14 Rielezione con DNS ? Il DNS controlla periodicamente i master. Se il master va offline elegge un nuovo master Quando uno slave viene eletto come master lo comunica agli altri slave del suo gruppo che provvedono a registrarsi presso di lui

15 Rielezione distribuita ? ? Gli slave controllano che il DNS sia ancora attivo, in caso contrario, se il master va offline si coordinano per la rielezione del master.

16 Conclusioni Lo sviluppo del software ha messo in evidenza la complessità del coordinamento e sincronizzazione in ambito distribuito e la necessità di una progettazione molto approfondita Ci si è resi conto della necessità di compromessi tra affidabilità e efficienza e dell’importanza di tenere sempre presente la reale fattibilità di una certa soluzione in un dato contesto

17 Sviluppi futuri Bilanciamento dinamico dei client  Se il server a cui un client è connesso è molto carico deve essere possibile redirigere dinamicamente il client su un altro server Configurazione automatica dei gruppi  La scelta di quali e quanti server tra quelli disponibili lavorino in bilanciamento (per garantire maggiore efficienza) e quanti in replicazione attiva deve essere automatizzabile Possibilità di decidere se un server deve collegarsi come slave o come master Gestione dell’autenticazione degli utenti Implementazione di servizi aggiuntivi quali votazione degli script, numero di download effettuati, ecc.