Deployment dei blocchi.

In questo modulo il Committente si occupa dell’invio in parallelo dei messaggi di deployment ai vari nodi destinatari. Questi messaggi contengono le informazioni necessarie per la ricostruzione dei file (nome, percorso nel filesystem, checksum, lista delle chiavi SHA1 dei blocchi) e l’eventuale lista dei nodi da cui recuperare i blocchi non inviati direttamente dal Committente.

I blocchi vengono ricevuti o direttamente dal Committente oppure da altri nodi; questi ultimi possono averli in cache oppure devono attendere di riceverli dal Committente.

L’obiettivo primario del deployment è quello di sfruttare al massimo i link coinvolti nella distribuzione in modo da avere in ogni istante il massimo throughput di rete: per tale motivo si vuol fare in modo di iniziare il prima possibile le comunicazioni sui link che non coinvolgono il Committente.

Dagli studi fatti (paragrafo 2.4) si è visto che per ottenere un buon throughput è bene avere più comunicazioni in parallelo sullo stesso link. Il numero di queste comunicazioni dipende molto dalla banda disponibile, dal tipo di protocollo utilizzato e dalla tipologia di rete: in generale un valore di 8 comunicazioni in parallelo è un buon compromesso per sfruttare al meglio tutta la capacità del link nel caso di comunicazioni fortemente I/O bound (senza quindi grandi delay dovuti alla CPU).

In generale con la nostra libreria le comunicazioni avvengono contemporaneamente su più link e le stesse non sono del tutto I/O bound in quanto i nodi devono effettuare anche altre elaborazioni che richiedono l’intervento di CPU e disco.

Nel nostro modello il link mediamente più sollecitato risulta essere quello del Committente che si occupa di inviare almeno i blocchi che non sono già presenti in rete (nelle Cache dei destinatari).

Alla luce di queste considerazioni il parallelismo nell’invio dei messaggi di inizio deployment (da parte del Committente) viene limitato ad un massimo dipendente dalla quantità di dati da inviare, dal numero di nodi e dalla velocità della rete: in generale meno sono i dati da inviare per nodo e maggiore è la velocità della rete più si consente un parallelismo spinto per tentare di aumentare lo speed- up. Per i dettagli vedere il metodo creaeInviaMessaggiNewJob della classe PoliticaInvio nel capitolo 5 dell’implementazione.

Al contrario il limite massimo di comunicazioni in parallelo sui rappresentanti è molto più alto in quanto i link vengono sfruttati con minore intensità visto che i blocchi vengono inviati agli altri nodi che ne fanno richiesta man mano che vengono ricevuti.

Di base si consentono almeno 20 comunicazioni in parallelo, che da test empirici hanno mostrato produrre buone performance.

Per ottenere il massimo throughput è importante far iniziare prima le trasmissioni dei blocchi con più alta molteplicità (termine che indica il numero di destinatari che devono ricevere un determinato blocco). In tal modo una volta che il generico destinatario ha ricevuto il blocco b dal Committente, può iniziare prima la ritrasmissione dello stesso agli altri nodi che devono ricevere b da lui. Se invece le comunicazioni fossero iniziate tutte in parallelo si sarebbe dovuta attendere una latenza maggiore prima di poter effettuare la ritrasmissione dei blocchi ricevuti. In tal modo si sarebbe ottenuto un throughput medio inferiore in quanto sarebbero rimasti inutilizzati per maggior tempo i link di comunicazione che non coinvolgono il Committente.

Il Committente calcola la priorità di ogni messaggio di inizio deployment, che definiamo messaggi di New Job, e fa iniziare le trasmissioni in base a tale priorità. Questa è calcolata semplicemente come somma del numero di blocchi da inviare a molteplicità maggiore

di uno. A rafforzare questo meccanismo di priorità, all’interno del generico messaggio di New Job inviato al nodo J, i blocchi inviati dal Committente vengono ordinati per molteplicità decrescente. Questo consente al nodo J di far partire prima le trasmissioni dei blocchi che sfruttano un maggior numero di link (la molteplicità di un blocco è esattamente pari al numero di link che verranno coinvolti nella sua trasmissione).

Nel messaggio di NewJob i blocchi inviati dal Committente sono generalmente la parte preponderante di informazioni e vengono inseriti per ultimi nel messaggio stesso. Questo per far sì che i vari Rappresentanti possano avviare in parallelo in modo asincrono le richieste di download dei blocchi mancanti ad altri nodi mentre leggono i blocchi inviati dal Committente nel pacchetto di NewJob. Questa strategia consente di inoltrare immediatamente i blocchi ricevuti senza alcun delay e sul massimo numero di link diversi.

I blocchi devono essere ricevuti dal Committente o da altri nodi che li hanno in cache prima di poter essere ritrasmessi ai nodi che ne fanno richiesta; pertanto vi sono spesso molte richieste concorrenti in attesa in merito a blocchi che verranno ricevuti in tempi diversi. Altra ottimizzazione consiste nell’effettuare l’invio dei blocchi richiesti in ordine di arrivo e non in ordine di richiesta; ciò avviene tenendo il canale di comunicazione aperto e accodando i blocchi man mano che vengono ricevuti dai nodi fornitori.

Ulteriore ottimizzazione è data dalla verifica di presenza di blocchi in cache prima di effettuare la richiesta ad un altro nodo; può infatti accadere che, tra il calcolo dello schema di distribuzione e la reale esecuzione del deployment, alcuni blocchi si siano resi disponibili. Oppure può anche accadere che la stima della politica di invio da utilizzare abbia preferito la politica 1 anziché la 2 o la 3, ma che alcuni blocchi fossero però già presenti in cache.