Progetto Reti
annuncio pubblicitario
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
