-
Introducción
Queremos trabajar un poco con sockets TCP y con RMI, ambos sobre la plataforma
de ejecución Java. Como en la práctica anterior, la excusa es construir una aplicación distribuida que ponemos a prueba
mediante una especie de proxy WEB simplificado. La herramienta de
programación es Java, aquí tenemos un ejemplo
de intermediario WEB en Perl que puede venir muy bien para que resolvais la
práctica: funciona para HTTPv1.0. (Aunque ahora hay que hacerlo en Java!)
Será de gran ayuda haber leído y entendido la práctica que se planteó
en la convocatoria ordinaria de la asignatura.
Pero el sistema que se construirá será un poco más complicado. En la Figura
1 se muestra un esquema simplificado con las tareas involucradas:
Figura 1
El intermediario proxy soporta una caché local, y debe comportarse de modo
transparente al cliente y al servidor WEB. El servidor proxy podrá presentar
diversos comportamientos en función de como lo configuremos. Esta
configuración se efectuará en tiempo de ejecución, y se podrá controlar
desde una interfaz de usuario que será un nuevo proceso en discordia. Este
proceso que actúa como un interfaz de control del proxy podrá funcionar bien
en modo texto, o para los más atrevidos como un applet.
-
Discusión de las tareas involucradas en el problema
En primer lugar, un proxy sencillo deberá poder entrar en contacto con el
servidor WEB en nombre del cliente WEB. Esto implica tres operaciones:
a) configurar el cliente web para que utilice el proxy que hemos puesto en
marcha, sobre una máquina concreta y con un número de puerto concreto. Este
cliente podrá ser el Netscape, el Opera, el Explorer de Microsoft, etc., o
incluso más interesante, "wget" de GNU.
b) el proxy deberá decodificar la cabecera de la petición del cliente web
para poder establecer la comunicación por socket TCP/IP con el servidor.
Recuerde que en la versión 1.0 por cada recurso al que se accede se establece
y se cierra una conexión por socket TCP.
c) a partir de este momento el proxy debe comportarse de modo transparente, si
es que queremos hacer algo sencillo. Como es lógico, puentearemos aquellas
peticiones que queramos tratar localmente.
ciclo básico de operación
En el ciclo básico de operación, el proxy se encarga de recibir la
conexión con el cliente web, tal y como se muestra en la Figura
2. Con la información del método (véase el RFC1945
en IETF) podemos saber si el método es GET
(para descargar recursos). El URL contiene la dirección Internet del
servidor, y posiblemente el número de puerto. Con esta información se
establecerá la conexión TCP correspondiente con el servidor web.
Figura 2. 
A continuación debemos trasvasar desde el proxy al servidor web toda
la información que envía el cliente. Éste, a su vez, responderá de la manera que crea conveniente, y debemos
transmitir ésta respuesta (tal cual) al cliente, siguiendo el camino inverso, que se
describe en la Figura 2. El servidor será multihenebrado. Para facilitar la
tarea se proporciona un sistema cliente-servidor en Java (ClienteTCP.java,
Conexion.java y ServidorTCP.java),
que como ya podríais imaginar son los que aparecen en el Coulouris
(Tercera edición).
ciclo de operación con caché
Bajo ciertas circunstancias, el proxy almacenará la información que le
envía el servidor web, para poder servir al cliente web sin necesidad de
volver a repetir la petición. En este caso, el caché se compondrá de
archivos que contienen la respuesta que envía el servidor, siendo
responsabilidad del diseñador de la aplicación el formato de los archivos,
su disposición y el vínculo que hay que establecer entre el URL y el
recurso.
control del ciclo de operación
En resumen, el programa proxy que hace como intermediario tiene tres formas
de funcionamiento:
|
|
El proxy almacena los
recursos nuevos recibidos |
|
|
Si |
No |
| El cliente recibe los datos
cacheados previamente |
Si |
1 |
2 |
|
No |
- |
3 |
- 1) el proxy almacena los nuevos recursos recibidos, y el cliente recibirá
los datos del caché cuando ya estén presentes en este. Está funcionando
como un proxy completo.
- 2) el proxy no almacena los nuevos recursos recibidos pero el cliente
recibe los datos cacheados que ya estén presentes en el caché. Está
funcionando como un proxy de aquellos datos que fueron cacheados en un
instante anterior.
- 3) el proxy no almacena los datos nuevos recibidos y funciona de modo
completamente transparente.
otros modos de operación
Se pueden añadir más funciones al proxy, como por ejemplo, que substituya
o elimine el acceso a ciertos recursos, para acelerar la comunicación, que
emplee otros clientes para descargar árboles de recursos web, etc.
Se deja a la imaginación del alumno implementar estos otros modos de
operación del caché.
-
Control del modo de operación del caché
El control del modo de operación del caché se efectuará mediante una
aplicación Java que interactuará vía RMI con el proxy (como se indica en la
Figura 1). Esta aplicación es lo que llamamos la Interfaz
de control. Esta interfaz deberá controlar de modo adecuado el ciclo de
operación del caché en que nos encontramos para la siguiente petición web.
Esta aplicación será interactiva, de modo que recibe en tiempo de
ejecución los parámetros de funcionamiento. La implementación de la
interfaz no es relevante, pudiendo ser de tipo textual, o de tipo gráfico
mediante AWT o Swing. Esta aplicación se ejecutará en alguna máquina,
suponiendo de partida que no será aquella donde se ejecutará el proxy que
hemos programado.
-
Cuestiones a tener en cuenta
Como es normal, cada vez que se trata de resolver una tarea compleja, sobre
todo cuando estamos problemas nuevos y complejos, debemos acotar la
funcionalidad del sistema. Mi punto de vista particular, es empezar con un
sistema sencillo que tenga la funcionalidad básica, e ir incrementando sus
funciones. En esta lista no están enumerados todos los problema. Según vayan
apareciendo más, trataré de incluirlos aquí.
mantenimiento de la información en el caché
Las respuestas del servidor deberán soportarse mediante archivos. UNIX. Se
generarán nombres de archivos
únicos, para que no haya colisión de nombres. La asociación deberá
plasmarse usualmente en un array asociativo cuya clave será el nombre del recurso (URL),
y el contenido asociado a la clave, el nombre del archivo.
La siguiente pregunta es, ¿qué pasa cuando el proxy muere? ¿Se mantiene
el índice, en un archivo estático, junto al contenido de las respuestas del
servidor? En este caso, y a diferencia de la aplicación ya hecha a lo largo
del curso, deberá ser estático. Esto no quiere decir que cada vez que
localicemos un recurso haya que mirar un archivo, aunque: cada vez que
arranquemos el proxy debemos comprobar si existe un caché previo.
La siguiente pregunta es, ¿vamos a llenar el disco de archivos? Lo ideal
sería que la interfaz del proxy nos notifique interactivamente cuánta
memoria llevamos consumida por el caché, para poder habilitarla o
inhabilitarla a gusto del consumidor.
Finalmente hay que decir, que este enunciado es más simple que en el caso
de la práctica para junio, pero no quiere decir que no lleve el mismo
trabajo. En cierta medida es más sencillo recurrir a la programación en Java
para resolver algunos aspectos, aun así hay que resolver correctamente el
problema de la conexión interfaz-proxy.
Este enunciado corresponde a una práctica de Sistemas Distribuidos
de la Ingeniería Técnica en Informática de Gestión y Sistemas de la
Universidad de Valladolid, del curso 2001-2002. Y el derecho de copia y
explotación (c) me pertenece a mí (el profesor de la asignatura) y a mis
alumnos :-)
El profesor de la asignatura no se hace responsable de la utilización
indebida que pueda hacerse de las aplicaciones construidas siguiendo la
especificación de esta práctica.