Progetto Reti

Mittente: Pierpaolo Angelini
"Pierpaolo Angelini" <[email protected]>
Ingegneria Elettronica, 20 06 35 0 90
Gentile professore, in base alle indicazioni da lei fornitemi, ho pensato di modificare le specifiche del progetto.
L'idea iniziale era di realizzare un server replicato che in base ad alcune indicazioni fornite da un cliente tramite una
pagina web fosse in grado di consigliare una possibile configurazione per l'acquisto di un pc. In realtà il servizio era
soprattutto un pretesto per provare alcuni meccanismi della programmazione di rete in Java. Analizzando il problema,
mi sono spostato verso un modello di replicazione più generale che vorrei sottoporle al vaglio.
Specifiche del progetto
Le specifiche sono brevi, infatti l’idea è semplicemente quella di realizzare un gestore di servizi replicati con le seguenti
caratteristiche:
- deve poter lavorare con i web server esistenti, purché compatibili con le servlet, e quindi con Java
- utilizza i servizi cgi e le servlet di ogni genere, già esistenti, e quindi non concepite specificamente per
lavorare in replicazione.
- deve tener conto del carico dei server impiegati, e quindi essere in grado di fare del load sharing.
Linee di sviluppo
Ecco in linea di massima le linee di sviluppo del nuovo progetto:
- L'interfaccia cliente è costituita da una pagina web, nella quale egli invia, attraverso un form, la query verso
uno specifico server.
- Su questo server, un gestore dei servizi, provvede a ricevere la query e a stabilire quale tra le copie dei server
disponibili sia la più scarica e quindi la più adatta a fornire il servizio.
- Il gestore è costituito da una servlet, che risponde al cliente, inviandogli una pagina web.
- La pagina web, contiene una copia nascosta del form iniziale, con gli stessi dati che il cliente aveva inviato al
gestore, ma con un indirizzo di destinazione che questa volta corrisponde esattamente all'indirizzo del server su
cui è attivo il servizio. Il submit della pagina questa volta avviene automaticamente, e il cliente, in maniera
trasparente, vede arrivare direttamente la pagina che corrisponde all'esecuzione del servizio eseguita
dalla meno impegnata delle copie replicate.
Problemi riscontrati
Alcuni problemi emersi approfondendo l’analisi del progetto sono i seguenti:
-
Avendo introdotto un gestore che media le richieste tra il cliente e i servizi, è necessario modificare le pagine
HTML, in maniera tale che il submit, non avvenga più direttamente verso il servizio, ma verso il gestore. Non
basta modificare l'URL del destinatario, occorre anche introdurre all'interno dell'oggetto FORM, un oggetto
INPUT che contenga il nome del vecchio servizio che è stato sovrascritto dall'indirizzo del gestore.
Queste modifiche, comunque, sono rapide, possono essere automatizzate, e avvengono sulla pagina HTML,
quindi sul web server che la pubblica.
-
È necessario che il gestore sappia trattare sia il metodo GET che il metodo POST, utilizzati da servlet e cgi.
-
La seconda richiesta del client, quella che si rivolge direttamente al servizio deve essere automatica. L'utente
infatti ha già manifestato la volontà di voler ricevere il servizio. L'automazione può avvenire attraverso uno
specifico meta in HTML, oppure con una open() in Javascript, o in Java tramite un applet.
-
Il problema più impegnativo è quello del load sharing. Il gestore, per poter decidere quale tra i servizi sia il più
scarico, deve tenere traccia dell'inizio di ciascun servizio su ciascun server, e della sua terminazione. Mentre è
facile, per il gestore, registrare l’inizio del servizio, è più difficile accorgersi che il servizio è finito, perché una
volta che il gestore ha passato il link al client, il client si rivolge direttamente, e automaticamente, al servizio, e
il gestore viene estromesso. Se i servizi fossero stati concepiti per lavorare con la replicazione, potrebbe essere
previsto l'invio di un messaggio dal servizio al gestore. Ma se vogliamo sfruttare i servizi già esistenti, questo
non è possibile.
Un modo per risolvere questo problema potrebbe essere il seguente: la pagina restituita dal gestore al client,
può essere un frame che carica altre pagine. All'interno del frame, utilizzando Javascript è possibile non solo
effettuare il submit verso il servizio, ma anche, in un secondo tempo, inviare un secondo form verso il gestore,
che lo avverta della terminazione di un servizio. Infatti, se assumiamo che il servizio termini con la restituzione
di una pagina HTML, al verificarsi dell'evento "onLoad" di tale pagina, ovvero dopo che la pagina è arrivata,
Javascript può eseguire una funzione che invia il messaggio al gestore. Naturalmente le stesse cose sono
realizzabili anche con un applet.
-
Dopo aver risolto il problema di avere una traccia esatta di tutti i servizi attivi su tutte le copie replicate, è
sufficiente che il gestore attribuisca un peso ad ogni servizio. Quindi alla richiesta di un servizio, non gli resta
che scegliere il server che risulta più scarico e aggiornare il suo valore all'interno di un vettore che contiene il
carico di ciascun server. In maniera analoga, al termine del servizio il valore del carico del server
corrispondente, viene ridotto.
-
Un rischio che si verifica, è che il cliente, dopo aver fatto la richiesta cada. Il livello di occupazione del server
che avrebbe dovuto eseguire il servizio, non viene più ripristinato perché il gestore non riceve più dal cliente la
comunicazione del servizio terminato. Una soluzione è quella di porre un time out in corrispondenza di ciascun
servizio, al termine del quale si possa ritenere concluso il servizio.
-
L’assunzione che un servizio termini con lo scaricamento di una pagina, non è sempre vera nella realtà. In un
servizio interattivo, il servizio restituisce una pagina che contiene altri form, e quindi altre richieste verso il
server. Il cliente, dopo aver scaricato la prima pagina, invia un form al gestore avvertendolo che il servizio è
terminato, mentre la sessione di interazione è appena iniziata. Una possibile soluzione potrebbe essere quella di
considerare terminato un servizio soltanto quando l’utente esce dalla pagina-frame che ha gestito il servizio.
Attraverso la gestione di questo evento “unLoad” è possibile comunicare al gestore che il servizio è terminato.
-
Esiste la possibilità che qualcuno dei server possa essere down. Il gestore potrebbe risolvere questo problema
interrogando periodicamente i servizi.
I limiti del progetto
Alcuni limiti intrinseci nell’impostazione del progetto sono i seguenti:
-
-
Il sistema non prevede che i servizi abbiano stato sui server. In questo caso il gestore dovrebbe garantire la
consistenza delle risorse e l'unica soluzione possibile, compatibile con la premessa di voler riutilizzare i servizi
esistenti, sarebbe quella di consentire l'esecuzione di un servizio alla volta, per ogni tipo di servizio. Ma a
questo punto tutti i vantaggi della replicazione verrebbero meno. Viceversa non c’è nessuna controindicazione
nell'utilizzo dello stato sui client, cioè dei cookie o del Session Tracking nelle servlet.
Un cliente che vuole accedere al servizio direttamente, potrebbe farlo, senza che il gestore possa accorgersi del
servizio in corso e senza che possa aggiornare il valore di occupazione del server.
Queste sono, in linea di massima, le nuove caratteristiche del progetto che intenderei sviluppare. In attesa di suoi
ragguagli, cordiali saluti,
Pierpaolo Angelini