Questa classe è una sottoclasse della classe astratta MsgRequest ed è utilizzata per inviare comandi agli altri nodi per poi catturarne l’output e restituirlo nel corrispondente MsgResponse.
MsgRequest_Command ha due costruttori: uno per creare un messaggio da una stringa ed uno per creare il messaggio da un DataInputStream. Implementa inoltre il metodo astratto
writeToStream usato per serializzare il messaggio su un DataOutputStream.
5.2.17 - Classe MsgRequest_NewJob
Questa classe è una sottoclasse della classe astratta MsgRequest ed è utilizzata dal Committente per avviare il deployment con i Rappresentanti. Un messaggio di NewJob ha una vasta serie di informazioni:
Le informazioni (oggetto di tipo CommInfo) serializzate per consentire al Rappresentante di contattare il Committente. Tali informazioni sono indispensabili in quanto non si conoscono a priori i dati per contattarlo essendo il Committente un nodo non permanente della Griglia.
Per ogni file oggetto del deployment la serializzazione del corrispondente oggetto di tipo FileDaInviare con indicati: il nome del file, il percorso, il checksum di integrità, la lista ordinata di chiavi SHA1 dei blocchi che lo compongono e il flag indicante la compressione o meno di tali blocchi.
Una serie di strutture serializzate di tipo BlocchiDaRicevere. Tali strutture contengono un id nodo e una lista di chiavi SHA1 e sono utilizzate per indicare al rappresentante quali blocchi richiedere agli altri nodi della griglia. Tali strutture sono calcolate dal Committente come output dell’algoritmo di ottimizzazione e allocazione dei blocchi. Tale lista può essere eventualmente vuota nel caso in cui il Committente si occupi di inviare direttamente tutti i blocchi.
La lista dei blocchi che il Committente invia direttamente al Rappresentante. Tale lista può eventualmente essere vuota nel caso in cui i blocchi vengano recuperati tutti in modalità distribuita dagli altri nodi. Questa parte è l’ultima sezione del messaggio di NewJob ed è la più voluminosa in quanto non
Durante la lettura da stream del messaggio di NewJob si avviano le richieste dei blocchi mancanti ai nodi indicati nel messaggio in parallelo alla lettura dei blocchi serializzati dal Committente. Questo per cercare di sfruttare il maggior numero possibile di link di comunicazione distinti in parallelo ed aumentare così il throughput di rete del Rappresentante rispetto ad un utilizzo sequenziale. Si fa notare come le richieste di blocchi vengano effettuate immediatamente alla ricezione del messaggio di NewJob in un momento in cui tali blocchi potrebbero essere ancora non disponibili sul nodo destinatario. L’algoritmo di allocazione garantisce che dei blocchi vengano richiesti ad un nodo se e solo se questo li dovrà ricevere o li ha in cache (in tal caso sono stati messi in stato di Lock dalla precedente lookup). Pertanto escludendo errori di comunicazione non è possibile che vi siano attese indefinite di blocchi; per gestire eventuali situazioni di errore tutte le richieste hanno un timeout per fare in modo che i blocchi non recuperati possano essere poi chiesti direttamente al Committente.
Le richieste fatte per blocchi non ancora disponibili rimangono in standby fino alla disponibilità degli stessi; tali richieste vengono infatti gestite in modalità non bloccante da appositi thread. Le richieste pendenti vengono evase man mano che i blocchi si rendono disponibili, eventualmente non nell’ordine della richiesta (che è ininfluente).
Dopo la lettura da stream di un messaggio di NewJob restano in esecuzione i thread per la lettura dei blocchi da ricevere dagli altri nodi. Sarà cura del metodo elaboraMsg del Rappresentante attenderne il completamento prima di procedere alla ricostruzione del file (a tal proposito vedere la descrizione della classe Rappresentante [par. 5.2.3]).
Come per gli altri messaggi di tipo MsgRequest anche la classe MsgRequest_NewJob ha due costruttori di cui uno per deserializzare il messaggio da uno stream ed inoltre l’implementazione del metodo
astratto writeToStream. I blocchi letti dallo stream vengono inseriti direttamente in cache grazie al metodo read della classe Cache; allo stesso modo i blocchi serializzati su stream dalla cache vi sono direttamente scritti dalla stessa tramite il metodo write.
5.2.18 - Classe MsgRequest_QueryFingerprints
Questa classe è una sottoclasse della classe astratta MsgRequest ed è utilizzata per richiedere la verifica di presenza di blocchi in cache ed eventualmente richiederne anche il lock. Le strutture della classe sono:
lockBlocks (di tipo boolean): indica se effettuare o meno il lock dei blocchi richiesti e trovati in cache. Nell’attuale implementazione il lock dei blocchi viene richiesto dal Committente nella fase di lookup precedente al deployment per garantire la presenza dei blocchi richiesti nella successiva fase di scambio distribuito degli stessi.
listaChiavi (di tipo String Array): lista contenente i fingerprint (chiavi SHA1) dei blocchi di cui si vuole verificare la presenza in cache.
MsgRequest_QueryFingerprints ha due costruttori: uno per creare un messaggio da una lista di chiavi e da un booleano ed uno per creare il messaggio da una DataInputStream.
L’unico metodo della classe è writeToStream che serializza su disco il messaggio (quindi msgType, il booleano lockBlocks, il numero di chiavi e le chiavi in questione).
5.2.19 - Classe MsgRequest_UpdateTopolgiaRete
Questa classe è una sottoclasse della classe astratta MsgRequest ed è utilizzata per sincronizzare il file XML della topologia di rete tra il nodo richiedente e tutti gli altri nodi della griglia.
per ricrearlo a partire dalla serializzazione di tale file su stream (di tipo DataInputStream).
La classe implementa inoltre il metodo astratto writeToStream usato per serializzare il messaggio su un DataOutputStream.