Con il diagramma seguente si schematizzano le principali operazioni che coinvolgono il Rappresentante durante il deployment.
Fig. 3.3
Schema Funzionamento Rappresentante (Collector)
Modulo 7: Server Multithread per raccolta Messaggi
Questo modulo si occupa di ricevere e smistare le richieste ricevute dagli altri nodi della rete e dal Committente.
Il generico Rappresentante è in grado di gestire contemporaneamente più deployment da parte di diversi Committenti utilizzando un’unica Cache.
Per ogni modello di comunicazione o protocollo utilizzato (es. SOAP, SSL, XML, RPC, TCP, SSH etc.) occorre implementare un diverso server che, a partire dalla richiesta ricevuta, crea i due stream in lettura/scrittura associati al canale di comunicazione da passare poi al Client. Il Client è un modulo generico ad alto livello che si occupa di gestire i vari comandi ricevibili e di leggere/scrivere dai canali con delle generiche funzioni di lettura/scrittura su stream.
Questo modello consente di disaccoppiare completamente la parte di comunicazione fisica da quella logica in modo da fornire una buona espandibilità del sistema e la possibilità di implementare nuovi protocolli senza dover entrare nella logica di funzionamento dell’applicazione.
Nella libreria da noi sviluppata si è fornito un server di test TCP che accetta messaggi su porte definite dall’utente; analogamente si è fornita la complementare primitiva di comunicazione Send basata su TCP.
Come sopra indicato il server non deve far altro che accettare la richiesta TCP ricevuta e creare i due canali di comunicazione di lettura e scrittura associati al socket. Una volta fatto ciò istanzia il Client e gli passa i descrittori dei due canali sopra creati; dopodichè il client si occupa di riconoscere il tipo di messaggio ricevuto e di invocare le apposite procedure per la sua gestione.
Volendo ad esempio implementare un sistema sicuro di trasmissione in cui ogni comunicazione è cifrata con 3DES e richiede l’ autenticazione presso un server centrale, si deve semplicemente creare un server ad hoc. Per ogni richiesta ricevuta tale server contatterà il server centrale di autenticazione e creerà due stream in grado di leggere/scrivere flussi cifrati con 3DES da passare al Client
Modulo 8: Gestione Messaggio Lookup
Un messaggio di lookup è un messaggio contenente una lista di chiavi SHA1 di cui verificare la presenza nella cache del nodo ricevente. Tale messaggio contiene anche un flag che indica se fare o meno il lock delle chiavi trovate. Il messaggio di risposta a un messaggio di Lookup contiene la lista delle chiavi trovate in cache.
Modulo 9: Gestione Messaggio Richiesta Blocchi
Un messaggio di Richiesta Blocchi è un messaggio contenente una lista di chiavi SHA1 di cui si richiede la trasmissione dei blocchi corrispondenti nel messaggio di risposta.
Tutti i blocchi richiesti vengono recuperati dalla cache del destinatario del messaggio che può essere un qualsiasi nodo della griglia (Committente o uno dei Rappresentanti).
Il sistema prevede che il comportamento della funzione di recupero dei blocchi dalla cache sia bloccante con Timeout, ovvero che il richiedente rimane in attesa di ricevere un blocco fino allo scadere del Timeout.
I blocchi richiesti nel messaggio vengono prelevati dalla cache e serializzati nel canale di scrittura per l’invio al richiedente nel messaggio di risposta. Per sfruttare al massimo il link di comunicazione, come indicato nel modulo 6, i blocchi richiesti vengono inviati sul canale di comunicazione man mano che si rendono disponibili e non necessariamente nell’ordine della richiesta.
Modulo 10: Gestione Messaggio New Job
Un messaggio di New Job è un messaggio che viene inviato dal Committente e che contiene tutte le informazioni per la ricostruzione dei file che il nodo destinatario deve ricevere col deployment.
Queste informazioni sono organizzate in quattro sezioni con:
– le informazioni necessarie per la ricostruzione dei file: nome,
percorso nel filesystem, checksum, lista delle chiavi SHA1 dei blocchi che lo compongono e flag di compressione
– la lista di associazioni <chiave, id nodo> che indicano i nodi da
cui recuperare i blocchi non inviati direttamente dal Committente
– i blocchi inviati direttamente dal Committente
I blocchi inviati direttamente dal Committente occupano di solito la parte più consistente del messaggio di New Job e vengono serializzati nella parte finale del messaggio. Questo per consentire di avviare la lettura dei blocchi da recuperare dagli altri nodi parallelamente alla lettura dei blocchi inviati dal Committente. Questo parallelismo consente di migliorare il throughput medio della rete in quanto si sfruttano contemporaneamente il massimo numero di link diversi possibili (per approfondimenti consultare il modulo 6).
Modulo 11: Ricostruzione dei File
Questo modulo si occupa di ricostruire i file a partire dalle informazioni contenute nel messaggio di New Job precedentemente ricevuto e dai blocchi recuperati.
Al completamento della lettura dei blocchi ricevuti dal Committente e dagli altri nodi si verifica la presenza di tutti i blocchi necessari alla ricostruzione dei file; nel caso in cui ne manchino (a causa di errori di comunicazioni e/o di fault di cache) si procede con la richiesta degli stessi direttamente al Committente.
Successivamente la ricostruzione dei file viene affidata ad un pool di Thread dove ogni thread si occupa della ricostruzione di un singolo file. Come per la fase creazione dei blocchi effettuata nel modulo 2 del Committente, anche in questo caso il numero massimo di thread che lavorano in parallelo è fissato in base alle capacità di calcolo della
Nella fase di ricostruzione ogni thread recupera dalla cache i blocchi relativi al file da ricostruire che gli è stato assegnato, eventualmente decomprime tali blocchi, ne verifica l’integrità tramite il checksum e progressivamente li salva su disco, senza l’ausilio di file temporanei.