Rt Module

Il Rt Module `e il componente che si preoccupa di ricevere ed elaborare le richieste di servizio ricevute da un consumatore, garantendo il rispetto della QoS che `e stata contrattata. Realizza dunque i requisiti 1.1 ed 1.2.

6.2. PROGETTO 79 Per poter ricevere ed elaborare le richieste di servizio, il Rt Module sfrut- ta le funzionalit`a del web server, di cui pu`o essere considerato una estensione. Per poter invece garantire la QoS contrattata dal consumatore, utilizza le funzionalit`a messe a disposizione dal livello di supporto alla gestione. I para- metri di QoS contrattati dal consumatore vengono resi disponibili dal livello superiore della nostra architettura (il livello di accordo).

Il componente, per quanto detto, pu`o essere suddiviso in due parti prin- cipali, descritte brevemente di seguito.

• WebServer Interface - Permette la ricezione e l’elaborazione delle ri- chieste di servizio, nonch´e la configurazione di alcune caratteristiche del componente. Tutto ci`o viene realizzato sfruttando le funzionalit`a del web server, con cui ci si interfaccia. Vengono inoltre utilizzati i dati provenienti dal livello di accordo, necessari per determinare quali richieste sono da servire con una certa QoS.

• Reservation Manager - Permette di gestire la QoS dei servizi da esegui- re con tali requisiti. Viene invocato nel momento in cui devono essere servite richieste con una certa QoS e si interfaccia verso il livello di supporto per poterne effettuare la gestione.

Tali sottocomponenti verrano di seguito analizzati in maniera approfon- dita.

WebServer Interface

Uno dei compiti di questo sottocomponente `e quello di permettere la con- figurazione del Rt Module. Per permettere la configurazione del modulo si utilizzeranno le seguenti direttive:

• RtModule

• RtUseAgreement • RtCpuBwReservation • RtSetHandler

Tali direttive, per il loro particolare significato, andrebbero utilizzate nell’ordine suggerito. Infatti, la prima direttiva permette di abilitare o disa- bilitare il modulo: prende dunque un parametro che pu`o assumere i valori On o Off. Se il modulo viene disabilitato con l’uso del valore Off allora le altre direttive non avranno alcuna validit`a.

Anche la seconda direttiva prende come parametro o un valore On o un valore Off, permettendo di specificare se il modulo viene utilizzato o meno in una architettura che fa uso di contrattazione della QoS. Questa direttiva `

80 CAPITOLO 6. ARCHITETTURA utilizzato anche al di fuori della nostra architettura. Nel nostro caso la direttiva sar`a sempre impostata ad On. Da notare che se viene abilitata la contrattazione basata su Agreement, le successive due direttive non avranno validit`a.

La terza e la quarta direttiva permettono di utilizzare il modulo anche in una architettura in cui non si fa uso di contrattazione della QoS. La terza direttiva prende infatti come parametro un valore che specifica la banda di CPU con cui si vuole eseguire un certo servizio. La quarta direttiva permette di indicare tale servizio tramite la specifica del tipo di gestore che eseguir`a un certo servizio. Ad esempio, se si vuole eseguire con una certa QoS un programma CGI, `e sufficiente specificare il valore cgi-script come parametro della direttiva. Il valore da specificare `e dunque quello con cui Apache identifica il gestore delle richieste di un certo tipo MIME. Si fa notare come l’utilizzo del modulo in architetture senza contrattazione non verr`a ulteriormente approfondito e si ribadisce che le ultime due direttive non hanno validit`a nell’architettura in esame.

Sebbene la possibilit`a di configurazione sia di assoluto rilievo, il compito pi`u importante di tale sottocomponente `e tuttavia quello di intercettare le richieste di servizio fatte al server web, per poter stabilire se queste devono essere servite con una particolare QoS. Le richieste da servire con garanzie di QoS sono quelle che provengono da soggetti consumatori per i quali esistono dei contratti validi. Al livello di servizio della nostra architet- tura, un contratto valido `e un contratto per cui esiste una terna (ClientId, CpuBw, RsvId) nella struttura dati condivisa con il livello di accordo. Per poter stabilire dunque se una richiesta deve essere servita con una particola- re QoS, `e sufficiente ottenere l’identificativo del consumatore (a partire dalla richiesta stessa) e verificare se esiste una entrata con lo stesso valore per il campo ClientId. Se la richiesta `e soggetta a garanzie relative alla qualit`a del servizio allora viene chiamato in causa il ReservationManager.

Una richiesta di servizio viene effettuata da un consumatore tramite il protocollo HTTP: la richiesta di un servizio si materializza dunque nell’in- vio di una o pi`u richieste HTTP. Il sottocomponente in esame non deve intercettare tutte le richieste HTTP di un consumatore per poter verificare la necessit`a di fornire garanzie di QoS a quel consumatore: `e sufficiente a tale scopo intercettare solo alcune ben determinate richieste HTTP. Que- sto perch´e il protocollo HTTP, che si appoggia al TCP come protocollo di trasporto, permette che pi`u richieste HTTP possano viaggiare su una stessa connessione TCP (in questo caso una connessione si dice di tipo Keep-Alive). Le richieste multiple che vengono effettuate su una stessa connessione ven- gono poi servite da uno stesso task all’interno della struttura concorrente del web server (si veda ad esempio il capitolo 4). Vi `e dunque la necessit`a di intercettare solamente la prima richiesta instradata su una nuova connes- sione: se si verifica che per essa si devono fornire garanzie di QoS allora si dovranno fornire le stesse garanzie a tutte le successive richieste HTTP di

6.2. PROGETTO 81 quella connessione, visto che provengono dallo stesso soggetto consumatore. Il processo di verifica della necessit`a di fornire QoS dipende dalla dispo- nibilit`a dell’identificativo del consumatore. Dato che questo `e disponibile subito dopo la creazione della connessione, il modulo Rt pu`o, in realt`a, in- serirsi nel flusso di esecuzione del server immediatamente prima che venga inviata la prima richiesta sulla connessione.

Le operazioni effettuate a quel punto per verificare se si deve fornire QoS a quel consumatore possono essere riassunte con il diagramma di flusso di figura 6.8. Notiamo che tali operazioni vengono fatte solamente una volta per ogni connessione, cio`e dopo che una connessione `e stata creata ma prima che venga ricevuta una richiesta. Se si verifica che la connessione proviene da un consumatore per il quale `e stata contrattata una certa QoS, allora tutte le richieste HTTP provenienti da quel consumatore saranno servite con quella QoS.

82 CAPITOLO 6. ARCHITETTURA Reservation Manager

Il Reservation Manager `e invocato nel momento in cui viene intercettata una richiesta di servizio per cui deve essere garantita una certa QoS. I dati che devono essere utilizzati dal Reservation Manager, affinch`e possa svolgere il suo compito di gestione, sono quelli relativi all’entrata (ClientId, CpuBw, RsvId) con cui si identifica un contratto valido. Infatti, il Reservation Ma- nager utilizza il livello di supporto per associare a ciascun consumatore una risorsa virtuale: in questo caso tale risorsa `e la CPU, per cui a ciascun con- sumatore sar`a associata una CPU virtuale, identificata da RsvId, con banda pari al valore specificato da CpuBw.

Concettualmente, dunque, il compito principale del Reservation Manager `

e quello di creare una risorsa virtuale ed associare a tale risorsa il task della struttura concorrente del server web che sta servendo la richiesta di servizio. Poich´e una risorsa virtuale viene generalmente distrutta quando non vi sono dei task ad essa associati, avremo che ciascuna risorsa virtuale ha il tempo di vita di una connessione: questo perch´e ogni qual volta viene instaurata una nuova connessione deve essere accertata l’identit`a del consumatore.

Il compito del Reservation Manager non si esaurisce nella creazione delle risorse virtuali, poich´e nell’eseguire le richieste di servizio per un consuma- tore, possono presentarsi diversi casi a cui dover far fronte. In particolare ne sono stati identificati tre, di cui il primo `e il caso cui si `e gi`a fatto riferi- mento, ovvero l’instaurazione della prima connessione tra client e server: in questo caso il Reservation Manager deve limitarsi a creare la risorsa virtuale e associarvi il task servente.

Il secondo caso `e relativo al caso in cui pi`u connessioni in contemporanea vengano instaurate con uno stesso soggetto consumatore: nel caso di con- nessioni successive alla prima, dunque, quello che deve fare il Reservation Manager `e associare il task servente alla risorsa virtuale gi`a creata e che contemporaneamente `e in uso dagli altri serventi.

Il terzo caso prevede che l’unica connessione tra il consumatore ed il fornitore si andata in timeout mentre si `e ancora in obblighi di garanzia del servizio. In questo caso, la risorsa virtuale, poich´e ha il tempo di vita di una connessione, non esiste pi`u e dunque deve essere nuovamente creata.

E’ necessario dunque che il Reservation Manager tenga traccia, in ogni istante, della risorsa virtuale a cui sono attualmente associati i servizi re- lativi ad un particolare consumatore. Per poter far questo si utilizzer`a il campo RsvId, per poter associare ad ogni consumatore una risorsa virtuale identificata univocamente all’interno del sistema. Al momento in cui viene servita la prima richiesta in assoluto di un consumatore avremo RsvId=−1, ad indicare che nessuna reservation `e stata finora creata per quel consuma- tore. In questo caso diremo che non esiste una “nota della reservation”. Viceversa, quando il valore di RsvId!=−1 si dir`a che esiste una “nota della reservation”.

6.2. PROGETTO 83 In particolare, le operazioni che devono essere effettuate dal Reservation Manager, successivamente alla sua invocazione, vengono riassunte nel dia- gramma di flusso di figura 6.9. Riguardo a tale diagramma `e interessante notare che l’operazione di verifica dell’esistenza della reservation viene ef- fettuata utilizzando un ClientId che `e gi`a stato verificato (si ricorda che il RsvId `e presente all’interno di un contratto valido). Si fa notare inoltre come possa esistere una nota della reservation in cui il RsvId non sia vali- do: ci`o non costituisce un errore ma semplicemente corrisponde al caso, cui si `e fatto riferimento in precedenza, in cui l’ultima reservation che `e stata utilizzata per servire quel client non esiste pi`u nel sistema.

84 CAPITOLO 6. ARCHITETTURA