Centro Nacional de Investigación y Desarrollo ... Xochitl Landa... · Debido a la importancia de...

S.E.P. S.E.I.T. D.G.I.T.

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

Mecanismos de Configuración Dinámica para Grupos de Proxy - Cachés

Cooperativas en la Web

TESIS

Que para Obtener el Grado de:

MAESTRO EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN

Presenta:

Xochitl Landa Miguez

Director de Tesis:

Dr. Víctor Jesús Sosa Sosa

Codirector de Tesis: M.C. Juan Gabriel González Serna

Cuernavaca, Morelos Diciembre del 2004

S.E.P. S.E.I.T. D.G.I.T.

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

MECANISMOS DE CONFIGURACIÓN DINÁMICA PARA GRUPOS DE PROXY – CACHÉS

COOPERATIVAS EN LA WEB

TESIS

Que para Obtener el Grado de:

MAESTRO EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN

Presenta:

Xochitl Landa Miguez

Director de Tesis:

Dr. Víctor Jesús Sosa Sosa

Codirector de Tesis: M.C. Juan Gabriel González Serna

Cuernavaca, Morelos Diciembre del 2004

Dedicatorias

A ti Dios, gracias por todo, sin tí no soy nada.

A mis queridos padres, María de la Luz Miguez García y Carlos René Landa Campos

Por darme siempre toda su confianza, amor y respeto, gracias por siempre estar cuando más los he necesitado, apoyarme en todas mis decisiones y creer en mí. Ustedes son la luz

de mi camino. Que Dios los bendiga, los amo.

A mi hermana Angélica

Por darme todo tu cariño, por aconsejarme y escucharme en todo momento. Lucha por tus niñas y sal adelante. Te quiero mucho.

A mis preciosas sobrinas Miroslava y Samantha.

Por enseñarme tantas cosas, por darme tantas lecciones y compartir tantas sonrisas, las quiero mis niñas.

Agradecimientos

Al COSNET y a la SEP, por brindarme su apoyo económico como becaria, ya que sin su ayuda no hubiera sido posible la terminación de esta tesis de Maestría.

Al Centro Nacional de Investigación y Desarrollo Tecnológico CENIDET, y a todo el personal que labora en esta institución, por permitirme por un tiempo representar y

formar parte de este centro de investigación.

A mi director de tesis, Dr. Víctor Jesús Sosa Sosa y mi codirector de tesis, M.C. Juan Gabriel González Serna, por brindarme toda su experiencia y conocimientos para

poder llevar a cabo la culminación de esta tesis.

Al comité revisor Dr. Joaquín Pérez Ortega, M.C. José Antonio Zarate Marceleño, y al M.C. Guillermo Cahue Díaz, por su valiosa disposición en la revisión de este trabajo

de tesis, y por sus comentarios y sugerencias que contribuyeron a mejorarlo.

Al maestro Luis Viades, por su valiosa ayuda en la revisión de mis publicaciones y por estar siempre dispuesto a dar consejos y sugerencias de forma desinteresada. Sin su

ayuda no hubiera sido posible publicar lo que se publicó.

A mi amigo Manuel Valdés, por tu apoyo incondicional que en todo momento me diste, nunca olvidaré nuestras pláticas, reflexiones y hasta nuestros enojos, gracias por

ponerme los pies sobre la tierra y sobre todo gracias por ser mi amigo.

Alicia Angélica y Ariadna Judith, aunque fue poco el tiempo que nos tratamos les agradezco por esos pequeños momentos que tuvimos tanto en el viaje como en la famosa

casa de las chavas, me la pasé muy bien.

Francisco, por procurarme tanto, nunca olvidaré esas charlas que tuvimos, te agradezco todo lo que hiciste por mí.

Fredy, por ser buen compañero, por brindarme tu amistad y apoyarme en mi tesis. Cuídate mucho.

Isaac Moisés, por compartir conmigo tus experiencias y dejarme compartir las mías. Nunca olvidaré esas pláticas que tuvimos, ni las reuniones en tu casa, de todo corazón te deseo lo

mejor.

Isaías, por los momentos tan agradables que nos hiciste pasar, espero que todo se solucione y seas feliz.

Isidro, por compartir unos cuantos momentos conmigo, esas pequeñitas pláticas que tuvimos pero sustanciales, y por hacernos las reuniones agradables.

Jorge O. Ceyca, por escucharme, por apoyarme y dedicarme tu tiempo, gracias por todos los ánimos que me dabas para seguir adelante.

Jorge Ochoa, por haberme compartido tu amistad. Disfruté mucho los trabajos que realizamos juntos.

José Guillermo, por los pequeñititos momentos que llegamos a compartir.

Luis Esteban, por esas pequeñas charlas que tuvimos y por apoyarme en los momentos que lo necesitaba.

Mariana, por escucharme, nunca olvidaré esas reuniones después de los partidos, cuídate portera estrella.

Pablo Rodrigo, por brindarme tu amistad y compartir algunas pláticas conmigo, cuídate mucho y ya no te aísles tanto.

Roberto Carlos, por los momentos que pasamos, esas pláticas que tuvimos y esos momentos juguetones que hacías, cuídate mucho y échale ganas.

Sheila Lizbeth, gracias por escucharme y hacerme los ratos amenos en los que estuve trabajando en el laboratorio, cuídate mucho.

RESUMEN

Una proxy caché es un intermediario entre un servidor Web y un navegador, que sirve para almacenar los datos frecuentemente solicitados por un cliente. Debido a la importancia de los tiempos de respuesta, el uso de proxy cachés se ha ido acrecentando cada vez más, así como el uso de varias cachés para formar un grupo de proxy cachés cooperativas, con el objetivo de compartir la información que se encuentra en sus cachés.

Pero desafortunadamente el uso de las proxy cachés en la Web no ha sido utilizado ampliamente, debido principalmente al desconocimiento de las mismas y a que estas proxy cachés tienen que ser configuradas manualmente, lo cual implica una tarea tediosa. Así también, se tiene que configurar de manera manual cada uno de los clientes (navegadores) que acceden a estas proxy cachés.

Esta situación genera diversos problemas, como por ejemplo: si alguna de estas proxy cachés falla, tienen que configurarse nuevamente tanto para los clientes como para las demás proxy cachés, por lo que todo el tiempo debe de haber una persona monitoreando que las proxy cachés estén activas.

Para resolver estos problemas, en este documento de tesis se propone un sistema de configuración dinámica de las proxy cachés.

El sistema está formado por un módulo de configuración dinámica del navegador para trabajar con una proxy caché y un grupo de módulos que se encargan de las distintas tareas de administración de las proxy cachés como son: darlas de alta, darlas de baja, cambiar su configuración, evaluar su viabilidad de uso y darle servicio a los navegadores.

Con el sistema propuesto ya no es necesario configurar manualmente a las proxy cachés ni a los navegadores, de la misma manera se reduce el trabajo a la persona encargada del monitoreo de la red. Por lo que este sistema nos ayuda a que no exista una subutilización de proxy cachés que podrían cooperar y evita la pérdida de tiempo que ocurre cuando se hacen peticiones a proxy cachés deficientes.

ABSTRACT

A proxy cache is a mediator between a web server and a browser which is used for storing frequently-required data by a client.

Due to the importance of time-response, the use of proxy caches has been increased, as well as the use of several proxy caches to build a cooperative proxy cache group, with the objective of sharing the data that the caches contain. But unfortunately, proxy caches have not been used widely in the Web mainly due to ignorance in their use and because these proxy caches have to be configured manually, which is a tedious task. Likewise, each client (browser) has to be configured manually in order to work with a proxy cache.

This situation generates several problems, for example: if a proxy cache in the group fails, they all have to configure themselves again, and the same goes for the clients. This requires a person monitoring that the proxy caches remain active all the time.

To solve the above problems, in this thesis a dynamic configuration system for proxy caches is proposed.

The system is conformed by a module of dynamic configuration for the browser in order to work with a proxy cache. A set of modules is for handling proxy caches management tasks, such as: registering a proxy cache, dropping a proxy cache, changing its configuration, evaluating its use viability and giving service to the browsers.

With the proposed system it is no longer necessary to configure either the proxy caches or the browsers manually; likewise, the work of the person monitoring the proxy caches is reduced. That is why, this system helps to prevent a poor use of a proxy cache that could cooperate and avoids time loss that occurs when requests are made to deficient proxy caches.

i

TABLA DE CONTENIDO TABLA DE CONTENIDO ......................................................................................... i LISTADO DE FIGURAS ..........................................................................................iii LISTADO DE TABLAS ............................................................................................iv GLOSARIO DE TÉRMINOS.................................................................................... v CAPÍTULO 1 INTRODUCCIÓN.............................................................................. 1

1.1 MOTIVACIÓN O JUSTIFICACIÓN .....................................................................3 1.2 DESCRIPCIÓN DEL PROBLEMA .......................................................................3 1.3 OBJETIVOS............................................................................................................5

1.3.1 Objetivo General .......................................................................................5 1.3.2 Objetivos Específicos ...............................................................................5

1.4 ALCANCES Y LIMITACIONES...........................................................................6 1.5 BENEFICIOS ..........................................................................................................7 1.6 ORGANIZACIÓN DEL DOCUMENTO ...............................................................8

CAPÍTULO 2 MARCO TEÓRICO......................................................................... 10

2.1 CACHING EN LA WEB ......................................................................................10 2.1.1 ¿Qué es el Caching en la Web? ..........................................................10 2.1.2 ¿Cómo Mejora la Velocidad el Caching?............................................11

2.2 PROXY CACHÉ ...................................................................................................11 2.3 ¿DÓNDE UBICAR UNA CACHÉ? .....................................................................11 2.4 TIPOS DE PROXY CACHÉS ..............................................................................12

2.4.1 Caché Aislada .........................................................................................12 2.4.2 Caché Transparente...............................................................................12 2.4.3 Caché Adaptativa....................................................................................13 2.4.4 Caché Activa............................................................................................13 2.4.5 Push Caching ..........................................................................................13 2.4.6 Cachés Cooperativas .............................................................................14

2.5 DISEÑO ARQUITECTÓNICO DEL CACHING COOPERATIVO EN LA WEB ......................................................................................................................14

CAPÍTULO 3 ESTADO DEL ARTE ...................................................................... 17

3.1 SQUID...................................................................................................................17 3.2 CACHÉS ADAPTATIVAS PARA LA WEB ......................................................20 3.3 LSAM PROXY CACHE (LPC)............................................................................21 3.4 INTERNET CACHE PROTOCOL V2.0 ..............................................................23 3.5 HYPER TEXT CACHING PROTOCOL V0.0.....................................................24 3.6 WEB CACHÉ COORDINATION PROTOCOL V1.0 .........................................25 3.7 WEB CACHÉ COORDINATION PROTOCOL V2.0 .........................................26 3.8 CACHÉ ARRAY ROUTING PROTOCOL V1.0.................................................27 3.9 WPAD ...................................................................................................................28

3.9.1 Proxy.pac .................................................................................................28 3.9.1.1 AUTOCONFIGURACIÓN DEL NAVEGADOR........................................ 29

3.9.2 Comparación de Programas .................................................................31

ii

CAPÍTULO 4 DESARROLLO DEL SISTEMA ...................................................... 33 4.1 ANÁLISIS DEL SISTEMA ..................................................................................33 4.2 DISEÑO DEL SISTEMA......................................................................................38

CAPÍTULO 5 IMPLEMENTACIÓN DEL SISTEMA............................................... 47

5.1 DISEÑO ARQUITECTÓNICO ............................................................................47 5.2 MÓDULO DE CONFIGURACIÓN DINÁMICA ENTRE PROXY CACHÉS ..49

5.2.1 Submódulo de Ingreso Dinámico de Proxy Cachés..........................49 5.2.1.1 Protocolo de Autoconfiguración entre Proxy Cachés............................... 50

5.2.2 Submódulo de Reconfiguración de Proxy Cachés Activas..............53 5.2.3 Submódulo de Análisis de las Respuestas de las Proxy Cachés...56 5.2.4 Submódulo de Detección de las Proxy Cachés Caídas ...................60

5.3 CONFIGURACIÓN DINÁMICA DEL NAVEGADOR (CLIENTE) .................63 CAPÍTULO 6 PRUEBAS ...................................................................................... 67

6.1 PLAN DE PRUEBAS ...........................................................................................67 6.1.1 Caso 1 ....................................................................................................68 6.1.2 Caso 2 ....................................................................................................70 6.1.3 Caso 3 ....................................................................................................72 6.1.4 Caso 4 ....................................................................................................74 6.1.5 Caso 5 ....................................................................................................76 6.1.6 Caso 6 ....................................................................................................77 6.1.7 Caso 7 ....................................................................................................81 6.1.8 Caso 8 ....................................................................................................83 6.1.9 Caso 9 ....................................................................................................84 6.1.10 Caso 10 ...................................................................................................85 6.1.11 Caso 11 ...................................................................................................87 6.1.12 Caso 12 ...................................................................................................88 6.1.13 Caso 13 ...................................................................................................89

CAPÍTULO 7 CONCLUSIONES........................................................................... 94

7.1 CONCLUSIONES.................................................................................................94 7.2 APORTACIONES.................................................................................................96 7.3 TRABAJOS FUTUROS........................................................................................97 7.4 PUBLICACIONES................................................................................................97

ANEXO A ANÁLISIS DEL ARCHIVO access.log ................................................. 98 ANEXO B CONFIGURACIÓN MANUAL DEL NAVEGADOR ............................ 109 ANEXO C CÓDIGO DEL SISTEMA ................................................................... 111 REFERENCIAS................................................................................................... 111

iii

LISTADO DE FIGURAS

Figura 3.1. Jerarquías de cachés ................................................................................ 19 Figura 3.2. Grupos de proxy cachés........................................................................... 20 Figura 3.3. Auto-configuración de una proxy caché para la comunicación entre

grupos de proxy cachés............................................................................ 21 Figura 3.4. Componentes del LSAM........................................................................... 22 Figura 3.5. Petición de un grupo con gustos afines ................................................. 23 Figura 3.6. Petición de clientes y respuesta por los filtros ...................................... 23 Figura 3.7. Pasos para configurar el Internet Explorer ............................................ 29 Figura 3.8. Pasos para configurar el Netscape......................................................... 30 Figura 4.1. Diagrama de Casos de Uso Principal..................................................... 34 Figura 4.2. Diagrama del caso de uso Configurar cliente ....................................... 35 Figura 4.3. Diagrama del caso de uso Configurar proxy caché ............................. 35 Figura 4.4. Diagrama del caso de uso Reconfigurar proxy caché local................ 36 Figura 4.5. Diagrama del caso de uso Detectar proxy caché caída ...................... 37 Figura 4.6. Diagrama del caso de uso Analizador de proxy caché ....................... 37 Figura 4.7. Diagrama de clases del módulo de configuración del cliente ............ 38 Figura 4.8. Diagrama de actividades del módulo que recibe las peticiones de los

clientes......................................................................................................... 39 Figura 4.9. Diagrama de actividades del módulo que configura una nueva proxy

caché ........................................................................................................... 40 Figura 4.10. Diagrama de actividades del módulo de monitoreo de peticiones de

conexión ...................................................................................................... 41 Figura 4.11. Diagrama de actividades del módulo de reconfiguración de una proxy

caché activa ................................................................................................ 41 Figura 4.12. Diagrama de actividades del módulo de monitoreo de ciertos

mensajes de configuración....................................................................... 42 Figura 4.13. Diagrama de actividades del módulo de monitoreo de proxy cachés

caídas .......................................................................................................... 43 Figura 4.14. Diagrama de actividades del módulo que verifica y desactiva proxy

cachés caídas............................................................................................. 44 Figura 4.15. Diagrama de actividades del módulo verificación la viabilidad de uso

y desactivación de proxy cachés............................................................. 45 Figura 4.16. Diagrama de actividades del módulo de reactivación de proxy

cachés ......................................................................................................... 46 Figura 5.1. Arquitectura general del prototipo ........................................................... 48 Figura 5.2. Submódulo de Ingreso Dinámico de Proxy Cachés............................. 49 Figura 5.3. Funcionamiento del protocolo entre las cachés ................................... 51 Figura 5.4. Submódulo de Reconfiguración de Proxy Cachés Activas................. 53 Figura 5.5. Funcionamiento de la reconfiguración entre las proxy cachés .......... 54

iv

Figura 5.6. Submódulo de Análisis de las Respuestas de las Proxy Cachés...... 56 Figura 5.7. Submódulo de Detección de las Proxy Cachés Caídas ...................... 60 Figura 5.8. Funcionamiento del submódulo de detección de proxy cachés

caídas .......................................................................................................... 61 Figura 5.9. Módulo de configuración dinámica del navegador del cliente............ 64 Figura 5.10. Ventana del Editor del Registro de Windows ........................................ 65 Figura 6.1. Detección de una proxy caché activa..................................................... 69 Figura 6.2. Recepción de un mensaje de tipo DISCOVER..................................... 70 Figura 6.3. No existen proxy cachés activas ............................................................. 70 Figura 6.4. Autoconfiguración cuando no existen proxy cachés activas .............. 71 Figura 6.5. Envío del archivo de configuración ......................................................... 73 Figura 6.6. Autoconfiguración cuando existen proxy cachés activas .................... 75 Figura 6.7. Recepción de un mensaje de tipo INFORM .......................................... 77 Figura 6.8. Reconfiguración de una proxy caché activa.......................................... 79 Figura 6.9. Recepción de un mensaje de tipo REINFORM .................................... 80 Figura 6.10. Detección de una proxy caché caída ..................................................... 82 Figura 6.11. Búsqueda de proxy cachés activas ........................................................ 86 Figura 6.12. No existen proxy cachés activas ............................................................. 87 Figura 6.13. Cliente configurado con una proxy caché activa. ................................. 87 Figura 6.14. Cliente configurado con otra proxy caché activa.................................. 88 Figura 6.15. Cliente configurado con una de las proxy caché activa. ..................... 89 Figura 6.16. Estructura de la intranet del Cenidet ...................................................... 90 Figura 6.17. Tasa de aciertos......................................................................................... 92 Figura 6.18. Tiempos de respuesta............................................................................... 92 Figura b1. Ventana de Opciones de Internet ......................................................... 110 Figura b2. Ventana de Configuración de red de área local ................................. 110

LISTADO DE TABLAS

Tabla 3.1. Comparación de protocolos para configuración dinámica de navegadores ............................................................................................... 31

Tabla 3.2. Comparación de protocolos para proxy cachés ................................... 32 Tabla 5.1. Mensajes que realiza el protocolo para la configuración dinámica ... 51 Tabla 5.2. Mensajes que realiza el protocolo para la reconfiguración dinámica 54 Tabla 5.3. Intercambio de mensajes para detectar proxy cachés caídas ........... 61 Tabla 6.1. Características de las trazas utilizadas en la simulación .................... 91

v

GLOSARIO DE TÉRMINOS

Ancho de banda. Medida de la información que fluye a través de un canal de comunicación (como los que unen una red) en una unidad de tiempo determinado (generalmente un segundo). Para dispositivos digitales, el ancho de banda se mide en bits por segundo (bps). El ancho de banda de circuitos analógicos se mide en ciclos por segundos (cps).

Broadcast message (mensaje de difusión). En una red de computadoras, mensaje enviado a todos los usuarios del sistema, que aparece al conectarse a éste.

Caché. Área de almacenamiento que facilita el acceso rápido a información o instrucciones de programa solicitadas con frecuencia para que la computadora no tenga que recuperarlas una y otra vez de un medio de almacenamiento lento. Las cachés mejoran el rendimiento mediante el almacenamiento de datos o instrucciones en secciones más rápidas de la memoria y utilizando un diseño eficaz a fin de aumentar la posibilidad de que los datos que se necesiten estén enseguida en la caché. En un navegador, sección del disco duro que se reserva para almacenar las páginas de más reciente acceso. Cuando se vuelve a visitar alguna de estas páginas, el navegador la obtiene de la caché y no de la red, mejorando considerablemente el tiempo de recuperación.

Carga. En un paquete, datos reales que se están transmitiendo a través de una red o por medio de líneas telefónicas.

Comunicación de datos. Transferencia electrónica de datos entre computadoras, la que puede ocurrir mediante conexiones directas por cables, como en las redes de área local (LAN), o a través de líneas telefónicas mediante módems.

Configurar. Adaptar una computadora a una necesidad específica, seleccionando entre una amplia gama de opciones de software y hardware. La

vi

configuración puede incluir la instalación nueva o reemplazo de hardware o software, o el cambio de parámetros en hardware o software existente.

Congestionamiento. Cuando hay demasiados paquetes presentes en la subred (o en una parte de ella), por lo que hay una degradación del desempeño, lo que significa que la carga es (temporalmente) mayor (en una parte del sistema) que la que pueden manejar los recursos. Se usan varias métricas para supervisar una subred en busca de congestionamientos, entre las principales son: el porcentaje de paquetes descartados debido a la falta de espacio de buffer, la longitud promedio de las colas, la cantidad de paquetes para los cuales termina la temporización (por lo que se transmiten de nuevo), el retardo promedio de los paquetes y la desviación estándar del retardo del paquete.

Control de concurrencia. En la versión de un programa de aplicación para red de área local (LAN), características integradas del programa que controlan lo que ocurre cuando dos o más personas tratan de usar una misma característica del programa o un archivo de datos. Numerosos programas que no están diseñados para redes pueden correr en una de éstas y permiten que más de una persona tenga acceso a un documento; sin embargo, esto puede proporcionar que alguien destruya de manera accidental el trabajo de otra persona. El control de concurrencia resuelve este problema, ya que permite el acceso múltiple siempre que no haya riesgo de pérdida de información, y lo registre cuando existe esta posibilidad.

Firewall. Procedimiento de seguridad que coloca, entre la red de área local (LAN) de una organización en Internet, un sistema de computación especialmente programado. La computadora Firewall impide que los crackers accedan a la red interna. Desafortunadamente, también impide que los usuarios de computadoras de la organización entren directamente a Internet; el acceso que la firewall proporciona es indirecto y mediado por programas llamados servidores proxy.

Hub. En una red de área local (LAN), dispositivo usado para crear una red a pequeña escala, conectando varias computadoras en conjunto.

vii

Memoria caché. Memoria de alta velocidad que reside entre la CPU y la RAM en una computadora. La memoria caché almacena datos e instrucciones que es probable que la CPU necesite continuamente. La CPU puede recuperar datos o instrucciones con mayor rapidez de la caché que de la RAM o de un disco. Pequeña unidad (que oscila en tan solo unos cuantos kilobytes a 256 o 512) de memoria ultra-rápida, la cual se utiliza para almacenar información a la que se ha accedido recientemente o a la que se accede con frecuencia, lo cual evita que el microprocesador tenga que recuperar esta información de circuitos de memoria más lentos. La memoria caché integrada directamente en los circuitos del microprocesador se conoce como caché primario o caché L1. La memoria caché contenida en un circuito externo se conoce como caché secundario o L2.

Mensaje. Señal de un proceso que le envía a otro proceso, solicitándole que realice una función específica.

Multicasting (multidifusión). En una red, la transmisión de un solo mensaje a dos o más estaciones de trabajo.

Navegador web. Programa que se ejecuta en una computadora conectada a Internet, proporciona acceso a las riquezas de la World Wide Web (WWW). Existen dos tipos de navegadores Web: de texto y gráficos. Los dos navegadores más populares son Microsoft Internet Explorer y Netscape Navigator, el navegador incluido en Netscape Comunicator. Los navegadores gráficos son preferibles porque el usuario puede observar imágenes en línea, fuentes y diseño de documentos.

Página web. Documento HTTP, se encuentra en la World Wide Web. Las páginas Web contienen información sobre algún tema en particular con vínculos a páginas Web relacionadas y otros recursos.

Protocolo. Conjunto de reglas y procedimientos que determinan cómo recibe y trasmite un sistema de cómputo. En comunicaciones de datos y conectividad, estándar que especifica el formato de los datos, además de

viii

las reglas que habrán de seguirse. No es posible diseñar ni mantener redes con rapidez y efectividad sin protocolo; un protocolo especifica la manera que un programa debe preparar los datos para que puedan enviarse a la siguiente etapa del proceso de comunicación.

Protocolo de red. Conjunto de normas usadas para comunicaciones de redes.

Proxy. También llamado servidor proxy. Programa que se ubica entre una red interna e Internet, el cual intercepta solicitudes de información. Un proxy, por lo general, es parte de una solicitud más amplia para la seguridad de la red interna, llamada Firewall. El propósito de un proxy es evitar que usuarios externos tengan acceso a recursos de la red interna o, por supuesto, que sepan exactamente dónde se encuentran esos recursos. El proxy intercepta una solicitud externa de información, determina si puede satisfacerse y pasa la solicitud a un servidor interno, cuya dirección no se revela al cliente externo. Al disfrazar la ubicación real del servidor que aloja realmente la información solicitada, el proxy dificulta mucho más que los criminales de las computadoras exploten potenciales huecos de seguridad en servidores y aplicaciones relacionadas, que podrían permitirles obtener accesos no autorizada a una red interna. Esta protección del ataque exterior se obtiene a costa de algunos inconvenientes (entre ellos, problemas de configuración y una ejecución más lenta) para los usuarios internos que desean acceder al Internet externo.

Router (encaminador, enrutador, ruteador). En una red de conmutación de paquetes con Internet, se encarga de examinar cada paquete de datos que recibe y luego decide de qué manera enviarlo a su destino.

Servidor proxy caché. En un servicio en línea, es un servidor que ha sido configurado para almacenar páginas Web a las que los miembros del servicio tienen acceso frecuente. Cuando los miembros solicitan estas páginas, el servidor proporciona la copia almacenada en lugar de solicitar la página a Internet. Los miembros ven las páginas Web con más rapidez y la red tiene menos carga, pero existe un inconveniente: tal vez la página desplegada no esté actualizada. Este término se usa a menudo como

ix

sinónimo (aunque incorrectamente) de proxy, programa de seguridad que establece una barrera para proteger a la red interna de ataques externos.

Switch. Dispositivo utilizado para conectar varios equipos informáticos, en redes locales, más seguro y fiable que el hub. El switch se denomina puente multipuerto, el cual toma decisiones basándose en las direcciones MAC y aumentan la velocidad de las redes al utilizar cada puerto todo el ancho de banda. Provee múltiples funcionalidades, como filtrado y conmutación de paquetes entre todas sus entradas, ya sean estaciones de trabajo u otras redes, basándose en la dirección de destino (aprende y recuerda, enviando la información solamente al puerto adecuado) y se utiliza para aumentar el rendimiento de las redes, segmentándolas en varias más pequeñas, lo que disminuye la congestión a la vez que sigue proporcionando la conectividad necesaria o conmutando las pequeñas, para aislar las estaciones entre sí, de modo que desaparezcan las múltiples colisiones generadas por un hub.

Tiempo de respuesta. Es el tiempo que transcurre cuando se realiza la petición desde la proxy caché hasta que ésta recibe el objeto.

Transceiver (transductor). Unión de transmisor y receptor. Se tienen dos acepciones: 1) En redes de área local (LANs), adaptador que permite a una estación de trabajo se conecte al cableado de la red. 2) En redes de área amplia (WANs) inalámbricas, modem capaz de transmitir y recibir datos de una computadora por medio de frecuencias de radio.

Capítulo 1. Introducción

1

CAPÍTULO 1

INTRODUCCIÓN

Debido al éxito que la Web ha tenido en las últimas décadas, la población de usuarios se ha ido acrecentando y se ha vuelto cada vez más exigente en tener la información lo más rápido posible; en ocasiones existen personas que tienen gustos afines y solicitan los mismos documentos, cada una de sus peticiones tiene que ir hasta el servidor origen, lo que ocasiona varios problemas, tales como: la sobrecarga en los servidores, el congestionamiento en la red, el aumento del consumo del ancho de banda disponible, entre otros.

Por lo tanto, para aminorar un poco estos problemas, una propuestas ha sido el uso del caching en la Web, el cual consiste en almacenar temporalmente


2

los datos frecuentemente accedidos lo más cerca posible del usuario, con el fin de reducir el tiempo de acceso a ellos y así disminuir el congestionamiento de la red, reducir el número de paquetes de comunicación que fluyen a través de la red y aminorar la sobrecarga de los servidores.

En la actualidad existen principalmente tres tipos de cachés en la Web: caché en el cliente (que es integrada en los navegadores para mejorar la eficiencia), caché en el servidor (ubicada en los servidores Web con el fin de reducir el tiempo de respuesta y la carga de trabajo), y proxy caché (que se encuentra ubicada en una localidad intermedia y por lo general se encuentra compartida entre usuarios que tienen alguna relación). Nos enfocaremos más a ésta última.

Las proxy cachés se encargan de enrutar la comunicación con el Internet, como es el caso de los firewalls, y pueden interceptar paquetes HTTP que realizan los clientes. Por ejemplo: cuando un cliente realiza una petición, la proxy caché la intercepta, busca primeramente esta información en su memoria; si no la encuentra, remite esta petición al servidor de origen en representación del cliente, el servidor le contesta a la proxy caché, ésta guarda una copia de la información en su memoria y se la pasa al cliente.

En la actualidad para poder hacer que un grupo de proxy cachés se comuniquen entre sí, se tienen que configurar de manera manual, y también se tiene que configurar de manera manual al cliente (navegador), indicándole qué proxy caché va a utilizar.

Existen varios tipos de configuraciones para las proxy cachés, una de las cuales es la de cachés adaptativas, que consiste en varias proxy cachés distribuidas, las cuales se unen o abandonan dinámicamente a un grupo de proxy cachés configurándose automáticamente.

Los grupos de proxy cachés se utilizan para hacer que las cachés cooperen entre sí, compartiendo documentos que se encuentran almacenados en sus cachés, de tal manera que si existen varios clientes que solicitan la misma información en las distintas proxy cachés, se disminuye el tiempo de respuesta. El fin primordial de éstas proxy cachés, es el de colaborar entre sí para mejorar la


3

calidad del servicio del conjunto de clientes conectados a las mismas, ya que evitan remitir las peticiones al servidor origen.

En el presente documento se describe a un sistema de proxy cachés cooperativas que se configuran de manera dinámica para cooperar entre ellas y el mecanismo de autoconfiguración de clientes para facilitarles el acceso a las proxy cachés, todo esto para obtener un sistema de proxy cachés cooperativas.

1.1 MOTIVACIÓN O JUSTIFICACIÓN

A pesar de que las proxy cachés han mostrado éxito en su funcionamiento, el hecho de tener una configuración manual ya sea para comunicarse con otras proxy cachés o para ser accedida por los clientes, ha desanimado su utilización y su aprovechamiento.

En la actualidad contamos con un software libre que hace las funciones de proxy caché, al cual es posible aplicarle las mejoras de configuración dinámica para fomentar y aprovechar de mejor manera el uso de las proxy cachés. De la misma forma es posible aplicarle una mejora al navegador Internet Explorer para que detecte de forma automática a las proxy cachés activas.

1.2 DESCRIPCIÓN DEL PROBLEMA

Debido al crecimiento exponencial tanto de usuarios como de información que la World Wide Web ha tenido, y la forma como se encuentra organizada, los clientes que desean obtener cualquier documento, tienen que ir directo hasta los servidores que los contienen.

En ocasiones existen varios usuarios que tienen gustos afines y solicitan los mismos documentos, y cada una de sus peticiones tiene que ir hasta el servidor donde se encuentra almacenada la información, lo que ocasiona mayor congestionamiento tanto en la red, como en los servidores, incrementando el consumo del ancho de banda, ocasionando altas latencias al extraer un documento, entre otros.


4

Para aminorar estos problemas, se ha recurrido al uso de la caché en la Web, el cual consiste en almacenar temporalmente los datos frecuentemente accedidos lo más cerca posible del usuario; sin embargo, en la actualidad nos encontramos con varios problemas que desaniman su utilización y que desaprovechan su capacidad de configuración. Así vemos que como primer problema tenemos el hecho de que las proxy cachés se tienen que configurar de manera manual, y si se configuran varias proxy cachés para que trabajen compartiendo información entre sí con la finalidad de reducir los tiempos de respuesta, se les tiene que indicar manualmente con cuales proxy cachés van a trabajar. El segundo problema es que se tiene que configurar de manera manual al cliente (navegador), indicándole cuál proxy caché va a utilizar.

Al tener un grupo de proxy cachés cooperativas y clientes conectados a ellas, el tercer problema es el desaprovechamiento del uso por parte de los clientes de otras cachés instaladas en la misma red, ya que si alguna proxy caché deja de funcionar, los clientes que estaban conectados a esa proxy caché ya no tienen acceso hacia el Internet. Esto ocasiona que pierdan tiempo en lo que se reestablece la conexión, o si estaban descargando alguna información, esta descarga tenga que volver a iniciar si es que no estaban usando algún programa que los prevenga de alguna desconexión. Y en caso de que el encargado no se dé cuenta de que alguna de las proxy cachés ya no está funcionando, se presenta un cuarto problema que tiene que ver con las peticiones de los clientes que utilizan esa caché, ya que estas peticiones no prosperarán, lo que conlleva a que una persona tenga que estar configurando la proxy caché nuevamente, y si es necesario, se tiene que configurar nuevamente a cada uno de los clientes que estaban conectados a esa proxy caché para reasignarles otra proxy caché, si es que ésta existe.

Por otro lado, un quinto problema sería que las proxy cachés que se encuentren activas continúen realizando peticiones a una proxy caché caída, lo que ocasiona una pérdida de tiempo al esperar alguna respuesta. Si ésta es la única caché vecina, se perderá siempre el tiempo al preguntarle por algún objeto Web en lugar de ir directo al servidor de origen.

Por otro lado, muchas veces existen proxy cachés que se encuentran instaladas en una misma red de proveedor de servicio de Internet (ISP, por sus


5

siglas en inglés) y tienen la desventaja de que no conocen de la existencia de sus vecinas, por lo que podríamos ver como un sexto problema el hecho de que haya una subutilización de proxy cachés que podrían cooperar.

Por todo lo anterior podemos decir que uno de los problemas que afectan a la población de usuarios de Internet en México, es que muy pocos utilizan a las cachés y además las pocas cachés que existen no utilizan a otras cachés que se encuentran en sitios cercanos para realizar una labor cooperativa, lo que desanima su uso y se desaprovecha el potencial que este tipo de herramienta nos ofrece.

1.3 OBJETIVOS

1.3.1 Objetivo General

Diseñar e implementar un sistema dinámico capaz de configurar de manera automática a un grupo de proxy cachés cooperativas para que compartan información entre sí. Además, este sistema será capaz de configurar de forma automática a los navegadores para ofrecerles los servicios de las proxy cachés.

1.3.2 Objetivos Específicos

• Diseñar e implementar un módulo de software que le permita a una proxy caché ingresar a un grupo de proxy cachés cooperativas, detectando a las proxy cachés activas existentes y configurándose de manera automática como miembro del grupo.

• Diseñar e implementar un módulo de software que permita a una proxy caché activa cambiar su configuración y de forma automática las demás proxy cachés activas detecten su nueva configuración.

• Diseñar e implementar un módulo de software que permita que, de manera automática, los clientes (navegadores) detecten a las proxy cachés activas y se configuren para trabajar con una de ellas.


6

• Diseñar e implementar un módulo de software que detecte, de manera automática, a las proxy cachés caídas y les comunique a las proxy cachés activas para que la den de baja.

• Diseñar e implementar un módulo de software que detecte, de manera automática, a las proxy cachés caídas y les avise a los clientes (navegadores) para que detecten a otra proxy caché activa y se configuren para trabajar con ella.

• Diseñar e implementar un módulo de software que evalúe de manera local, la eficiencia de las proxy cachés que se encuentran trabajando con ella y si su uso no es viable, darlas de baja temporalmente de manera local.

1.4 ALCANCES Y LIMITACIONES

Las metas que se logran y que están dentro de los alcances de esta tesis son:

• Implementar un protocolo encargado de la detección de las proxy cachés activas que se encuentran dentro de una intranet y al detectarlas, hacer la configuración de una proxy caché que quiere ingresar con la ayuda de ellas para que sea miembro del grupo de proxy cachés cooperativas. El protocolo trabaja bajo la plataforma de Linux y sólo se enfoca para el software libre Squid.

• Cambiar la jerarquía de configuración y sus parámetros a una proxy caché y que las demás proxy cachés activas reconozcan esta nueva configuración.

• Detectar a las proxy cachés caídas y avisarle a las demás proxy cachés que aún no la han detectado como proxy caché caída, así mismo avisarle a sus clientes para que detecten a una nueva proxy caché.


7

• Localizar a las proxy cachés activas y configurar dinámicamente al navegador Internet Explorer del cliente.

• Detectar cuándo la proxy caché con la que estaba trabajando el cliente ya no está funcionando, y dinámicamente asignarle una nueva proxy caché.

• Detectar y evaluar el número de respuesta afirmativas que se tiene por cada proxy caché localmente y mediante un porcentaje, el cual es dado y puede ser cambiado en un archivo de configuración, dar de baja temporalmente a la proxy caché que no alcance el porcentaje indicado.

Tanto los clientes (navegadores) como las proxy cachés deben encontrarse dentro de una intranet o una red de un proveedor de servicios de Internet en particular.

1.5 BENEFICIOS

• Al almacenar los documentos en la caché, se reduce el tráfico en la red y se minimiza la carga de trabajo del servidor de origen, se disminuye el número de paquetes de comunicación que fluyen a través de la red, gracias al almacenamiento de los documentos en la caché.

• Acelerar el acceso a los documentos cuando estos son accedidos por varias personas.

• Obtener una mayor respuesta a las peticiones de objetos Web, al utilizar proxy cachés cooperativas para la Web, cuando existen grupos de personas que accedan a las mismas páginas.

• Configurar de manera automática a los navegadores y aprovechar el servicio que ofrece la proxy caché.


8

• Detectar de manera automática, a las proxy cachés que se encuentran dentro de un sistema (intranet, red de un proveedor de servicios de Internet), para formar un grupo de proxy cachés cooperativas.

• Detectar de manera automática, la reconfiguración de las proxy cachés.

• Detectar de manera automática y reconfigurar a las proxy cachés activas cuando alguna proxy caché del grupo deja de funcionar.

• Detectar y reconfigurar de manera automática a los navegadores cuando alguna proxy caché del grupo deja de funcionar y ésta brindaba servicios al navegador.

• Evitar que exista una persona que esté configurando manualmente a cada proxy caché y a cada navegador.

1.6 ORGANIZACIÓN DEL DOCUMENTO

A continuación se da un panorama de la organización de este documento de tesis, el cual describe el trabajo que se realizó para diseñar e implementar un sistema de configuración dinámica entre proxy cachés y entre clientes con proxy cachés.

En el Capítulo 1, se presenta una introducción del uso de las proxy cachés, la problemática que se tiene, los beneficios que aporta este sistema así, como sus limitaciones.

En el Capítulo 2, se presenta un marco teórico con los tipos de proxy cachés existentes y su diseño arquitectónico.

En el Capítulo 3, se presenta el estado del arte, dando una explicación del software libre Squid y los protocolos soportados por las proxy cachés. También se


9

da una descripción del protocolo utilizado para la configuración del navegador y algunos trabajos relacionados con la configuración dinámica de proxy cachés.

En el Capítulo 4, se presenta el análisis del sistema modelado a través de diagramas de casos de uso de UML (Unified Modeling Language, Lenguaje de Modelado Unificado). También se presenta el diseño del sistema mediante un diagrama de clases para el cliente y diagramas de actividades para describir la funcionalidad de las proxy cachés.

En el Capítulo 5, se describe toda la arquitectura del sistema, se da una explicación de cada uno de los módulos que la componen y la interacción que hay entre ellos.

En el Capítulo 6, se describe un conjunto de documentos de pruebas que están asociados con los aspectos dinámicos de las pruebas del sistema, las cuales tienen un objetivo, un procedimiento y un resultado.

En el Capítulo 7, se derivan las conclusiones a que se llegó después de analizar, diseñar, implementar y probar el sistema.

Capítulo 2. Marco Teórico

10

CAPÍTULO 2

MARCO TEÓRICO

2.1 CACHING EN LA WEB

2.1.1 ¿Qué es el Caching en la Web?

Consiste en traer y almacenar temporalmente los objetos Web lo más cerca que se pueda de sus clientes (navegadores), con el fin de minimizar los tiempos de acceso a los mismos. Esta técnica ha sido aplicada con éxito desde su aparición en las jerarquías de memorias empleadas en las computadoras. El caching en la Web sigue las ideas originales del caching [Ball04] [Heat04].


11

2.1.2 ¿Cómo Mejora la Velocidad el Caching?

Los datos frecuentemente accedidos se guardan temporalmente cerca del solicitante. Así, la caché reduce o elimina elementos clave de retardo incluyendo [Cons04]:

• La transmisión de una petición del usuario final al dispositivo de almacenamiento.

• Congestión de la red entre el usuario final y el dispositivo de almacenamiento.

• Congestión dentro del propio dispositivo de almacenamiento.

• La transmisión de los datos desde el dispositivo de almacenamiento hasta el usuario final.

2.2 PROXY CACHÉ

Una proxy caché por lo general se encuentra en puntos de salida de la red, como es el caso del firewall y puede interceptar peticiones HTTP que realizan los clientes. Lo primero que realiza una proxy caché cuando intercepta una petición, es buscar esta información en su memoria, si no la encuentra, remite esta petición al servidor de origen en representación del cliente, el servidor le contesta a la proxy caché, la cual guarda una copia de la información en su caché y posteriormente pasa esta información al cliente.

2.3 ¿DÓNDE UBICAR UNA CACHÉ?

En general existen tres lugares principales donde se puede ubicar una caché:

• Cerca de los clientes (proxy cachés).


12

• Cerca de los servidores (de esta forma se mejora el nivel de calidad del servicio).

• En puntos estratégicos en la red (unas proxy cachés pueden estar cerca de los clientes, otras cerca de los servidores, esta forma de acomodar las proxy cachés es una de las más adecuadas para trabajar) [Sosa02a].

2.4 TIPOS DE PROXY CACHÉS

2.4.1 Caché Aislada

Se encuentra en el punto de acceso y salida de una intranet. Este tipo de configuración tiene la desventaja de que si ocurre una falla en la proxy caché, el acceso a la red externa no va a estar disponible. Al utilizar esta técnica se requiere que los usuarios configuren manualmente sus navegadores y cuando la proxy caché ya no está disponible se debe cambiar la configuración. Existe una propuesta para un protocolo de descubrimiento automático de proxy cachés en la Web denominado WPAD [Marl02], que autoconfigura los navegadores, el cual intenta localizar las proxy cachés más cercanas. WPAD se apoya en mecanismos para descubrir recursos, en los cuales incluye registros del DNS y del DHCP, localiza un archivo para la configuración automática de una proxy caché (APC). Un problema que tiene la caché aislada es que si su demanda sube no se pueden añadir dinámicamente más proxy cachés.

2.4.2 Caché Transparente

En este tipo de caché ya no es necesario configurar el navegador, ya que al momento en que el cliente realiza una petición HTTP destinado al puerto 80 se intercepta, y se redirecciona a una proxy caché o a un grupo de proxy cachés. Aquí se permite un cierto control administrativo para balancear la carga entre las proxy cachés. Existen 2 formas de manejar cachés transparentes: a nivel conmutador y a nivel ruteador. A nivel ruteador utiliza un encaminamiento basado en las políticas que redireccionan las peticiones a la(s) caché(s) más apropiada(s). Con el método de conmutador, se encarga de manera dedicada a balancear la


13

carga, no utiliza políticas; sin embargo, si las cachés no están disponibles no se tiene forma de redireccionar la petición hacia Internet.

2.4.3 Caché Adaptativa

Consiste en varias proxy cachés distribuidas, las cuales se unen o abandonan dinámicamente a un grupo de proxy cachés (malla). Utiliza un protocolo de administración de grupo de proxy cachés (CGMP) y un protocolo de encaminamiento de contenido (CRP). El CGMP especifica cómo es que se tiene que formar la malla, proporciona mecanismos para que proxy cachés individuales se unan y abandonen el grupo. Las proxy cachés están organizadas en grupos multicast sobrepuestos, las cuales utilizan técnicas de votación y retroalimentación para estimar la utilidad de admitir o excluir un miembro del grupo, por medio de este mecanismo se forma una topología virtual. El CRP localiza objetos dentro de la malla. Esta propuesta tiene la desventaja de que no se ha probado de manera exhaustiva y que si el uso de las proxy cachés no es viable no se desactiva.

2.4.4 Caché Activa

Se enfoca a documentos dinámicos, con la ayuda de applets ubicados en la misma caché para personalizar los objetos y así poder colocarlos en ella. Cuando el servidor por primera vez recibe una petición, manda el objeto solicitado con un applet asociado, en caso de que se realicen nuevas peticiones, sólo se ejecuta el applet que ya se encuentra instalado en la caché, técnica que no ha tenido aceptación debido a los problemas administrativos que conlleva enviar código a cachés en otros dominios administrativos en la red.

2.4.5 Push Caching

En este tipo de sistemas de caching, se detecta en qué partes de una red se están solicitando con mucha frecuencia documentos de un servidor o de una caché, y se crea de manera dinámica otra caché en esa zona de la red, a la cual se le emitirán los documentos antes de que hayan sido solicitados nuevamente, con el fin de que éstos ya se encuentren ahí en el momento que se requieran. Los datos dinámicamente se replican al momento en que el servidor detecta en dónde se encuentra el cliente. En este tipo de sistema de caching se supone que se


14

pueden arrancar cachés en cualquier lugar de la red sin tener límites administrativos.

2.4.6 Cachés Cooperativas

Estas cachés comparten documentos almacenados entre sí, de tal manera que si existen varios clientes que solicitan la misma información, se acelera el tiempo de respuesta y no se desperdician los canales de comunicación que se tienen en la red. El fin primordial de las proxy cachés cooperativas, es el de comunicarse entre ellas y evitar al máximo remitir esta petición al servidor de origen. Para permitir la comunicación entre proxy cachés, se necesita un mecanismo para poder definir la existencia de otras proxy cachés. También se busca que el intercambio de mensajes sea mínimo [Sosa02].

2.5 DISEÑO ARQUITECTÓNICO DEL CACHING COOPERATIVO EN LA WEB

La construcción de un sistema de cachés cooperativas requiere de varios aspectos a analizar entre los cuales podemos englobar cuatro grandes rubros:

Organización del sistema de cachés cooperativas, el cual puede ser:

• Jerárquico: En este tipo de organización las cachés se encuentran ubicadas en diferentes niveles de la red. En el nivel inferior se encuentran las cachés clientes (L1) que están conectadas directamente a los clientes (navegadores). En el siguiente nivel encontramos las cachés institucionales (L2), las cuales pueden ser las cachés que se ubican en algún nodo de la red universitaria. En el próximo nivel hacia arriba en la jerarquía se encuentran las cachés regionales o nacionales (L3), las cuales son cachés que pudieran ubicarse en un nodo troncal que enlaza varias universidades, o en un nodo troncal que enlaza la red de un país con otros países.


15

• Malla / Distribuida: Aquí sólo existen cachés institucionales que se encuentran en los niveles bajos de la red y se comunican entre sí para intercambiar información. Para decidir de cual caché extraer un objeto, las cachés pueden utilizar varios mecanismos de búsqueda, uno de ellos puede ser por medio de una consulta exhaustiva entre todas sus compañeras, emitiendo una consulta en broadcast. Otro mecanismo es el de mantener información en forma de metadatos acerca de los contenidos que están guardados en sus cachés compañeras.

• Híbrida: este tipo de organización es una combinación de las dos arquitecturas anteriores, la cual consiste de una jerarquía de cachés cuyas ramificaciones están formadas por mallas.

Comunicación entre cachés, se trata de establecer coordinación entre las cachés al menor costo. La comunicación entre las cachés puede existir en alguno de los siguiente procesos:

• Descubrimiento, destinado a cómo una caché localizará los objetos Web dentro de un grupo de cachés. Se puede hacer uso del ICP [Wess97] (Internet Cache Protocol), el cual se encarga de realizar la comunicación entre las cachés, para saber si un objeto que se desea extraer de la Web se encuentra entre ellas. Se puede utilizar un directorio de las cachés y una lista de los objetos que tiene almacenados cada caché, el intercambio de los objetos se hará de la forma peer to peer, o en forma jerárquica, o también se puede utilizar el método hashing.

• Obtención de los documentos; se trata de definir de qué manera se accederá a un objeto Web, ya sea por medio de un grupo de cachés o directo del servidor.

• Difusión de copias de los documentos entre las cachés.


16

Consistencia, para lograrlo se pueden utilizar diferentes algoritmos:

• Expire: manejo de fechas predefinidas de expiración de documentos.

• IMS: Verificación por consistencia cada vez que ocurre un acierto (hit).

• IMS – Alex: se asigna tiempo de vida proporcional al tiempo transcurrido desde su última modificación.

• Invalidación: El servidor al momento de actualizar un documento invalida las copias solicitadas previamente por las cachés.

• Variantes o combinación de los algoritmos anteriores.

Comportamiento de las cargas de trabajo, es el análisis a través de bitácoras del comportamiento de las cargas de trabajo que tienen los entes que participan en una interacción cliente /servidor en la Web [Sosa02].

Capítulo 3. Estado del Arte

17

CAPÍTULO 3

ESTADO DEL ARTE

3.1 SQUID

Una forma de acelerar la navegación en la Web es mediante la instalación de una caché. Squid se ha destacado por ser una de las mejores cachés que existen, el cual es un software gratuito diseñado para entornos Unix, Linux y Windows NT [Squi04].

Es un sistema que funciona como caché de objetos Web en la Internet. La función de Squid, es mantener una copia de los objetos Web que los usuarios solicitan, en otras palabras, si una persona quiere descargar una página Web, pide a Squid que obtenga dicha página, éste se conecta al servidor remoto y pide la


18

página, cuando el servidor remoto le contesta, Squid reenvía los objetos al usuario, pero al mismo tiempo mantiene una copia de los objetos en su caché y así, la próxima vez que alguien quiere dicha página, Squid simplemente la lee del disco y la transfiere al usuario de forma instantánea. Además soporta actualmente los protocolos HTTP, FTP, GOPHER, SSL y WAIS. No soporta otros protocolos como RealAudio, Streams y similares [Squi04] [Wess00].

Squid es un servidor proxy caché que permite utilizar una sola conexión a Internet para todos los clientes. Además, el servidor proxy caché Squid almacena en el disco duro las páginas más visitadas por los clientes, de tal manera que se disminuye el congestionamiento de la red, el número de paquetes de comunicación que fluyen a través de la red y aminora la sobrecarga de los servidores, cuando los clientes tienen gustos afines.

Otra de las funciones que realiza la proxy caché Squid, es verificar si la página ha cambiado, y de ser así, vuelve a almacenarla localmente. Es posible configurar Squid para definir cuanto tiempo pueden estar almacenadas las páginas en el servidor, así como realizar una configuración para que varias proxy cachés interactúen entre sí para formar un grupo de proxy cachés cooperativas, entre otras configuraciones que se pueden tener.

Al configurar una proxy caché Squid para que colabore con otras, se logra que trabajen conjuntamente compartiendo la información que se encuentra en sus cachés. Al realizar esta configuración de proxy cachés cooperativas, se pueden ir formando jerarquías entre las cachés, las cuales establecen relaciones entre si.

Hay dos tipos de relaciones: padres y hermanos. Una caché padre tiene esencialmente un nivel más en la jerarquía de cachés y una caché hermana está al mismo nivel que otra. Los términos vecino y par se utilizan para referirse tanto a padres como a hermanos, los cuales están sólo a un salto de caché de distancia, como se muestra en la figura 3.1.

Para indicarle a una proxy caché mediante Squid quién es su padre, se utiliza la relación de parent, y para indicarle a una proxy caché quién es su hermana, se utiliza la relación de sibling.


19

Figura 3.1. Jerarquías de cachés

Cuando un cliente realiza una petición, el flujo de los objetos Web pedidos se recorre de abajo hacia arriba de la jerarquía. Para ejemplificar un poco más el flujo de peticiones se menciona lo siguiente: un cliente realiza una petición, la proxy caché que trabaja con ese cliente intercepta la petición, busca primeramente esta información en su caché, si no la encuentra remite esta petición a su(s) caché(s) hermana(s) (si es que se tiene configurada alguna caché hermana). En caso de que esta(s) proxy caché(s) hermana(s) no tenga(n) la información solicitada, entonces la proxy caché remitirá esta petición a su(s) caché(s) padre(s) (si es que se tiene configurada alguna caché padre) en caso de que esta(s) proxy caché(s) padre(s) no tenga(n) la información solicitada se remitirá la petición al servidor de origen en representación de la proxy caché que le realizó la petición. Al momento de que el servidor de origen conteste la petición se guardará una copia en la(s) caché(s) del padre(s) y enviará esta información a la proxy caché que realizó la petición y ésta a su vez guardará una copia de esta información en su caché y enviará esta información al cliente [Sosa02].

Clientes (Navegadores)

Proxy Caché

Proxy Caché

Proxy Caché

ProxyCaché

Internet

ServidorOrigen

Proxy Cachés

Hermanas

ProxyCachéPadre




20

3.2 CACHÉS ADAPTATIVAS PARA LA WEB

En [Zhan97] nos indica que al hacer uso de las proxy cachés, se reduce la carga de trabajo en los servidores, el tiempo de respuesta para los clientes y el congestionamiento de la red. Propone la construcción de cachés adaptativas, lo cual consiste en un grupo de proxy cachés que trabajan de una manera cooperativa, compartiendo objetos entre sí. Hacen uso de multicast, proponiendo varios grupos de proxy cachés como se muestra en la figura 3.2, para así poder enviar el mismo documento a varias proxy cachés que se encuentran en un grupo. Lo utilizan también cuando un servidor quiere preguntar por algún objeto pero no sabe a quien preguntarle, por lo tanto realiza una pregunta multicast hacia un grupo específico, y si en este grupo no se encuentra, se hace la petición de la información al servidor de origen, el cual se encuentra ubicado en otro grupo.

Figura 3.2. Grupos de proxy cachés

Para que un grupo pueda comunicarse con otro, lo hace por medio de una proxy caché, ésta se autoconfigura con el grupo que contiene el objeto que se está buscando; por ejemplo, un cliente que se encuentra en el grupo G5 no encuentra la información ahí, por lo tanto, tiene que ir al servidor de origen, como se muestra en la figura 3.3.

Si este servidor se encuentra en otro grupo, en este caso en el G4, se autoconfigura una proxy caché del grupo G5 para que se pueda comunicar con el grupo G4, esta proxy caché es denominada C2 en este caso, y de esta manera ya se puede enviar la información hacia el host que realizó la petición.


21

Figura 3.3. Auto-configuración de una proxy caché para la comunicación entre

grupos de proxy cachés

Las proxy cachés para su autoconfiguración utilizan el CGMP (Cache Group Management Protocol, Protocolo de Administración de grupos de cachés), el cual va organizando geográficamente y administrativamente los grupos. Un punto crítico en las cachés adaptativas, es el de ir formando los grupos, por lo que se ha propuesto el uso de un protocolo desarrollado por MASH (Multimedia Achitecture that Scales across Heterogeneous environments, Arquitectura Multimedia escalable a través de ambientes heterogéneos) [Zhan97] y para mantener estos grupos pretenden, utilizar un protocolo denominado RTCP (Real-Time Control Protocol, Protocolo de Control de Tiempo Real) [Zhan97].

Sin embargo, este tipo de configuración de las proxy cachés, prevé un mundo en el cual las proxy cachés están ubicadas tanto en los puntos de acceso de las redes, como internamente en varias redes autónomas en Internet.

En el presente documento, se describe como es que se realiza la configuración dinámica de las proxy cachés para que puedan cooperar, pero estas proxy cachés se encuentran dentro de un solo sistema.

3.3 LSAM PROXY CACHE (LPC)

LSAM (Large-Scale Active Middleware, Intermediario activo a gran escala) es una caché Web multicast distribuida que proporciona push multicast automático de páginas Web, el cual, tiene implementado un módulo de autoconfiguración de grupos que tengan gustos afines.

La jerarquía de las cachés se autoconfigura conforme los grupos de páginas Web afines se vayan almacenando en la caché [Touc98].


22

Cuenta con una proxy caché llamada LPC, la cual se encuentra ubicada en varios lugares de la red, y consta de dos componentes, un servidor de proxy caché (llamado pump) y un conjunto distribuido de clientes proxy cachés (llamados filtros), como se muestra en la figura 3.4. Los filtros actúan como si fueran una sola proxy caché virtual, y se encargan del monitoreo de canales para localizar grupos afines. Las proxy cachés filtros son particionadas para permitirles el monitoreo de múltiples canales y aceptar la transmisión multicast en los canales sin una caché.

Figura 3.4. Componentes del LSAM

El pump monitorea el acceso al servidor y crea los canales multicast con grupos afines y los destruye. Los grupos afines pueden ser anunciados en un canal multicast simple, o en un canal multicast global. Esto es similar a los canales de teleconferencias.

Cuando se realiza una petición individual, la respuesta es enviada de forma multicast, siempre y cuando las páginas se encuentren dentro del grupo. Primero se verifica si esta información existe en las proxy cachés intermediarias (filtros), en caso de que ellas no contengan la información, la solicitud es enviada al servidor. La respuesta del servidor hacia los filtros, la hace de forma multicast y aquí se guarda una copia de la información, posteriormente la respuesta es enviada de forma unicast del filtro al proxy final y éste se encarga de regresar la información al cliente, este proceso se puede observar en la figura 3.5.


23

Figura 3.5. Petición de un grupo con gustos afines

La siguiente solicitud de la misma información, será respondida por los filtros, como se muestra en la figura 3.6, ya que ellos ya tienen una copia de la información en sus cachés, por lo que el tiempo de respuesta se agiliza.

Figura 3.6. Petición de clientes y respuesta por los filtros

3.4 INTERNET CACHE PROTOCOL V2.0

En [Wess97] y [Wess97a] es descrito el protocolo ICP (Internet Cache Protocol, Protocolo de Caché de Internet, RFC2186, RFC2187 para su aplicación) versión 2.0, el cual permite a las cachés preguntarse entre sí acerca de su contenido, usualmente se utiliza para evitar tener que ir hasta el servidor de origen. Esta comunicación se realiza mediante el uso de UDP en la capa de transporte, tiene una cabecera con longitud fija de 20 octetos más una carga útil de tamaño variable y sus números están representados en binario.

A través del uso del protocolo ICP, se realiza el intercambio de mensajes entre cachés vecinas y ayuda a la detección de la existencia de URLs (u objetos Web) en estas cachés vecinas, y así con la información recopilada, selecciona la localización más adecuada desde la cual extraerá un objeto Web.


24

Con este protocolo se puede obtener la accesibilidad del vecino, es decir, si éste no responde, quiere decir que ese camino de red está congestionado, caído o la aplicación no está funcionando en la máquina vecina. Por otro lado ICP maneja el balance de carga para cachés que se encuentran muy ocupadas.

Este protocolo puede ser configurado para que realice varias funciones, las cuales pueden ser: marcar como caché caída a alguna de las cachés vecinas que no responda después de un número de peticiones seguidas; modificar el tiempo de espera entre mensajes; configurar la caché para que si el tamaño del objeto Web pedido cabe en un mensaje, éste sea enviado al mismo tiempo de notificar que este objeto Web es encontrado en alguna caché vecina; configurarla para tener un control del acceso a la información entre las cachés; configurarla para que trabaje con un firewall; entregar solicitudes ICP a una dirección multicast; y las cachés vecinas pueden unirse al grupo multicast para recibir esas solicitudes, entre otras configuraciones.

Para poder utilizar ICP es necesario que las proxy cachés estén correctamente configuradas, para que éstas puedan cooperar, ya que este protocolo no cuenta con ningún módulo de autoconfiguración.

3.5 HYPER TEXT CACHING PROTOCOL V0.0

En [Vixi00] se describe el protocolo HTCP (Hyper Text Caching Protocol, RFC2756) versión 0.0, el cual se encarga de descubrir cachés HTTP y datos que se encuentran almacenados en las cachés. Manipula conjuntos de cachés HTTP y monitorea la actividad de las cachés. A diferencia de ICPv2, HTCP incluye las cabeceras completas en las peticiones y respuestas. Los mensajes HTCP pueden ser enviados como datagramas UDP, o a través de conexiones TCP. El IANA (Internet Assigned Numbers Authority, Autoridad de Números Asignados en Internet) ha asignado el puerto 4827 para TCP y UDP para HTCP.

Este protocolo realiza monitoreos de adiciones y borrados de cachés, pidiendo borrados inmediatos, y mandando indicaciones acerca de objetos Web, tales como la localización externa de los objetos Web que se encuentran en la caché, objetos Web que no están disponibles, etc.


25

Maneja varias cabeceras, dependiendo de las operaciones que se desean realizar, las cuales pueden ser: que se conozca que una o más proxy cachés mantienen una copia de este objeto Web; el manejo de políticas de cacheo del objeto Web, que indican que en la cabecera se tienen detalles acerca del objeto Web; la modificación de manera local de la política de cacheo del objeto Web, entre otras.

De la misma manera que el protocolo ICP, es necesario que estas cachés ya estén configuradas para que puedan cooperar.

3.6 WEB CACHÉ COORDINATION PROTOCOL V1.0

En [Cies99] se describe el protocolo WCCP (Web Caché Coordination Protocol) versión 1.0, el cual es propietario de Cisco. Este protocolo es usado para asociar un solo ruteador con una o más cachés, redirigiendo el tráfico Web desde el ruteador hacia el motor de caché de Cisco, con el propósito de descubrir, verificar e informar la conectividad a una o más cachés, definiendo la comunicación entre los motores Caché de Cisco y el ruteador.

Con WCCP, un ruteador redirecciona solicitudes Web hacia un motor caché de Cisco (más que intentar al servidor Web), sin tener que reconfigurar a los clientes.

El ruteador también determina la disponibilidad de las cachés o la presencia de nuevas cachés en el grupo. Cada paquete del protocolo WCCP es colocado dentro de un paquete UDP con un puerto destino 2048.

WCCP consta de un grupo de cachés asociados con un ruteador, que es referido como una granja de cachés. También consta de una caché designada (se recomienda la caché con la dirección IP más baja), y una tabla Hash que mapea la dirección IP destino de un paquete para redireccionarlo a la dirección IP de una caché dentro de la granja.

Una caché se puede unir a una granja mediante mensajes unicast hacia el ruteador, lo que involucra que se conozca la dirección IP para poderse añadir al grupo y así ésta comienza a trabajar dentro de la granja.


26

Este protocolo, también es usado para permitirle a una de las cachés, la caché designada, indicar como el ruteador distribuye el tráfico redireccionándolo transparentemente a través de las cachés asociadas. La redirección transparente involucra la intercepción y la redirección de tráfico HTTP a una o más cachés Web mediante un ruteador o switch, haciendo todo esto transparente para el cliente. Este protocolo se aplica a nivel de red, lo cual lo casa con un producto y lo hace menos portable a diferencia de implementarlo a nivel de aplicación.

3.7 WEB CACHÉ COORDINATION PROTOCOL V2.0

En [Cies00] se describe el protocolo WCCP (Web Caché Coordination Protocol) versión 2.0, el cual especifica la interacción entre uno o más ruteadores y una o más cachés. El propósito de la interacción es establecer y mantener la redirección transparente de tipos seleccionados de tráfico a través de un grupo de ruteadores. El tráfico seleccionado es redireccionado a un grupo de cachés con el propósito de optimizar el tratamiento de recursos y minimizar los tiempos de respuesta.

Para esta versión, la caché designada le indica al ruteador o ruteadores cómo el tráfico redireccionado debe ser distribuido entre los miembros de la granja. Se añade un método de remisión, por el cual los paquetes redireccionados son transportados desde el ruteador a la caché; un método de retorno de paquete por el cual los paquetes redireccionados a una caché son regresados al ruteador para una remisión normal; un grupo de servicio, el cual es un grupo de uno o más ruteadores mas uno o más cachés trabajando juntos en la redirección del tráfico, cuyas características son parte de la definición de un grupo de servicio. El protocolo proporciona la manera adecuada para negociar el método específico usado para la distribución de la carga entre las cachés, y además el método es usado para transportar tráfico entre el ruteador y la caché.

Esta versión soporta el envío de mensajes multicasting entre cachés y ruteadores y proporciona autenticación opcional de paquetes de protocolos recibidos por las cachés y ruteadores, además, soporta la redirección del tráfico que no es HTTP al permite a una caché rechazar un paquete redireccionado y regresarlo a un ruteador para ser remitido. El método mediante el cual los paquetes son regresados a un ruteador es negociable.


27

3.8 CACHÉ ARRAY ROUTING PROTOCOL V1.0

El protocolo CARP (Caché Array Routing Protocol) versión 1.0 descrito en [Vall98], es utilizado para dividir espacios de URLs entre un arreglo de servidores proxy débilmente acoplados. Permite el balance de carga dinámico en los múltiples servidores dentro del arreglo, por lo que se distribuye el contenido y aumenta el tamaño efectivo de la caché sin duplicar el contenido, maximiza los hits a la caché y preserva el ancho de banda.

Para hacer la división de espacios de URLs se utiliza una función hash; otra función que también utiliza este protocolo, es una función de ruteo. Este protocolo tiene incluída una “Tabla de Miembros Participantes o de Membresías” (archivo de texto en ASCII), que es el grupo de proxy cachés cooperativas, así como las formas de obtener esta información.

Un cliente HTTP (proxy o navegador) que implementa CARP v1.0, puede asignar e inteligentemente dirigir solicitudes de un URL hacia uno de los miembros. Gracias a una clasificación eficiente de los URLs entre los miembros, las réplicas en la caché son eliminadas, mejorando aciertos globales.

Este protocolo permite rastrear el estado actual de una tabla de arreglos y en ocasiones, es usado para igualar múltiples copias publicadas independientemente de la tabla de membresía de arreglo de proxy cachés. Mantiene datos del tiempo en que un servidor proxy ha estado en su estado actual y cuanto tiempo ha sido un miembro de esta tabla. Este protocolo maneja un factor de la carga total para el arreglo, que debe ser manejado por cualquier miembro dado de un arreglo, también se le puede indicar el tamaño de la caché que posee un miembro en particular de la tabla de arreglos.

Una vez que se tiene una tabla de membresías de arreglo de proxy cachés, se usa una función hash matemática para determinar cuales de los miembros del arreglo deben ser receptores de una particular petición URL. La función de ruteo se encarga de construir n “cuentas” aplicando una función hash al URL de la petición, más una función hash por cada k proxy caché en la tabla de membresías de arreglo de proxy cachés. Para poder utilizar este protocolo, es necesario que estas proxy cachés ya estén configuradas.


28

3.9 WPAD

En [Coop00] se describe un protocolo de Internet que permite a un cliente, tales como navegadores Web, automáticamente localizar e interactuar con una proxy caché, para que el contenido sea entregado de forma más rápida.

Puede configurar a un navegador automáticamente la primera vez que se inicie. De esta forma, puede ayudar a reducir el trabajo de administración y las llamadas a su servicio de soporte acerca de la configuración del navegador.

La configuración automática del navegador, se basa en el protocolo Web Proxy AutoDiscovery (WPAD), el cual es compatible con el Protocolo de Configuración Dinámica de Host (DHCP) y con el Sistema de Nombre de Dominio (DNS). Con la configuración adecuada, los servidores DHCP y DNS pueden detectar y configurar automáticamente un navegador.

Esta característica se basa en tecnologías automáticas de configuración, según las cuales un navegador puede configurarse desde una ubicación central con una dirección URL de configuración automática (archivo .INS) o con un archivo Javascript para la configuración de proxy (.js, .jvs, .pac).

Para hacer esta autoconfiguración es necesario indicarle manualmente una dirección URL de un archivo de autoconfiguración (http://www.ujaen.es/sci/redes/proxy/proxy.pac), por lo que surge un problema, si esta dirección cambia, es necesario cambiar la dirección manualmente por la nueva dirección.

3.9.1 Proxy.pac

Este archivo realiza la autoconfiguración del navegador para que trabaje con un servidor proxy, el mayor inconveniente es que se tiene que tener conocimiento de la URL donde está dicho archivo, además de la necesidad de configurar manualmente el navegador. Este programa está desarrollado en JavaScript [Nets96].


29

3.9.1.1 AUTOCONFIGURACIÓN DEL NAVEGADOR

Figura 3.7. Pasos para configurar el Internet Explorer


30

En [Sorr04] se menciona que hay un programa llamado proxy.pac que se encarga de la autoconfiguración del navegador para trabajar con una proxy caché. Existe este programa tanto para Netscape como para Internet Explorer, pero la autoconfiguración no es completa ya que se tiene que ir al navegador a configurar manualmente una parte.

Figura 3.8. Pasos para configurar el Netscape


31

En la figura 3.7, se muestra paso a paso cómo hacer esta configuración para Internet Explorer, y en la figura 3.8 se muestra paso a paso cómo hacer esta configuración para el Netscape. En esta forma de configurar el navegador, si la proxy caché falla se tiene nuevamente que configurar al navegador.

En la sección 5.3 se describe un mecanismo de configuración dinámica del navegador Internet Explorer, de tal forma que cuando un cliente se conecte a la intranet, se configura de manera automática, y si en un momento determinado la proxy caché con la que se configuró el cliente por alguna razón falla, el navegador se vuelve a configurar de manera automática con otra proxy caché (si es que existe), haciendo todo esto transparente para el cliente.

3.9.2 Comparación de Programas

La tabla 3.1 muestra una comparación entre el programa proxy.pac y el proyecto realizado. En esta tabla se observa que el programa proxy.pac no realiza una autoconfiguración, ya que es necesario indicarle la URL a donde se tiene que conectar.

Tabla 3.1. Comparación de protocolos para configuración dinámica de navegadores

Proxy.pac Proyecto Auto detección de la proxy caché

Sí Sí

Autoconfiguración Parcial

(Netscape, Internet Explorer)

Sí (Internet Explorer)

Portátil No Sí

La tabla 3.2 muestra una comparación entre los protocolos que pueden utilizar las proxy cachés y el proyecto realizado. En esta tabla se observa que ninguno de los protocolos realiza una autoconfiguración, y en algunos casos sólo realizan una autoconfiguración parcial


32

Tabla 3.2. Comparación de protocolos para proxy cachés

Detección de cachés activas Autoconfiguración ICP No No

HTCP Si No WCCP v1.0 Parcial Si WCCP v2.0 Parcial Si

CARP No No Proyecto Si Si

Capítulo 4. Desarrollo del Sistema

33

CAPÍTULO 4

DESARROLLO DEL SISTEMA

4.1 ANÁLISIS DEL SISTEMA

A continuación se presenta el análisis del sistema, modelado con diagramas de casos de uso de UML (Unified Modeling Language, Lenguaje de Modelado Unificado).

La figura 4.1 muestra el diagrama general de la herramienta, con los diferentes módulos que se tienen.

Hay cinco casos de uso principales: Configurar cliente, Configurar proxy caché, Reconfigurar proxy caché local, Detectar proxy caché caída y Analizador


34

de proxy caché caída. Los actores son: Usuario, las personas que utilizan el sistema, y pueden ser de dos tipos, Usuario cliente, el que utiliza el navegador, y Usuario proxy caché, el que utiliza el administrador de la proxy caché; Navegador, es el navegador Internet Explorer; Proxy caché X, representa a una proxy caché y Archivo de configuración X, para indicar una parte de la proxy caché.

Configurar cliente

Reconfigurar proxy caché local

Usuario

Analizador de proxy cachés

Navegador

Proxy caché 1

Proxy caché 2

Detectar proxy caché caída

Configurar proxy caché

<<include>>

<<include>>

Figura 4.1. Diagrama de Casos de Uso Principal

La figura 4.2 muestra el diagrama del caso de uso Configurar cliente, que es ejecutado por el Usuario cliente cuando quiere configurar al Navegador. Este caso consiste en detectar a las proxy cachés activas, una vez detectadas se modifica el registro de Windows en donde se encuentra configurado el navegador.

La figura 4.3 muestra el diagrama del caso de uso Configurar proxy caché, que es ejecutado por el Usuario proxy caché cuando quiere registrar a una proxy caché para que sea parte del grupo. Este caso consiste en configurar a la proxy caché que quiere ingresar, modificando sus archivos con ayuda de la recepción de un archivo de configuración, el cual se recibe. Posteriormente se les notifica a las demás proxy cachés para que modifiquen sus archivos y la registren.


35

Usuario cliente Proxy caché 1

Proxy caché 2

Detectar proxy caché

Modificar registro de Windows

<<include>>

NavegadorConfigurar Navegador

<<include>>

Figura 4.2. Diagrama del caso de uso Configurar cliente

Archivo de configuración de Squid 2


Archivo de configuración 3

Usuario proxy caché


Archivo de configuración de Squid 1 Configurar proxy cachés activas

Configurar a la proxy caché a ingresar

<<include>>


Figura 4.3. Diagrama del caso de uso Configurar proxy caché


36

La figura 4.4 muestra el diagrama del caso de uso Reconfigurar proxy caché local, que es ejecutado por el Usuario proxy caché cuando quiere cambiar la configuración local. Este caso consiste en reconfigurar a la proxy caché modificando sus archivos y posteriormente se les notifica a las demás, para que ellas modifiquen sus archivos y registren el cambio.





Usuario proxy caché



Reconfigurar proxy cachés

Reconfigurar proxy caché local

<<include>>

Figura 4.4. Diagrama del caso de uso Reconfigurar proxy caché local

La figura 4.5 muestra el diagrama del caso de uso Detectar proxy caché caída, que es ejecutado localmente cuando la nueva proxy caché se configura. Este caso consiste en detectar y dar de baja a las proxy cachés caídas modificando los archivos locales, si en verdad se confirma que se encuentran inactivas. Enseguida se les notifica a las demás para que también las den de baja.


37

Configurar proxy caché Archivo de configuración de Squid 2


Detectar a la proxy caída





Baja de la proxy caché caídaNotificar a proxy cachés

Verificar proxy caché caída

<<extend>>

Proxy caché 1

<<extend>>

<<include>>

Figura 4.5. Diagrama del caso de uso Detectar proxy caché caída

La figura 4.6 muestra el diagrama del caso de uso Analizador de proxy caché, que es ejecutado localmente cuando la nueva proxy caché se configura. Este caso consiste en analizar la bitácora local para detectar cuando el uso de ciertas proxy cachés no es viable y desactivarlas o activarlas según sea necesario.

Configurar proxy caché

Desconfigurar proxy caché

Analizar bitácora

<<include>>



Reactivar proxy caché

<<include>>

Figura 4.6. Diagrama del caso de uso Analizador de proxy caché


38

4.2 DISEÑO DEL SISTEMA

Para diseñar el módulo de configuración del cliente se utilizó el paradigma orientado a objetos. Este módulo fue implementado en el lenguaje Java para proveer una interfaz gráfica amigable y el soporte para modificar el registro de Windows. En la figura 4.7 se muestra el diagrama de clases de este módulo.

Thread

run()JFrame

ActionListener

actionPerformed()

Desactivaipport : Stringvalor : Integerreg : RegistryKeyproxy_habilitado : RegistryValueproxy : RegistryValue

Desactiva_serv()

Activaipport : Stringvalor : Integerreg : RegistryKeyproxy_habilitado : RegistryValueproxy : RegistryValue

Activa_serv()

Servidor<<static>> salida : JTextField<<static>> Trans : JButtonipaddr : InetAddressaddr : InetAddressSalidaSocket : DatagramSocketCicloSocket : DatagramSocketEntradaSocket : DatagramSocketSalida : DatagramPacketCiclo : DatagramPacketEntrada : DatagramPacketipAddr : bytebufferSalida : bytebufferEntrada : bytebufferCiclo : byteip : StringipBroadcast : Stringipport : Stringmascara : Stringsubnetmask : Stringproxyserver : Stringport : intport2 : intport3 : intcaracter : charipconfig : Vector

<<static>> ligaInterfaz()Servidor()run()

+desconfigura

+configuraInterfaz

menuBar1 : JMenuBarmenuAyuda : JMenumenuAyudaInfo : JMenuItemstatusBar : JLabelEtiqIP : JLabel<<static>> IP : JTextField<<static>> Trans : JButtoninterrup : Checkbox

Interfaz()actionPerformed()<<static>> main()

+$serv

Figura 4.7. Diagrama de clases del módulo de configuración del cliente

Se tienen cuatro clases que realizan la configuración del navegador, así como para activar o desactivar proxy cachés del navegador. La clase Interfaz sirve únicamente para la interfaz gráfica del usuario. La clase Servidor realiza la detección de las proxy cachés activas y se encarga de estar escuchando por si la proxy caché con la que se está trabajando deja de funcionar. Esta clase utiliza hilos y esta funcionalidad es provista por la clase Thread. La clase Activa sirve


39

para configurar al navegador para que trabaje con una proxy caché, mediante el uso de una API (Application Programming Interface, Interfaz de Programación de Aplicaciones) para modificar el registro de Windows y ligar al navegador con la proxy caché. Finalmente, la clase Desactiva sirve para dar de baja a la proxy caché que se encuentra configurada en el navegador utilizando nuevamente la API mencionada.

Para diseñar los demás módulos de configuración del sistema se utilizó el paradigma procedural. Estos módulos fueron implementados en el lenguaje C para mantener la compatibilidad del lenguaje en el que fue implementado el software libre Squid. El diseño fue realizado apoyándose en los diagramas de actividades de UML.

La figura 4.8 muestra el diagrama de actividades del módulo de la proxy caché que recibe las peticiones del cliente. Cuando la proxy caché a ingresar se configura ejecuta localmente este módulo, el cual se encarga de monitorear las peticiones de los clientes. Cuando recibe una solicitud de configuración, la proxy caché le responde enviándole su dirección IP.

Recepción de una petición del cliente

Envío de la dirección IP local

Figura 4.8. Diagrama de actividades del módulo que recibe las peticiones de los clientes

La figura 4.9 muestra el diagrama de actividades del módulo que se encarga de configurar a la proxy caché que quiere ingresar. Cuando ésta se va a configurar, manda un mensaje de tipo DISCOVER para detectar a las proxy cachés activas, en caso de que éstas no existan, sólo se realiza la configuración


40

de esta proxy caché; en caso contrario se establece la conexión con una de ellas y se recibe un archivo de configuración.

Posteriormente, con ayuda de este archivo se modifica y notifica su configuración a las que ya se encuentran activas mediante un mensaje de tipo INFORM. Una vez configurada, se inicia la ejecución de sus programas monitores.

Envio del mensaje DISCOVER para la detección de las proxy cachés activas

Hay ACK?

Recepción del archivo de configuración

Configuración de la proxy caché a ingresar

Envio del mensaje INFORM para la notificación de configuración exitosa

Ejecución de programas monitores

Configuración de la proxy caché a ingresarno

Establecer la conexión

si

Recepción del mensaje ACK

Figura 4.9. Diagrama de actividades del módulo que configura una nueva proxy caché


41

La figura 4.10 muestra el diagrama de actividades del módulo de la proxy caché que se encarga de monitorear las peticiones de establecimiento de la conexión. Este monitoreo se inicia localmente en la proxy caché que ingresó al grupo. Al establecer la conexión se envía el archivo de configuración.

Envío del archivo de configuración

Monitoreo de peticiones de conexión

Figura 4.10. Diagrama de actividades del módulo de monitoreo de peticiones de conexión

La figura 4.11 muestra el diagrama de actividades del módulo que se encarga de reconfigurar a una proxy caché activa. Este módulo se ejecuta a través de un comando en línea, incluyendo los parámetros de reconfiguración. Con estos parámetros se hace la configuración localmente y posteriormente se envía un mensaje de tipo REINFORM para notificar a las demás proxy cachés de su nueva configuración.

Reconfiguración de la proxy caché local

Envío del mensaje REINFORM

Recepción del mensaje ACK

Recepción de los parámetros de reconfiguración

Figura 4.11. Diagrama de actividades del módulo de reconfiguración de una proxy

caché activa


42

La figura 4.12 muestra el diagrama de actividades del módulo de la proxy caché que se encarga de monitorear ciertos mensajes (DISCOVER, INFORM y REINFORM) que son enviados por otras proxy cachés. Este monitoreo se inicia localmente en la proxy caché que ingresó al grupo.

Al recibir un mensaje de tipo DISCOVER se envía una confirmación utilizando un mensaje de tipo ACK y se retorna a monitorear. Al recibir un mensaje de tipo INFORM también se envía una confirmación, se inicia un proceso en paralelo y se retorna a monitorear. Este proceso en paralelo añade a la nueva proxy caché y se reinicia para que tome en cuenta los cambios. Al recibir un mensaje de tipo REINFORM también se envía una confirmación, se inicia un proceso paralelo y se retorna a monitorear. Este proceso en paralelo cambia la configuración que se tiene localmente de una proxy caché externa y se reinicia para que tome en cuenta los cambios.

Recepción de un mensaje

Es de tipo DISCOVER?

Es de tipo INFORM?

no

Es de tipo REINFORM?

no

no

Envío del mensaje ACK

si

Reconfiguración local

Adición de la proxy caché a ingresar

Reconfiguración de una proxy caché externa

Envío del mensaje ACK2

si

Envío del mensaje ACK

si

Reconfiguración local

Figura 4.12. Diagrama de actividades del módulo de monitoreo de ciertos mensajes de configuración


43

La figura 4.13 muestra el diagrama de actividades del módulo que se encarga de monitorear cada cierto tiempo para detectar cuando alguna proxy caché deja de funcionar. Este monitoreo se inicia localmente en la proxy caché que ingresó al grupo.

Detección de una posible proxy caché caída

Envío del mensaje SURVIVE para detectar si se encuentra caída

Recepción del ACK?

Se encuentra activa?

si

Desactivación de la proxy caché caída

no


Envío del mensaje DEACTIVATE a las proxy cachés activas

Notificación a los navegadores de la proxy caché caída

Realizar espera para el siguiente monitoreo

no si

Figura 4.13. Diagrama de actividades del módulo de monitoreo de proxy cachés caídas


44

Cuando se detecta la posible caída de alguna proxy caché externa, provoca que se le envíe un mensaje de tipo SURVIVE. Si se confirma su caída, esta proxy caché externa es desactivada y se reinicia a la proxy caché local. Enseguida se les informa de este cambio a las demás proxy cachés activas mediante un mensaje de tipo DEACTIVATE y así mismo se les informa a los clientes.

La figura 4.14 muestra el diagrama de actividades del módulo de la proxy caché que se encarga de verificar si se encuentra ejecutándose su proceso Squid y de dar de baja a una proxy caché externa. Este módulo se inicia localmente en la proxy caché que ingresó al grupo.

Al recibir un mensaje de tipo SURVIVE verifica que su proceso Squid se encuentre ejecutándose y envía el estado de éste. Al recibir un mensaje de tipo DEACTIVATE se envía una confirmación utilizando un mensaje de tipo ACK, se inicia un proceso paralelo y se retorna a monitorear. Este proceso en paralelo desactiva a la proxy caché caída y se reinicia.

Recepción de un mensaje

Es de tipo SURVIVE?

Es de tipo DEACTIVATE?

no

Verificar si Squid está activo

si

Está activa?

Envío del mensaje ACK informando que está activa

si

Envío del mansaje ACK informando que no está activa

no

Desactivación de la proxy caché caída


Envío del mensaje ACK2

si

no

Figura 4.14. Diagrama de actividades del módulo que verifica y desactiva proxy

cachés caídas


45

La figura 4.15 muestra el diagrama de actividades del módulo de la proxy caché que se encarga de verificar la viabilidad de uso que se tiene localmente por cada proxy caché mediante un monitoreo, el cual se realiza cada cierto tiempo. Este monitoreo se inicia localmente en la proxy caché que ingresó al grupo.

Utilizando un archivo de configuración, se establece el parámetro para el tiempo entre monitoreos y el parámetro aceptable de viabilidad de uso. De acuerdo al desempeño de las proxy cachés externas, se obtiene el grado de viabilidad de cada una de ellas y en caso de no ser viable su uso, ésta se desactiva temporalmente pero sólo de manera local, llevando un registro en un archivo de estado.

Lectura del archivo de configuración

Monitoreo del archivo access.log

Evaluación de la viabilidad de uso

es viable?

Desactivación temporal

no


si

Modificación del archivo de estado de las proxy cachés

Figura 4.15. Diagrama de actividades del módulo verificación la viabilidad de uso y desactivación de proxy cachés


46

La figura 4.16 muestra el diagrama de actividades del módulo de la proxy caché que se encarga de reactivar a las proxy cachés que han sido dadas de baja temporalmente de manera local. Este monitoreo se inicia localmente en la proxy caché que ingresó al grupo.

Utilizando un archivo de configuración se establece el parámetro para el tiempo entre monitoreos. Se monitorea el archivo de registro de estado de las proxy cachés para detectar las que deben ser reactivadas localmente. Si se cumple el tiempo que tiene que permanecer desactivada una proxy caché externa, se le vuelve a dar de alta de manera local. Sin importar si se hace una reactivación, se modifica el archivo de registro de estado de las proxy cachés para actualizar el tiempo que lleva desactivada.

Lectura del archivo de configuración

Monitoreo del archivo de estado de las proxy cachés

Verificar condición de activación

activar?

Activación de la proxy caché

Modificación del archivo de estado de las proxy cachés


sino

Figura 4.16. Diagrama de actividades del módulo de reactivación de proxy cachés

Capítulo 5. Implementación del Sistema

47

CAPÍTULO 5

IMPLEMENTACIÓN DEL SISTEMA

5.1 DISEÑO ARQUITECTÓNICO

El prototipo se encuentra dividido en dos módulos como se observa en la figura 5.1, un módulo se utiliza para realizar toda la configuración dinámica de un grupo de proxy cachés cooperativas, y el otro módulo se utiliza para realizar la configuración del navegador del cliente asignándole una proxy caché para que trabaje con ella.


48

Figura 5.1. Arquitectura general del prototipo


49

Configuración de la proxy caché

a ingresar


activa

Ingreso dinámico de proxy cachés


a ingresar


activa

Ingreso dinámico de proxy cachés

En la arquitectura, para indicar las partes que solamente se utilizaron y que

no fueron desarrolladas, se utiliza un recuadro con relleno tipo rombo , y para

indicar que nos estamos refiriendo a un archivo se utiliza el símbolo .

Se ha utilizado el software libre Squid para Linux, que como se ha mencionado en la sección 3.1, es una proxy caché que puede trabajar con varios protocolos para la comunicación entre las proxy cachés, así como formar jerarquías de cachés.

Por el lado de los clientes, en donde se lleva acabo la configuración del navegador se encuentra el resto del módulo de configuración dinámica del navegador del cliente.

5.2 MÓDULO DE CONFIGURACIÓN DINÁMICA ENTRE PROXY CACHÉS

En cada una de las proxy cachés se va a tener este módulo, el cual se encarga de realizar toda la configuración dinámica entre ellas, por lo que se subdividió en varios submódulos y cada uno tiene un funcionamiento específico, con el fin de tener un sistema que detecte cuando alguna proxy caché ingrese al grupo o se salga de él, cuando alguna se reconfigure y además se encarga de realizar un análisis de la respuesta que se tiene localmente de cada una de ellas.

5.2.1 Submódulo de Ingreso Dinámico de Proxy Cachés

Figura 5.2. Submódulo de Ingreso Dinámico de Proxy Cachés


50

El submódulo de Ingreso dinámico de proxy cachés se encarga de realizar la configuración dinámica de una proxy caché que quiere ingresar al grupo que se encuentran en una intranet y así mismo reconfigura a éstas para que la reconozcan como un nuevo miembro del grupo.

Este submódulo se encuentra subdividido en otros dos submódulos como se puede observar en la figura 5.2. El submódulo de configuración de la proxy caché a ingresar, se utiliza para la proxy caché que aún no está configurada y se comunica con el submódulo de configuración de la proxy caché activa, de las que ya se encuentran activas en el grupo. Así mismo el submódulo de configuración de la proxy caché activa se comunica con el submódulo de configuración de la proxy caché a ingresar de la otra proxy caché.

Estas configuraciones se realizan mediante el intercambio de mensajes entre ellas, por lo que se ha desarrollado un protocolo para realizar esta comunicación y configurar tanto a la que quiere ingresar como a las que ya se encuentran activas dentro del grupo.

5.2.1.1 Protocolo de Autoconfiguración entre Proxy Cachés

Este protocolo se encarga de la comunicación entre el submódulo de configuración de la proxy caché activa y el submódulo de configuración de la proxy caché a ingresar para realizar la configuración dinámica tanto de una proxy caché Squid que quiere ingresar al grupo como de las que ya pertenecen a él.

El submódulo de configuración de la proxy caché a ingresar se encarga del descubrimiento de las proxy cachés activas, el establecimiento de la conexión con una de ellas, la recepción del archivo de configuración, su autoconfiguración e informar de su configuración a las proxy cachés activas.

El submódulo de configuración de la proxy caché activa se encarga de estar escuchando si alguna nueva proxy caché quiere ingresar al grupo, responder a su llamado, establecer la conexión, enviar el archivo de configuración y reconfigurarse cuando esta nueva proxy caché ya esté configurada para añadirla al grupo.


51

Mediante este protocolo se realiza el intercambio de mensajes necesarios entre los dos submódulos para realizar la configuración dinámica entre las que ya se encuentran activas y la que quiere ingresar al grupo. El funcionamiento del protocolo se observa en la figura 5.3. Los recuadros con relleno tipo líneas

horizontales son para el submódulo de configuración de la proxy caché a

ingresar y los recuadros con relleno tipo cuadros son para el submódulo de configuración de la proxy caché activa.

Figura 5.3. Funcionamiento del protocolo entre las cachés

Los mensajes que se envían entre sí se observan en la tabla 5.1.

Tabla 5.1. Mensajes que realiza el protocolo para la configuración dinámica

Mensajes Descripción

DISCOVER Es enviado de la proxy caché que quiere ingresar al grupo de proxy cachés activas en modo broadcast, con su dirección IP.

ACK Es enviado de las proxy cachés activas, con su dirección IP hacia la proxy caché que quiere ingresar al grupo.

INFORM Es enviado por la proxy caché que quiere ingresar al grupo de proxy cachés activas, con su configuración.

ACK2 Es enviado de las proxy cachés activas hacia la proxy caché que quiere ingresar al grupo, con su dirección IP.

Estado inicial

Proxy cachés activas

ACK

Proxy caché seleccionada

Proxy caché configurada

INFORM

1

23

4

5

DISCOVER

Establecimiento de la conexión

Envío del archivo de configuración

ACK2 6


52

El trabajo de este protocolo inicia cuando una proxy caché quiere ingresar al grupo, por lo que envía un mensaje de tipo DISCOVER en forma de broadcast para detectar a las proxy cachés activas. En caso de que no existan proxy cachés activas, la que quiere ingresar configura al archivo de Squid llamado squid.conf con ayuda del archivo local configure.txt. El contenido del archivo configure.txt es como se muestra a continuación:

http_port 3128 http_port 8080 icp_port 3130

En caso de que se hayan detectado proxy cachés activas, éstas le contestan con un mensaje de tipo ACK, pero la proxy caché que quiere ingresar al grupo sólo toma a la primera que le contestó, y le pide los parámetros necesarios para configurarse, estos parámetros son enviados por medio de un archivo de configuración llamado config.txt. Los parámetros de auto-configuración son: el número del puerto por donde va a escuchar el Squid (http_port), el número del puerto por donde va a trabajar el protocolo ICP (icp_port) y las cachés que ya están activas en ese momento (cache_peer) con su tipo de membresía (sibling). El contenido del archivo config.txt es como se muestra a continuación:

http_port 3128 http_port 8080 icp_port 3130 cache_peer 192.168.150.4 sibling 3128 3130

La proxy caché que quiere ingresar con ayuda de este archivo recibido modifica al archivo de configuración de la caché Squid llamado squid.conf.

Cuando la proxy caché que quiere ingresar al grupo termina de configurarse, envía un mensaje de tipo INFORM a cada una de las que ya se encuentran activas para informarles acerca de su configuración. Posteriormente les envía un mensaje a cada una de ellas para indicarles que ya la pueden añadir


53

al grupo, y éstas le contestan con un mensaje de tipo ACK2 a esta nueva proxy caché, y la añaden al grupo.

El submódulo de configuración de la proxy caché a ingresar tiene una función llamada configurar(), la cual se encarga de realizar toda la parte de la modificación del archivo de Squid llamado squid.conf.

El submódulo de configuración de la proxy caché activa tiene una función llamada reconfigurar(), la cual se encarga de modificar el archivo de Squid llamado squid.conf para añadir al grupo a la nueva proxy caché que quiere ingresar.

5.2.2 Submódulo de Reconfiguración de Proxy Cachés Activas

Figura 5.4. Submódulo de Reconfiguración de Proxy Cachés Activas.

La reconfiguración se realiza cuando se le tiene que cambiar algunos parámetros o se le tiene que cambiar la jerarquía a una de las proxy cachés, por lo que el submódulo de reconfiguración de proxy cachés activas se encarga de realizar esta reconfiguración y de que esta nueva configuración sea detectada automáticamente por todas las demás que se encuentran activas en ese momento.

Este submódulo se encuentra subdividido en otros dos submódulos como se puede observar en la figura 5.4. El submódulo de reconfiguración de una proxy caché es utilizado por la que quiere cambiar su configuración y se comunica con el submódulo de detección de la reconfiguración de una proxy caché de las otras. Así mismo el submódulo de detección de la reconfiguración de una proxy caché se

Reconfiguración de proxy cachés activas

Reconfiguración de una

proxy caché

Detección de la reconfiguración

de una proxy caché

Reconfiguración de proxy cachés activas

Reconfiguración de una

proxy caché

Detección de la reconfiguración

de una proxy caché


54

comunica con el submódulo de reconfiguración de una proxy caché a reconfigurarse.

Cuando se efectúa la reconfiguración dinámica entre las que ya se encuentran activas y la que quiere reconfigurarse, se realiza el intercambio de mensajes necesarios entre los dos submódulos. El funcionamiento del protocolo

se observa en la figura 5.5. El recuadro con relleno tipo líneas horizontales es para el submódulo de reconfiguración de una proxy caché y el recuadro con

relleno tipo cuadros es para el submódulo de detección de la reconfiguración de una proxy caché.

Figura 5.5. Funcionamiento de la reconfiguración entre las proxy cachés

Los mensajes que se envían entre sí se observan en la tabla 5.2.

Tabla 5.2. Mensajes que realiza el protocolo para la reconfiguración dinámica


REINFORM Es enviado por una de las proxy cachés activas que quiere cambiar su configuración hacia las otras proxy cachés activas. Incluye su nueva configuración.

ACK2 Es enviado de las proxy cachés activas hacia la que quiere cambiar su configuración.

Cuando se quiere reconfigurar a una proxy caché activa, se ejecuta manualmente el submódulo de reconfiguración de una proxy caché y se le indica la nueva configuración de la proxy caché activa.

Proxy caché reconfigurada


REINFORM

ACK2

1

2


55

La sintaxis de la invocación de este submódulo es la siguiente:

./reconfig jerarquía opciones_de_configuración

Como podemos observar, primero va el nombre del programa, seguido con un espacio en blanco, posteriormente la jerarquía, seguido con un espacio en blanco, y posteriormente las opciones de configuración. Cada opción debe ir separada por un espacio en blanco. Para ejemplificar el uso de la invocación a este submódulo, se cambiará la configuración de una proxy caché que tiene una jerarquía de sibling por parent (es decir, pasamos a una proxy caché de la jerarquía de ser sibling, que se encuentra al mismo nivel, a la jerarquía de parent, que se encuentra a un nivel superior) y se le agregará el parámetro de proxy-only (que indica que los objetos obtenidos no serán almacenados localmente), por lo que la instrucción queda de la siguiente manera:

./reconfig parent proxy-only

Con estos nuevos parámetros se genera la nueva configuración y se reconfigura al archivo de config.txt y al archivo squid.conf y posteriormente se les informa de la nueva configuración a las proxy cachés activas a través de un mensaje de tipo REINFORM. Ellas, al obtener el mensaje, le contestan con un mensaje de tipo ACK2, para indicarle a la proxy caché reconfigurada que recibieron su mensaje, y posteriormente obtienen el contenido del mensaje para modificar sus archivos de config.txt y de squid.conf.

El submódulo de reconfiguración de una proxy caché tiene una función llamada reconfigurar(), la cual se encarga de modificar al archivo config.txt colocándole la nueva configuración de esta proxy caché. También tiene otra función llamada reconfigurar2(), la cual se encarga de modificar en su archivo squid.conf la jerarquía de las demás proxy cachés si es necesario.

El submódulo de detección de la reconfiguración de una proxy caché tiene una función llamada reconfigurar(), la cual se encarga de modificar el archivo de Squid llamado squid.conf para cambiar la configuración de la proxy caché que está informando de su nuevo estado.


56

5.2.3 Submódulo de Análisis de las Respuestas de las Proxy Cachés

Figura 5.6. Submódulo de Análisis de las Respuestas de las Proxy Cachés

El submódulo de análisis de las respuestas de las proxy cachés realiza una evaluación de las respuestas afirmativas (HITs) que se han tenido localmente por cada una de las proxy caché activas. En el caso de que el uso de alguna proxy caché externa no sea viable, ésta será dada de baja local y temporalmente. Una vez que pase este tiempo se vuelve a dar de alta.

Este submódulo se encuentra subdividido en otros tres submódulos como se puede observar en la figura 5.6. El submódulo de análisis del access.log se encarga del monitoreo de este archivo; el submódulo de desconfiguración temporal se encarga de desactivar temporalmente a la proxy caché, cuyo uso no sea viable; el submódulo de activación de la proxy caché, se encarga de mantener desactivada a la proxy caché cierto tiempo y activarla cuando haya pasado el tiempo que debe permanecer desactivada.

El submódulo de análisis del access.log sirve para realizar la evaluación de las respuestas afirmativas que se generan localmente por cada una de las proxy cachés, analizando el archivo bitácora que genera automáticamente Squid llamado access.log, en el cual se van registrando cada una de las peticiones que se le realizan a la proxy caché y qué respuesta se tuvo de esta petición. El

Análisis de las respuestasde las proxy caches

Análisis delAccess.log

Desconfiguracióntemporal

Activación de la Proxy caché

Análisis de las respuestasde las proxy caches

Análisis delAccess.log

Desconfiguracióntemporal

Activación de la Proxy caché


57

porcentaje que se consideró para indicar que el uso de una proxy caché es viable, es del 20% de acuerdo a [Baen97] [Baen97a] [Bari99] y [Davi99].

El archivo access.log tiene dos formatos diferentes para guardar estos registros, pero este módulo trabaja con el formato nativo de Squid [Wess01] [Gand00] [Barr02] [Cler02]. En el anexo A se muestra un análisis detallado del formato de estos registros y también se muestra un ejemplo de cómo es que están interactuando tres proxy cachés.

A través de estos registros se puede contar el número de respuestas afirmativas (HITs) que se producen localmente, así como los HITs obtenidos por cada una de las proxy cachés activas.

El archivo access.log se va monitoreando cada cierto tiempo, este tiempo va variando con respecto al número de peticiones que se vayan teniendo. Este submódulo lee el archivo de configuración llamado reconfig.txt, el cual tiene: el tiempo de espera en segundos para cada nuevo monitoreo del archivo access.log, el tiempo de espera en segundos en que se tiene desactivada a una proxy caché localmente y el porcentaje para realizar esta desactivación. El contenido del archivo reconfig.txt es el siguiente:

Tiempo entre monitoreos (segundos): 1800

Tiempo de desactivación de una proxy caché (segundos): 3600

Porcentaje para desactivar a una proxy caché: 20

Cuando el submódulo de análisis del access.log comienza a trabajar se obtienen los datos de configuración del archivo reconfig.txt y se espera dos veces el tiempo entre monitoreos debido a que existe una fase en todas las proxy cachés llamada fase de calentamiento. Posteriormente después de haber pasado este tiempo, se realiza el primer monitoreo del archivo access.log y se obtiene el número de peticiones. En los siguientes monitoreos sólo se toman en cuenta las nuevas peticiones y se obtiene el total de estas nuevas peticiones. Con el total se puede obtener el porcentaje de variación con respecto al monitoreo anterior y se verifica si el total de peticiones aumentó con respecto al anterior para disminuir el porcentaje obtenido al tiempo entre monitoreos, en caso contrario, se aumenta el porcentaje obtenido al tiempo entre monitoreos. Este cálculo de tiempo dinámico


58

se va a estar realizando cada vez que se realicen los monitoreos del archivo access.log con un tiempo mínimo de espera entre monitoreos de 60 segundos.

Por ejemplo: supongamos que tenemos un tiempo de espera de 1800 segundos. En el primer monitoreo, se tiene un total de 100 peticiones y en el segundo monitoreo se tiene un total de 120 nuevas peticiones, el porcentaje de la diferencia entre los dos totales de peticiones es un 20%; se puede observar que el total de peticiones en el segundo monitoreo aumentó con respecto al primer monitoreo, por lo que se le disminuye al tiempo (1800) un 20%, lo que da como resultado un nuevo tiempo de espera de 1440 segundos.

En caso de que en el primer monitoreo se tuviera un total de peticiones de 120 y en el segundo monitoreo se tuviera un total de peticiones de 100, nos da nuevamente como resultado un 20% de diferencia entre las peticiones, pero en esta ocasión el primer monitoreo es mayor que el segundo por lo que se le va a aumentar al tiempo (1800) un 20%, lo que da como resultado un nuevo tiempo de espera de 2160 segundos.

En cada monitoreo, el submódulo de desconfiguración temporal verifica que el porcentaje de respuestas afirmativas (HITs) que se tiene de cada proxy caché con respecto al número total de peticiones, sea igual o mayor al estipulado en el archivo de configuración reconfig.txt (que por defecto se tiene un 20%, pero este porcentaje puede ser variado). En caso de que el porcentaje de respuesta de alguna de ellas sea menor, ésta es desactivada localmente del archivo de squid.conf y se registra esta desactivación en el archivo llamado IPproxy.txt en el que se va registrando cuantas veces ha sido desconfigurada, ya que cada vez que sea desactivada, este tiempo se va aumentando.

El contenido del archivo IPproxy.txt es el siguiente:

192.168.150.4 2 0

192.168.150.5 2 0

El primer campo corresponde a la dirección IP de la proxy caché, el segundo campo corresponde al número de veces que se ha desactivado y el tercer campo indica cuantos ciclos de espera lleva desactivada.


59

Para poder obtener el número de respuestas afirmativas (HITs) que se tiene por cada proxy caché incluyendo a la local, se analizan solamente cuatro campos de cada uno de los registro del archivo access.log que genera Squid, los cuales son: el primero, tercero, cuarto y noveno campo que son respectivamente el tiempo de la petición, la dirección IP, el código de estado de la petición HTTP y el tipo de respuesta que se tuvo. Por lo que se han tomado en cuenta las siguientes características:

• Cuando es una dirección IP que no es la que se tiene localmente, es decir que la petición la ha hecho otra proxy caché (esto se observa en el tercer campo de los registros del archivo access.log), se verifica que en el noveno campo contenga PARENT, o SIBLING, o HIT, o CARP, pero no DIRECT para que sea considerado como un HIT.

• Cuando es la dirección IP local, es decir que la petición se ha realizado desde la proxy caché local (esto se observa en el tercer campo de los registros del archivo access.log), se verifica que en el cuarto campo se tenga HIT pero no NEGATIVE para que sea considerado como un HIT.

El submódulo de activación de la proxy caché, se encarga de estar monitoreando el archivo IPproxy.txt para reactivar a la proxy caché que se dio de baja temporalmente, evaluando a cada uno de los registros de este archivo y cuando el número de veces que se ha desactivado la proxy caché (número del segundo campo) y el número de ciclos de espera que lleva desactivada (número del tercer campo) sean iguales, esta proxy caché se vuelve a activar y el tercer campo vuelve a ser cero.

El submódulo de análisis del access.log tiene una función llamada nuevas_peticiones() que se encarga de obtener los nuevos registros que son generados en el archivo de access.log. También tiene otra función llamada analisis(), la cual se encarga de analizar y evaluar estos nuevos registros para detectar a las proxy cachés en las cuales su uso no sea viable de manera local.

El submódulo de desconfiguración temporal tiene una función llamada desactivar() que se encarga de desactivar a las proxy cachés de manera local en


60

las cuales su uso no sea viable y también se encarga de registrar a éstas en el archivo IPproxy.txt.

El submódulo de activación de la proxy caché tiene una función llamada activar() que se encarga de volver a activar a las proxy cachés de manera local cuando su tiempo de desactivación ya haya pasado.

5.2.4 Submódulo de Detección de las Proxy Cachés Caídas

Figura 5.7. Submódulo de Detección de las Proxy Cachés Caídas

El submódulo de detección de las proxy cachés caídas se encarga del monitoreo de las proxy cachés activas para detectar cuando alguna de ellas ya no está funcionando, y poder avisarle a las demás que aún no la han detectado como proxy caché caída, así como avisarle a los clientes (navegadores) que están trabajando con ésta para que realicen una nueva búsqueda de alguna otra proxy caché activa y trabajen con ella. Este mecanismo se realiza de manera transparente, tanto para las proxy cachés activas como para los clientes (navegadores).

Este submódulo se encuentra subdividido en otros tres submódulos, como se puede observar en la figura 5.7. El funcionamiento de este submódulo de detección de las proxy cachés caídas se observa en la figura 5.8. El recuadro con

relleno tipo líneas horizontales es para el submódulo de detección y baja

de las proxy cachés caídas, el recuadro con relleno tipo cuadros es para el

Detección de proxy cachés caídas

Detección y baja de las

proxy caché caídas

Respuesta dedetección

Baja de lasproxy caché caídas

Detección de proxy cachés caídas

Detección y baja de las

proxy caché caídas

Respuesta dedetección

Baja de lasproxy caché caídas


61

submódulo de respuesta de detección, y el recuadro con relleno tipo rombo es para el submódulo de baja de las proxy cachés caídas.

Figura 5.8. Funcionamiento del submódulo de detección de proxy cachés caídas

Durante la detección de proxy cachés caídas se produce un intercambio de mensajes, los cuales se pueden observar en la tabla 5.3.

Tabla 5.3. Intercambio de mensajes para detectar proxy cachés caídas


SURVIVE Es enviado por una de las proxy cachés activas hacia la proxy caché que se cree caída.

ACK Es enviado de la proxy caché que se cree caída hacia la proxy caché que la detectó como caída.

DEACTIVATE Es enviado por una de las proxy cachés activas hacia las demás para indicarles que una proxy caché ya no está funcionando. Se les envía la dirección IP de la proxy caché caída.

ACK2 Es enviado por la proxy caché activa hacia la proxy caché que le envió el mensaje de tipo DEACTIVATE.

El submódulo de detección y baja de las proxy cachés caídas que está realizando el monitoreo; se comunica con el submódulo de respuesta de detección de la proxy caché que se considera como caída y también se comunica con el

Proxy caché activa

Proxy caché caída

SURVIVE

ACK2


DEACTIVATE

1

3 ACK2

4


62

submódulo de baja de las proxy cachés caídas de las otras, y estos submódulos a su vez le contestan.

El submódulo de detección y baja de las proxy cachés caídas, para realizar el monitoreo de las proxy cachés activas, se apoya del archivo que genera automáticamente Squid llamado cache.log, en el cual se registra cuando una de ellas ya no está funcionando. Pero esto realmente no quiere decir que no este funcionando, existen ocasiones que por alguna razón no llega la respuesta y Squid la considera como caída. Squid cuando detecta alguna proxy caché caída genera un registro en este archivo, el cual queda como se muestra a continuación:

2004/07/08 21:22:34| Detected DEAD Sibling: 192.168.150.4/3128/3130

Este registro indica la fecha y hora en que se detectó que ya no estaba funcionando la proxy caché, así como la dirección IP de la proxy caché, en este caso la dirección IP es 192.168.150.4.

Cuando se detecta un registro de este tipo, se le envía un mensaje de tipo SURVIVE a la proxy caché que se detectó como caída para verificar si se encuentra activa, el cual es recibido por el submódulo de respuesta de detección de esta proxy caché. La proxy caché al recibir un mensaje de este tipo, verifica que Squid este funcionando y dependiendo si está funcionando o no le contesta a la proxy caché que le preguntó con un mensaje de tipo ACK. En caso de que la encuentre activa, el registro es ignorado, pero si la proxy caché está caída se da de baja localmente en el archivo config.txt, en el archivo IPproxy.txt, y en el archivo squid.conf, eliminando el registro en donde aparece la configuración de la proxy caché en estos archivos y se reinicia a Squid para que tome en cuenta los cambios.

Posteriormente se les avisa a las demás proxy cachés activas para que la den de baja mediante un mensaje de tipo DEACTIVATE junto con la dirección IP de la proxy caché caída, el cual es recibido por el submódulo de baja de las proxy cachés caídas. La proxy caché activa al detectar el mensaje de tipo DEACTIVATE, la da de baja localmente en el archivo config.txt, en el archivo IPproxy.txt, y en el archivo squid.conf, eliminando el registro en donde aparece la configuración de la


63

proxy caché en estos archivos y se reinicia a Squid para que tome en cuenta los cambios y le envía un mensaje de confirmación de tipo ACK2 al submódulo de detección y baja de las proxy cachés caídas.

El submódulo de detección y baja de las proxy cachés caídas cuando detecta que realmente la proxy caché está caída, les avisa a los clientes mediante un mensaje de tipo broadcast para que los clientes que estaban trabajando con ella la sustituyan por otra.

El submódulo de detección y baja de las proxy cachés caídas tienen una función llamada detectar() que se encarga del monitoreo del archivo cache.log y de detectar a las proxy cachés que se encuentran caídas mediante el paso de mensajes. También tiene otra función llamada desactivar() que se encarga de dar de baja a la proxy caché que se detectó que realmente estaba caída.

El submódulo de respuesta de detección tiene una función llamada detectar() que se encarga de verificar si el programa Squid está trabajando y posteriormente dar respuesta del estado en que se encuentra.

El submódulo de baja de las proxy cachés caídas, tiene una función llamada desactivar() que se encarga de dar de baja a la proxy caché que se detectó que realmente estaba caída.

5.3 CONFIGURACIÓN DINÁMICA DEL NAVEGADOR (CLIENTE)

El módulo de configuración dinámica del navegador (cliente) se encarga de realizar la detección de las proxy cachés activas y de la autoconfiguración del navegador Internet Explorer. La configuración manual del navegador Internet Explorer se muestra en el apéndice B.

Configuración del

navegador

Respuesta de configuración dinámica del

cliente

Configuración dinámica del cliente

API jRegistryKeyRegistro de WindowsInternet Explorer

Configuración dinámica del navegador del cliente

Configuración del navegador

Respuesta de configuración dinámica del

cliente

Configuración dinámica del cliente

API jRegistryKeyRegistro de WindowsInternet Explorer

Configuración dinámica del navegador del cliente


64

Figura 5.9. Módulo de configuración dinámica del navegador del cliente.

El módulo de configuración dinámica del navegador del cliente como se puede observar en la figura 5.9, está constituído por el navegador Internet Explorer, el Registro de Windows, la API jRegistryKey y por el módulo de configuración dinámica del cliente; que a su vez se divide en dos submódulos.

El submódulo de configuración del navegador se encuentra del lado del cliente y se encarga de realizar el descubrimiento de las proxy cachés activas y de configurar al navegador. El submódulo de respuesta de configuración dinámica del cliente se encuentra en el lado de las proxy cachés activas y se encarga de responder cuando el cliente está localizando a las proxy cachés activas.

En la arquitectura de este módulo para indicar las partes que solamente se utilizaron y que no fueron desarrolladas se utiliza un recuadro con relleno tipo

rombo .

Al hacer el cambio en el navegador Internet Explorer para que trabaje con alguna proxy caché, el registro de Windows HKEY_CURRENT_USER\Software\ MicrosoftWindows\CurrentVersion\Internet Settings se altera. Al habilitar la casilla de verificación se habilita la opción de ProxyEnable como 0x00000001 (1), ya que anteriormente se tenía el valor de 0x00000000 (0). Al colocar la dirección IP y el puerto, se crea la opción de ProxyServer y su contenido para ejemplificar en este caso, es el 192.168.150.5:8080 (DireccionIP:Puerto), como se puede observar en la figura 5.10.

Cuando el submódulo de configuración del navegador inicia, manda un mensaje en forma de broadcast para localizar a las proxy cachés activas. El mensaje que envía este submódulo es obtenido por el submódulo de respuesta de configuración dinámica del cliente de cada una de las proxy cachés activas y le contestan con un mensaje que contiene su dirección IP. El cliente al recibir el


65

primer mensaje de contestación lo toma e ignora a los demás mensajes y configura al navegador Internet Explorer.

En caso de que no conteste ninguna proxy caché el navegador Internet Explorer se configura para salir directo.

Figura 5.10. Ventana del Editor del Registro de Windows

Para realizar la configuración del navegador ya sea para que salga directo o para que trabaje con una proxy caché activa, se utiliza un API de java llamada jRegistryKey [Osdn04] que se encarga de modificar el registro de Windows, ya que la configuración del navegador afecta al registro.

Por otro lado, el submódulo de configuración del navegador también se encarga de estar monitoreando por si la proxy caché con la que está trabajando deja de funcionar. En caso de que éste detecte que la proxy caché con la que estaba trabajando deja de funcionar, detecta de manera automática a otra proxy caché activa y se configura nuevamente para trabajar con ella, si es que existe.

El submódulo de configuración del navegador tiene una clase llamada Activa que se encarga de modificar el registro de Windows para realizar la configuración del navegador Internet Explorer. También tiene otra clase llamada


66

Desactiva que se encarga de configurar al navegador Internet Explorer para que salga directamente hacia Internet sin necesidad de utilizar alguna proxy caché.

Capítulo 6. Pruebas

67

CAPÍTULO 6

PRUEBAS

6.1 PLAN DE PRUEBAS

En esta sección se describen los casos de prueba que se realizaron para el prototipo de configuración dinámica de proxy cachés y el prototipo de configuración dinámica del navegador. Para cada caso de prueba se presenta su objetivo, el procedimiento que se siguió para la prueba y los resultados obtenidos.

Estas pruebas se realizaron con tres computadoras, dos de ellas fueron configuradas como proxy cachés y una de ellas como cliente.


68

Una de las computadoras que funcionó como proxy cachés, se le asignó la dirección IP 192.168.150.4. Esta computadora cuenta con las siguientes características: procesador AMD Athlon XP a 1.24 GHz, un disco duro de 80 GB y una memoria RAM de 256 MB.

La otra computadora que funcionó como proxy cachés, se le asignó la dirección IP 192.168.150.5. Esta computadora cuenta con las siguientes características: procesador Intel Pentium IV a 2.0 GHz, un disco duro de 40 GB y una memoria de RAM de 256 MB.

A estas dos computadoras se les instaló el sistema operativo Red Hat Linux versión 9, y la versión 2.5.STABLE1 del software libre Squid.

La tercera computadora que funcionó como cliente, se le asignó la dirección IP 192.168.150.3. Esta computadora cuenta con las siguientes características: procesador Intel Pentium IV a 2.5 GHz, un disco duro de 40 GB y una memoria de RAM de 256 MB. A ésta última se le instaló el sistema operativo Windows XP Profesional versión 2002, el jdsdk1.4.0, y la API jRegistryKey.

Para que el sistema de configuración dinámica de proxy cachés funcione correctamente, el software de Squid para Linux debe de estar instalado en la ruta /usr/local/squid.

Es necesario que el archivo de configuración de Squid llamado squid.conf se encuentre en la ruta /usr/local/squid/etc. Y los archivos logs que genera automáticamente Squid se encuentren en la ruta /usr/local/squid/var/logs.

La herramienta desarrollada debe de colocarse dentro de Linux en la ruta /home/proyecto.

6.1.1 Caso 1

Objetivo

Detectar las proxy cachés activas que se encuentran dentro de una intranet.


69

Procedimiento

La proxy caché que quiere ingresar al grupo envía un mensaje de tipo DISCOVER en forma de broadcast con su dirección IP. Coloca un socket a escuchar con un timeout de tres segundos, esperando obtener como respuesta un mensaje de tipo ACK. Si pasan los tres segundos y no se recibe ningún mensaje de respuesta por parte de las proxy cachés activas, se vuelve a enviar un mensaje de tipo DISCOVER y posteriormente se vuelve a colocar el socket en espera de recibir un mensaje de tipo ACK con un timeout de tres segundos.

En el caso de que existan proxy cachés activas, las cuales siempre están escuchando, al recibir un mensaje, verifican qué tipo de mensaje es; en este caso es un mensaje de tipo DISCOVER, por lo que cada una de las proxy cachés activas envían un mensaje de tipo ACK a la proxy caché que quiere ingresar, cuyo contenido es su dirección IP.

Resultado

Para este caso de prueba se realizaron dos evaluaciones, la primera fue con proxy cachés activas, por lo que se detectó a una de ellas. La figura 6.1 muestra la pantalla de detección de una proxy caché.

Figura 6.1. Detección de una proxy caché activa

La figura 6.2 muestra la pantalla que se observa cuando la proxy caché activa recibe un mensaje de tipo DISCOVER.


70

Figura 6.2. Recepción de un mensaje de tipo DISCOVER

Para la segunda evaluación no se tienen proxy cachés activas, así es que no detecta nada. La figura 6.3 muestra la pantalla cuando esto ocurre.

Figura 6.3. No existen proxy cachés activas

6.1.2 Caso 2

Objetivo

Configurar la proxy caché que quiere ingresar al grupo cuando no existen proxy cachés activas dentro de una intranet.

Procedimiento

La proxy caché que quiere ingresar, accede al archivo local de configuración llamado configure.txt, que tiene los parámetros de configuración necesarios para configurar a la nueva proxy caché, los cuales son: los puertos de escucha para Squid (http_port) y el puerto del protocolo ICP (icp_port).


71

Esta proxy caché que quiere ingresar, abre el archivo de configuración de Squid llamado squid.conf, y localiza en dónde se colocan los puertos de escucha de Squid y en dónde se coloca el puerto del protocolo ICP. Posteriormente, coloca el contenido del archivo configure.txt en el lugar adecuado del archivo squid.conf. Se modifica en este mismo archivo el TAG: emulate_httpd_log con la opción emulate_httpd_log off para trabajar con el formato nativo de Squid y configura las listas de control de acceso para que otras proxy cachés que se encuentran activadas con la misma máscara de red puedan acceder al contenido de esta proxy caché.

Al archivo de configuración configure.txt, le añade una línea con la configuración de esta nueva proxy caché en donde la incluye en la lista de proxy cachés activas. Esta línea de configuración se crea con la dirección IP de la proxy caché que quiere ingresar, con una jerarquía, con el número de puerto de Squid y con el número de puerto de ICP. La nueva proxy caché se configura por defecto con la jerarquía de sibling (proxy cachés hermanas que se encuentran al mismo nivel).

Ya que se modificaron los dos archivos de configuración, tanto el configure.txt como el squid.conf, se inicia a Squid y se crea el archivo de configuración config.txt. El contenido de este nuevo archivo es el mismo que el del archivo configure.txt.

Resultado

La proxy caché con dirección IP 192.168.150.5, al quedar configurada muestra su estado. La figura 6.4 muestra la pantalla cuando esto ocurre.

Figura 6.4. Autoconfiguración cuando no existen proxy cachés activas


72

El archivo de configuración config.txt queda de la siguiente manera:

http_port 3128 http_port 8080

icp_port 3130

cache_peer 192.168.150.5 sibling 3128 3130

Las secciones que se modificaron en el archivo de squid.conf quedaron de

la siguiente manera: # TAG: http_port ... http_port 3128 http_port 8080 # TAG: icp_port ... icp_port 3130 # TAG: acl ... acl lared src 192.168.0.0/255.255.0.0 ... http_access allow lared # TAG: emulate_httpd_log on|off ... emulate_httpd_log off 6.1.3 Caso 3

Objetivo

Establecer la conexión entre la proxy caché que quiere ingresar al grupo y una de las proxy cachés activas. Una vez cumplido lo anterior, enviar el archivo de configuración config.txt desde la proxy caché activa hacia la proxy caché que quiere ingresar al grupo dentro de una intranet.


73

Procedimiento

La proxy caché que quiere ingresar al grupo establece la conexión con una proxy caché activa.

En caso de que en el primer intento de establecer la conexión sea fallida, se espera un tiempo y vuelve a intentar establecer nuevamente la conexión; y si en esta segunda ocasión nuevamente es fallida, se vuelve a mandar un mensaje de tipo DISCOVER y se coloca el socket a escuchar con un timeout de tres segundos. Si después del timeout no se recibe ningún mensaje de tipo ACK, se vuelve a mandar un mensaje de tipo DISCOVER y nuevamente se coloca el socket a escuchar con un timeout de tres segundos.

Si se recibe como respuesta un mensaje de tipo ACK se establece una conexión con esta proxy caché activa y ésta le envía el archivo de configuración config.txt a la que quiere ingresar al grupo.

En caso de que exista algún error en la transferencia del archivo se intenta localizar a otra proxy caché para la transferencia del archivo, realizando lo mismo antes descrito en el caso 1, pero si no existe alguna otra proxy caché se realiza lo antes descrito en el caso 2.

Resultado

La proxy caché activa envía el archivo de configuración config.txt a la proxy

caché que quiere ingresar. La figura 6.5 muestra la pantalla que se observa en la

proxy caché activa al terminar de enviar el archivo.

Figura 6.5. Envío del archivo de configuración


74

6.1.4 Caso 4

Objetivo

Configurar la proxy caché que quiere ingresar al grupo con ayuda del archivo de configuración config.txt.

Procedimiento

La proxy caché que quiere ingresar al grupo accede al archivo de configuración llamado config.txt, que tiene los parámetros de configuración necesarios para configurarse. Los parámetros son: los puertos de escucha para Squid (http_port), el puerto del protocolo ICP (icp_port) y la lista de las proxy cachés activas (cache_peer).

Ésta abre el archivo de configuración de Squid llamado squid.conf, y localiza en dónde se modifican los puertos de escucha de Squid, en dónde se cambia el puerto del protocolo ICP y dónde se coloca la lista de las proxy cachés activas; enseguida, coloca el contenido del archivo config.txt en el lugar adecuado del archivo squid.conf. Modifica en este mismo archivo el TAG: emulate_httpd_log con la opción emulate_httpd_log off para trabajar con el formato nativo de Squid y configura las listas de control de acceso para que otras proxy cachés que se encuentran activadas con la misma máscara de red puedan acceder al contenido de esta proxy caché.

Al archivo de configuración config.txt se le añade una línea con la configuración de esta nueva proxy caché en donde la incluye en la lista de proxy cachés activas. Esta línea de configuración se crea con su dirección IP con una jerarquía, con el número de puerto de Squid y con el número de puerto de ICP. La nueva proxy caché se configura por defecto con la jerarquía de sibling.

Ya que se modificaron los dos archivos de configuración, tanto el config.txt como el squid.conf, se inicia a Squid.


75

Resultado

La proxy caché con dirección IP 192.168.150.5, al quedar configurada muestra su estado. La figura 6.6 muestra la pantalla cuando esto ocurre.

Figura 6.6. Autoconfiguración cuando existen proxy cachés activas

Y el archivo de configuración config.txt quedó de la siguiente manera:


icp_port 3130 cache_peer 192.168.150.4 sibling 3128 3130 cache_peer 192.168.150.5 sibling 3128 3130

Las secciones que se modificaron en el archivo de squid.conf quedaron de

la siguiente manera: # TAG: http_port ... http_port 3128 http_port 8080 # TAG: icp_port ... icp_port 3130 # TAG: cache_peer ... cache_peer 192.168.150.4 sibling 3128 3130 # TAG: acl


76

... acl lared src 192.168.0.0/255.255.0.0 ... http_access allow lared # TAG: emulate_httpd_log on|off ... emulate_httpd_log off

6.1.5 Caso 5

Objetivo

Informar a las proxy cachés activas que la proxy caché que quiere ingresar al grupo ya está configurada para que la reconozcan como proxy caché activa.

Procedimiento

La proxy caché que quiere ingresar al grupo manda un mensaje de tipo INFORM junto con su configuración hacia cada una de las proxy cachés activas y coloca el socket a escuchar con un timeout de tres segundos, esperando obtener como respuesta un mensaje de tipo ACK2. Si pasan los tres segundos y no se recibe ningún mensaje de tipo ACK2 como respuesta, se vuelve a enviar un mensaje de tipo INFORM y posteriormente se vuelve a colocar el socket en espera de recibir un mensaje de tipo ACK2 con un timeout de tres segundos.

Por el lado de las proxy cachés activas, al recibir un mensaje de tipo INFORM, envían un mensaje de tipo ACK2 de confirmación y añaden el contenido del mensaje en el archivo squid.conf y en el archivo de config.txt.

Resultado

La proxy caché activa recibe un mensaje de tipo INFORM, añade a la proxy caché que quiere ingresar y muestra el estado de esta proxy caché. La figura 6.7 muestra la pantalla cuando esto ocurre.


77

Figura 6.7. Recepción de un mensaje de tipo INFORM

Y el archivo de configuración config.txt de la proxy caché activa quedó de la siguiente manera:


icp_port 3130

cache_peer 192.168.150.4 sibling 3128 3130 cache_peer 192.168.150.5 sibling 3128 3130

La sección del archivo squid.conf en donde se coloca la configuración de

las proxy cachés con las que se está trabajando quedó de la siguiente manera: # TAG: cache_peer ... cache_peer 192.168.150.4 sibling 3128 3130

6.1.6 Caso 6

Objetivo

Reconfigurar a una proxy caché que ya se encuentra dentro del grupo de proxy cachés cooperativas y que las demás proxy cachés activas detecten su nueva configuración.


78

Procedimiento

Ejecutar el programa manualmente en la terminal (línea de comandos). La sintaxis de la invocación de este programa es la siguiente:

./reconfig jerarquía opciones_de_configuración

Cada una de estas opciones debe ir separada por un espacio en blanco.

Se obtienen estos parámetros y genera la nueva línea de configuración, la cual está formada por la dirección IP de la proxy caché que quiere reconfigurarse, la jerarquía que va a tener, el número de puerto de Squid, el número de puerto de ICP y las opciones de configuración si es que existen.

Una vez concluido lo anterior se accede al archivo de config.txt, se localiza la línea donde se encuentra configurada esta proxy caché y se cambia esta línea por la nueva. En caso de que se haya cambiado de jerarquía se modifica el archivo de configuración squid.conf. Si se cambio de sibling a parent, todas las proxy cachés configuradas como sibling, son dadas de baja, y las proxy cachés que se encuentran configuradas como parent, se les cambia la configuración a sibling, ya que la proxy caché que se está reconfigurando está subiendo de jerarquía. Posteriormente se reinicia a Squid, para que reconozca la nueva configuración.

En el caso de que haya cambiado de parent a sibling, las proxy cachés que se tienen configuradas como sibling se cambian a parent y las proxy cachés que están desactivadas, primero se verifica que sean proxy cachés activas y si lo son, se reactivan.

Ya que se terminó de reconfigurar a la proxy caché localmente, se envía un mensaje de tipo REINFORM con la línea de su nueva configuración a cada una de las proxy cachés activas esperando obtener como respuesta un mensaje de tipo ACK2. Si pasan tres segundos y no se recibe ningún mensaje de tipo ACK2 como respuesta, se vuelve a enviar el mensaje de tipo REINFORM esperando obtener como respuesta nuevamente un mensaje de tipo ACK2.


79

Las otras proxy cachés activas al recibir un mensaje de tipo REINFORM envían un mensaje de tipo ACK2 de confirmación y posteriormente obtienen el contenido del mensaje, el cual es una línea que tienen que cambiar tanto en el archivo de configuración config.txt como en el archivo de configuración de Squid llamado squid.conf.

Para cambiar la configuración de la proxy caché que se quiere reconfigurar en el archivo de squid.conf, primero se verifica el tipo de jerarquía que tiene localmente esa proxy caché activa, si es una proxy caché configurada como sibling, se coloca la configuración que viene en el mensaje. En caso de que esa proxy caché activa esté configurada como parent, se verifica la jerarquía de la proxy caché que se quiere reconfigurar, si es una proxy caché con jerarquía de sibling, se coloca la configuración en el archivo de squid.conf pero se desactiva, ya que esta proxy caché tiene un nivel más en la jerarquía que la proxy caché que se quiere reconfigurar. En el caso de que la proxy caché que se quiere reconfigurar tenga una jerarquía de parent, se le cambia la jerarquía a sibling, debido a que esta se encuentra en el mismo nivel. Ya que se modificó el archivo de squid.conf se reinicia a Squid para que reconozca la nueva configuración.

Resultado

Se reconfiguró a la proxy caché con dirección IP 192.168.150.5 que tenía una jerarquía de sibling cambiándosela por parent ejecutando la siguiente instrucción:

./reconfig parent

La figura 6.8 muestra la pantalla de la ejecución de lo descrito anteriormente:

Figura 6.8. Reconfiguración de una proxy caché activa


80

El archivo de configuración config.txt en todas las proxy cachés activas quedó de la siguiente forma:


icp_port 3130

cache_peer 192.168.150.4 parent 3128 3130 cache_peer 192.168.150.5 sibling 3128 3130

En el archivo de Squid de la proxy caché con dirección IP 192.168.150.5 desactiva a la proxy caché con dirección IP 192.168.150.4, ya que está a un nivel inferior en la jerarquía y quedó de la siguiente manera:

# TAG: cache_peer ... #cache_peer 192.168.150.4 sibling 3128 3130

El archivo de Squid de la proxy caché con dirección IP 192.168.150.4 quedó de la siguiente manera:

# TAG: cache_peer ... cache_peer 192.168.150.5 parent 3128 3130

La figura 6.9 muestra la pantalla cuando las proxy cachés activas reciben un mensaje de tipo REINFORM con la nueva configuración de la proxy caché con dirección IP 192.168.150.5.

Figura 6.9. Recepción de un mensaje de tipo REINFORM


81

6.1.7 Caso 7

Objetivo

Detectar y dar de baja a las proxy cachés caídas que se encuentran dentro de una intranet.

Procedimiento

Monitorear el archivo que genera Squid automáticamente llamado cache.log y detectar los registros que tienen el siguiente formato:

2004/07/08 21:22:34| Detected DEAD Sibling: 192.168.150.4/3128/3130

Obtiene del registro la dirección IP de esta proxy caché para enviarle un mensaje de tipo SURVIVE esperando obtener como respuesta un mensaje de tipo ACK. Si después de los cinco segundos no se obtiene ningún mensaje de respuesta se vuelve a enviar el mensaje de tipo SURVIVE y si después de estos cinco segundos no se obtiene ningún mensaje de respuesta, la proxy caché es tomada como proxy caché caída.

La proxy caché que se está considerando como proxy caché caída, al recibir un mensaje de tipo SURVIVE, verifica si el programa de Squid se encuentra funcionando, en caso de que sí esté funcionando se envía un mensaje de tipo ACK el cual contiene la palabra YES, en caso contrario el contenido del mensaje será la palabra NO.

La proxy caché que está realizando el monitoreo al recibir el mensaje de confirmación de tipo ACK, obtiene el contenido y si es un YES el registro que se obtuvo del archivo cache.log es ignorado. En caso de que el contenido del mensaje fuera un NO, se considera efectivamente que la proxy caché está caída por lo que se borra de los archivos config.txt, squid.conf y IPproxy.txt el registro en donde aparece la configuración de esta proxy caché caída. Una vez realizado lo anterior, se reinicia a Squid para que tome en cuenta los cambios.


82

Enseguida se le envía a cada proxy caché un mensaje de tipo DEACTIVATE junto con la dirección IP de la proxy caché caída y espera recibir un mensaje de contestación de tipo ACK2, si después de tres segundos no se recibe el mensaje, se vuelve a enviar el mensaje de tipo DEACTIVATE y se vuelve a esperar la contestación con un mensaje de tipo ACK2.

La proxy caché activa al recibir un mensaje de tipo DEACTIVATE le contesta a la proxy caché que le está informando con un mensaje de tipo ACK2. Enseguida borra el registro en donde aparece la configuración de la proxy caché caída de los archivos config.txt, squid.conf y IPproxy.txt, enseguida se reinicia a Squid para que tome en cuenta los cambios.

La proxy caché que está informando de la proxy caché caída envía un mensaje en forma de broadcast a todos los clientes. El contenido del mensaje para los clientes es la dirección IP de la proxy caché caída.

Resultado

Se detectó a la proxy caché con dirección IP 192.168.150.4 como caída por lo que se eliminaron los registros de ésta en el archivo squid.conf, config.txt e IPproxy.txt.

La figura 6.10 muestra la pantalla que indica que se ha detectado una proxy caché caída.

Figura 6.10. Detección de una proxy caché caída


83

6.1.8 Caso 8

Objetivo

Monitorear el archivo que genera automáticamente Squid llamado access.log, para desactivar local y temporalmente a una proxy caché si su uso no es viable.

Procedimiento

Acceder al archivo de configuración llamado reconfig.txt, para obtener el tiempo de espera entre monitoreos y el porcentaje para realizar la desactivación de una proxy caché. El contenido del archivo reconfig.txt es el siguiente:

Tiempo entre monitoreos (segundos): 1800


Porcentaje para desactivar a una proxy caché: 20

A continuación se espera dos veces el tiempo entre monitoreos debido a que existe una fase en todas las proxy cachés llamada fase de calentamiento.

Una vez concluido lo anterior, se comienzan a realizar los monitoreos del archivo access.log cada cierto tiempo y se verifica localmente que el porcentaje de respuestas afirmativas (HITs) que se tiene de cada proxy caché con respecto al número total de peticiones, sea igual o mayor al estipulado en el archivo de configuración reconfig.txt (que por defecto es de un 20%). En caso de que el porcentaje de respuesta de alguna de las proxy cachés sea menor, ésta es desactivada localmente del archivo de squid.conf debido a que su uso no es viable, y se reinicia a Squid para que tome en cuenta los cambios. Una vez concluido lo anterior se coloca o se modifica el registro en el archivo llamado IPproxy.txt.

Resultado

La proxy caché con dirección IP 192.168.150.4 realizó el monitoreo del archivo access.log y detectó que el uso de la proxy caché con dirección IP


84

192.168.150.5 no era viable, por lo que se desactivó en el archivo de Squid, el cual quedó de la siguiente manera:

# TAG: cache_peer ... #cache_peer 192.168.150.5 sibling 3128 3130

El archivo IPproxy.txt en la proxy caché local quedó de la siguiente manera:

192.168.150.5 1 0

6.1.9 Caso 9

Objetivo

Dar de alta a las proxy cachés que fueron dadas de baja temporalmente de manera local cuando su uso no fue viable.

Procedimiento

Acceder al archivo llamado reconfig.txt, para obtener el tiempo de desactivación de una proxy caché. Parte del contenido del archivo reconfig.txt es el siguiente:


A continuación se espera una vez el tiempo de desactivación. En seguida se accede al archivo IPproxy.txt. El contenido de este archivo es el siguiente:

192.168.150.5 1 0

Se modifica el tercer campo de cada registro del archivo sumándole uno a la cantidad que se tenga.

En caso de que el número del segundo campo y el número del tercer campo de un registro sean iguales, se accede al archivo de configuración de Squid llamado squid.conf para localizar el registro en donde se encuentra desconfigurada a esta proxy caché y nuevamente se activa. Ya que se dieron de alta a las proxy caché se reinicia a Squid para que tome en cuenta los cambios.


85

Se vuelve a esperar el tiempo de desactivación y se vuelve a acceder al archivo IPproxy.txt para realizar la modificación y evaluación de los registros del archivo.

Resultado

EL archivo IPproxy.txt al acceder a él y realizar la modificación quedó de la siguiente manera:

192.168.150.5 1 1

Como el número del segundo y del tercer campo del registro son iguales, se reactivó a la proxy caché en el archivo de squid.conf y quedó en la parte donde están configuradas las proxy cachés de la siguiente manera:

# TAG: cache_peer ... cache_peer 192.168.150.5 sibling 3128 3130

En el archivo IPproxy.txt el tercer campo se colocó a cero y queda de la siguiente manera:

192.168.150.5 1 0

6.1.10 Caso 10

Objetivo

Configurar al navegador Internet Explorer que se encuentra dentro de una intranet.

Procedimiento

Iniciar el programa en la máquina del cliente que se encuentra en una intranet, para que envíe un mensaje en forma de broadcast y localice a las proxy cachés activas. Se espera recibir un mensaje que contenga la dirección IP de una de ellas. En caso de que pasen tres segundos y no se reciba ningún mensaje de


86

respuesta, se vuelve a enviar el mensaje de localización de las proxy cachés activas.

Si no se recibe ningún mensaje de contestación después de que pasen tres segundos se configura al navegador para que salga directamente.

En caso de que existan proxy cachés activas, al recibir el mensaje que proviene del cliente, le mandan un mensaje de contestación con su dirección IP.

El cliente al recibir el primer mensaje de contestación toma el contenido y le concatena al puerto que por defecto va a ser el puerto 8080, generando una cadena como DireccionIP:Puerto, y en seguida se configura al navegador para que trabaje con esta proxy caché activa.

Resultado

Se realizaron dos pruebas, una con proxy cachés activas y otra sin ellas.

La figura 6.11 muestra la pantalla que se observa cuando la aplicación esta buscando a las proxy cachés activas. Esta pantalla se observa para las dos pruebas.

Figura 6.11. Búsqueda de proxy cachés activas

La figura 6.12 muestra la pantalla que se observa en el caso de que no existan proxy cachés activas.


87

Figura 6.12. No existen proxy cachés activas

La figura 6.13 muestra la pantalla que se observa si se encuentra alguna proxy caché activa, la cual indica la dirección IP de la proxy caché con la que se está trabajando:

Figura 6.13. Cliente configurado con una proxy caché activa.

6.1.11 Caso 11

Objetivo

Reconfigurar al navegador Internet Explorer cuando se detecte que la proxy caché con la que se estaba trabajando ya no está funcionando.

Procedimiento

Colocar un socket de recepción de mensajes que le indica si alguna proxy caché ya no está funcionando.


88

Al recibir un mensaje se verifica si es la dirección IP de la proxy caché con la que se está trabajando, en caso de que así sea se realiza nuevamente la localización de las proxy cachés activas. En caso contrario no se hace nada y se vuelve a colocar el socket en espera de mensajes que indiquen que alguna proxy caché ya no está funcionando.

Resultado

El cliente recibió un mensaje con la dirección IP de una proxy caché caída y era con la que se estaba trabajando, por lo que se buscó a una nueva proxy caché. La proxy caché que respondió al llamado fue la que tenía la dirección IP 192.168.150.4. La figura 6.14 muestra la pantalla con la nueva configuración del navegador.

Figura 6.14. Cliente configurado con otra proxy caché activa.

6.1.12 Caso 12

Objetivo

Localizar manualmente a una proxy caché activa cuando el cliente lo indique.

Procedimiento

Hacer clic en el botón Buscar servidor. La aplicación realiza lo descrito en el caso 10.


89

En caso de que sólo exista la proxy caché activa con la que se está trabajando, volverá a localizarla, o puede suceder que esa misma proxy caché sea la primera que le conteste, por lo que se puede volver a pulsar el botón cada vez que se requiera.

Resultado

Cuando se pulsó el botón de Buscar Servidor, se encontró y configuró el navegador para trabajar con la proxy caché con dirección IP 192.168.150.5. La figura 6.15 muestra la pantalla con la nueva configuración del navegador.

Figura 6.15. Cliente configurado con una de las proxy caché activa.

6.1.13 Caso 13

Objetivo

Realizar una comparación en la tasa de aciertos (HITs) y el tiempo de respuesta de proxy cachés configuradas individualmente, proxy cachés configuradas en un grupo de proxy cachés cooperativas en forma estática y proxy cachés configuradas en un grupo de proxy cachés cooperativas en forma dinámica.

Procedimiento

Se realizó una simulación con tres proxy cachés organizadas en forma de malla, las cuales se encontraban dentro una intranet, la que se esquematiza en la figura 6.16.


90

Figura 6.16. Estructura de la intranet del Cenidet

Las proxy cachés se encuentran en una subred de direcciones privadas, y se encuentran interconectadas a un hub, que a su vez se conecta a un switch. Éste último se conecta a un transceiver para conectar fibra óptica, y en el otro extremo de la fibra óptica nuevamente se le conecta un transceiver para volver a pasar las señales al switch y finalmente éste se conecta a un router de Telmex, el cual realiza la conexión a Internet con una velocidad de 2 Mbps.

Se utilizaron los ficheros logs de la bitácora registrados (trazas) en las cachés que controla el Centro de Supercomputación de Cataluña (CESCA). Se presentan los resultados basados en las trazas que nos ha proporcionado el CESCA, ya que éstas muestran cargas de trabajo reales, que asumimos que éstas tienen una distribución autosimilaridad (self similarity), basado en los estudios realizados en el comportamiento del tráfico en la Web descritos en [Crov97][Lela94], lo que hace que los resultados sean más confiables. Las características de las trazas utilizadas se presentan en la tabla 6.1.

HUB

Switch TransceiverRouter

de Telmex

InternetTransceiver

HUB

Transceiver

Switch

HUB

Servidor mail 192.168.1.1

Servidor Web 192.168.1.4

Servidor DNS 1 192.168.1.7

Servidor DNS 2 192.168.1.8

Gateway 192.168.100.10

Direcciones Privadas 192.168.0.0

Direcciones públicas 148.208.209.[20-40]

HUB

Firewall 148.208.209.4

Servidor DNS 1 Zeus

148.208.209.2

Servidor DNS 2 Apolo

148.208.209.3

Gateway 148.208.209.254

Proxy Caché 1 192.168.150.3

Proxy Caché 2 192.168.150.4

Proxy Caché 3 192.168.150.5

10 M

bps

10/1

00

Mbp

s

100

Mbp

s

10 Gbps

100

Mbp

s

10/100 Mbps 10/100 Mbps

10/100 Mbps

10/100Mbps

10/100 Mbps

10/100 Mbps

2Mbps

200.79.11.108


91

Tabla 6.1. Características de las trazas utilizadas en la simulación

Número de peticiones 3,089,592 Número de objetos 212,352 Número de clientes aproximado 11,765 Promedio de peticiones por segundo 21 Bytes transferidos 30GB Duración 2 días

El número de clientes se presenta como un valor aproximado debido a que muchos de los IPs que fueron registrados en la bitácora del CESCA, pertenecen a máquinas que concentran a más de un cliente, lo que hace imposible saberlo con exactitud, lo que quiere decir que el número de clientes puede ser superior.

Resultado

Para obtener los resultados se tomaron tres modelos, el primer modelo consta de proxy cachés configuradas de manera individual, el segundo modelo consta de proxy cachés configuradas en un grupo de proxy cachés cooperativas de manera estática, y el tercer modelo consta de proxy cachés configuradas en un grupo de proxy cachés cooperativas de manera dinámica.

En los tres modelos para comenzar a realizar las pruebas ya estaban configuradas las tres proxy cachés.

Los puntos a observar son los números de HITs obtenidos (tasa de aciertos) y los tiempos de respuesta. La figura 6.17 muestra la tasa de aciertos que se tuvieron en cada uno de los modelos y la figura 6.18 muestra los tiempos de respuesta que se tuvieron en cada uno de los modelos.


92

20%30% 36%

00.10.20.30.4

Maneraindividual

Maneraestática

Maneradinámica

Proxy cachés configuradas

Tasa de aciertos (HITS)

Figura 6.17. Tasa de aciertos

170140

100

020406080

100120140160180

Manera individual Manera estática Manera dinámica

Proxy cachés configuradas

Tiempos de respuesta

Horas

Figura 6.18. Tiempos de respuesta

En el primer modelo se observa que el número de HITs es menor que el de las demás y que el tiempo de respuesta es mayor que el de los otros dos modelos, esto se debe a que estas proxy cachés se encuentran trabajando de manera individual y no comparten la información que se encuentra almacenada en sus cachés.


93

En el segundo modelo se observa que el número de HITs es ligeramente menor que el del tercer modelo, ya que aunque las proxy cachés se encuentran todo el tiempo configuradas, se tienen menos HITs con respecto al número de peticiones que se les realiza.

El tiempo de respuesta para el segundo modelo es mayor al del tercer modelo, esto se debe a que siempre le preguntan a sus proxy cachés hermanas y se tiene que esperar a que éstas le contesten para ir por los objetos al servidor de origen en caso de que no los tengan.

En el tercer modelo se observa que el número de HITs es ligeramente menor que el del tercer modelo, ya que desconfiguró de manera temporal a la proxy caché en la cual su uso no era viable. Pero es el que tiene el mejor tiempo de respuesta ya que no es necesario esperar a que todas sus proxy cachés hermanas le contesten para poder obtener los objetos del servidor de origen.

Capítulo 7. Conclusiones

94

CAPÍTULO 7

CONCLUSIONES

7.1 CONCLUSIONES

En este capítulo se presentan las metas alcanzadas, así como las conclusiones del presente proyecto de investigación, adicionalmente, se mencionan los trabajos futuros que pueden ser desarrollados a partir de los resultados obtenidos en este proyecto.

Se logró la implementación del sistema de configuración dinámica entre proxy cachés y entre clientes con proxy cachés que permite: realizar la detección de las proxy cachés activas que se encuentran dentro de una intranet; la


95

configuración de la proxy caché que quiere ingresar al grupo mediante un archivo de configuración que le es enviado desde una proxy caché activa; la reconfiguración de una proxy caché activa y que las demás detecten el cambio; la detección de proxy cachés caídas y se les avisa tanto a las demás que aún no las han detectado como a los clientes, para que éstos busquen a una nueva proxy caché; la evaluación de la viabilidad de uso de cada proxy caché de manera local y la configuración dinámica del navegador. Por todo lo anterior, se observa que se cumplieron de manera satisfactoria los objetivos planteados.

Además a partir del objetivo inicial propuesto para este trabajo de investigación, se puede concluir puntualmente lo siguiente:

• Con la configuración dinámica, la reconfiguración y la detección de proxy cachés caídas ya no es necesario tener que configurar o reconfigurar manualmente a cada una de ellas cada vez que ocurra algún cambio, lo cual optimiza su uso.

• Con la configuración dinámica del navegador del cliente ya no es necesario tener que configurar o reconfigurar manualmente a cada uno de ellos para que utilicen a las proxy cachés, por lo que se mejoran sus tiempos de acceso.

• Se presenta un mecanismo que puede ser adaptado a otro software de proxy cachés y a otros navegadores.

• Se desarrolló la configuración dinámica solo para el navegador Internet Explorer debido a que no importando la versión que se tenga, se puede utilizar el sistema propuesto. En lo que respecta al navegador Netscape, en cada versión el archivo de configuración para que trabaje con una proxy caché varía.


96

7.2 APORTACIONES

1.- El mecanismo de configuración dinámica de las proxy cachés.

La metodología usada para realizar la configuración dinámica de proxy cachés, puede servir como pauta para otras implementaciones, ya que los protocolos de comunicación que se desarrollaron, así como la arquitectura puede adecuarse para implementar aplicaciones para otro software de proxy cachés.

2.- El mecanismo de configuración dinámica del navegador.

El mecanismo propuesto ayuda a la localización de proxy cachés activas dentro de una intranet y con esto se puede realizar la configuración dinámica del navegador. Así mismo al tener localizadas a las proxy cachés activas, se puede implementar una configuración para otro tipo de navegador.

3.- Se disminuyen los tiempos de respuesta en un 30% cuando se utiliza un grupo proxy cachés cooperativas configurándose de manera dinámica cuando existen usuarios que tienen gustos afines con respecto a la configuración de manera estática del grupo de proxy cachés; y se disminuye en un 40% con respecto a la configuración individual de proxy cachés.

4.- Se agiliza la configuración de las proxy cachés, ya que cuando una proxy caché ingresa a un grupo es configurada automáticamente para que trabaje con las que ya se encuentran activas. También se agiliza la reconfiguración de una proxy cachés, ya que esta nueva configuración es detectada y modificada automáticamente en las demás. Y también se da de baja de manera automática en cada proxy caché cuando una de ellas ya no está trabajando.

5.- Se agiliza la detección de las proxy cachés activas y la configuración del navegador para los clientes, así como la reconfiguración de manera automática del navegador cuando la proxy caché con la que estaba trabajando deja de funcionar.


97

7.3 TRABAJOS FUTUROS

Con la herramienta propuesta se deja la infraestructura para implementar la parte de la localización de las proxy cachés que no se encuentran dentro de la intranet, para que dos intranets diferentes puedan comunicarse y compartir la información que se encuentra almacenada en las proxy cachés de cada una de estas intranets.

Con la metodología seguida para configurar el navegador Internet Explorer se puede también desarrollar la configuración dinámica del navegador Netscape bajo la plataforma de Windows, y modificar la herramienta para que realice la localización de las proxy cachés bajo la plataforma de Linux.

7.4 PUBLICACIONES

Este tema de tesis ha sido difundido por medio de dos publicaciones: en un foro nacional y en un foro internacional. En cada publicación se ha buscado mostrar el funcionamiento del sistema, siempre explicando el trabajo realizado desde distintas perspectivas.

Las publicaciones son las siguientes:

1. “Mecanismos de Configuración Dinámica para Grupos de Proxy – Cachés Cooperativas en la Web” en las memorias de la Decimocuarta Reunión de Otoño de Comunicaciones, Computación y Electrónica (IEEE ROC&C’2003).

2. “Dynamic Configuration between Proxy Caches within an Intranet” en la conferencia internacional 2004 en ciencias computacionales y sus aplicaciones (The 2004 International Conference On Computational Science And Its Applications, ICCSA 2004), el cual fue publicado en LNCS (Lecture Notes in Computer Science ) 3046, Springer-Verlag.

Anexo A. Análisis del Archivo access.log

98

ANEXO A

ANÁLISIS DEL ARCHIVO access.log

El archivo access.log tiene dos formatos diferentes para guardar cada una de las líneas de logs [Wess01] [Gand00] [Barr02] [Cler02], el formato nativo de Squid y el formato que utiliza Apache.

El formato nativo de Squid es el siguiente:

1001710342.180 1552 192.168.150.5 TCP_MISS/200 528 GET http://ar.bumeran.com/aplicantes/a_posting.ngmf? - DIRECT/64.76.45.215 text/html


99

El análisis de los campos es el siguiente:

1001710342.180: este campo corresponde al timestamp que es la hora en formato UTC en segundos.milisegundos, en que se terminó de realizar la petición.

1552: este campo indica en mili segundos el tiempo que le tomo a Squid entregar el objeto.

192.168.150.5: indica la dirección IP de la máquina que hizo la petición.

TCP_MISS/200: este campo indica los códigos de estado de la petición HTTP, en este caso el objeto no estaba en la caché. Si se genera un TCP_HIT, indica que el objeto se encontraba en la caché.

528: indica la longitud en bytes del objeto entregado.

GET: indica el método empleado (según la RFC de HTTP). Los más comunes son GET y POST.

URL: indica la URL del objeto solicitado. La primera parte corresponde al protocolo, la segunda parte (después de ://) corresponde al nombre del host del servidor de origen y la tercera parte corresponde al path del objeto en el servidor de origen.

- : es el código de identidad (si está activado)

DIRECT/64.76.45.215: indica el tipo de respuesta y la dirección IP de donde se obtuvo el objeto, en este caso el objeto se obtuvo directamente del servidor de origen 64.76.45.215. Cuando el objeto se trae directamente de la caché este campo está como NONE.

text/html: este campo indica el tipo de objeto.

El otro formato es el mismo formato que utiliza Apache. Para cambiar a este formato, es necesario cambiarle en el archivo de configuración de Squid el TAG: emulate_httpd_log por la opción emulate_httpd_log on, que por defecto está en off.


100

El formato es el siguiente:

192.168.150.5 - - [28/Sep/2001:18:37:17 -0300] "GET http://ar.google.yahoo.com/bin/query_ar? HTTP/1.0" 200 16403 TCP_MISS:DIRECT

En el formato nativo de Squid, el cuarto campo, que es el código de estado, se indica el tipo de respuesta que se generó localmente y se dividen en TCP y en UDP. Cuando el tipo de respuesta es TCP se refiere a que las peticiones HTTP fueron a través del puerto 3128 y cuando son del tipo UDP se refiere a que las peticiones HTTP fueron realizadas por otras proxy cachés a través del puerto 3130. Se tienen diferentes códigos de estados para cada uno de los tipos de respuesta y son los siguientes:

TCP_HIT: el objeto estaba en la caché.

TCP_MISS: el objeto no estaba en la caché.

TCP_REFRESH_HIT: objeto caducado que no se ha modificado.

TCP_REF_FAIL_HIT: objeto caducado, y el servidor origen no responde.

TCP_REFRESH_MISS: el objeto estaba caducado y se ha refrescado.

TCP_CLIENT_REFRESH_MISS: actualizado a petición del cliente.

TCP_IMS_HIT: el cliente ha pedido si el objeto no está caducado y no lo está.

TCP_SWAPFAIL_MISS: no se ha podido acceder al objeto en la caché.

TCP_NEGATIVE_HIT: petición de un objeto, no se ha encontrado o es inaccesible.

TCP_MEM_HIT: el objeto estaba en memoria.

TCP_DENIED: las normas de acceso no permiten responder.

TCP_OFFLINE_HIT: objeto recibido con la cahé off-line.

TCP_EXPIRED: El objeto estaba en la caché pero ha caducado.

TCP_IFMODSINCE: Una petición If-Modified-Since utilizando el método GET.

UDP_HIT: hay una copia válida del objeto en la caché.

UDP_HIT_OBJ: El objeto es lo suficientemente pequeño que cabe en la respuesta UDP.

UDP_MISS: el objeto no está en el servidor.


101

UDP_DENIED: las normas de acceso no permiten responder.

UDP_INVALID: petición no válida.

UDP_MISS_NOFETCH: no se tiene el objeto y no se puede pedir.

NONE: ocurrió algún error o no es un tipo de respuesta TCP o UDP.

En cuanto al noveno campo, que indica el modo en que se obtuvo la respuesta, así como de donde se obtuvo, es decir, directo del servidor de origen o de alguna de sus proxy cachés hermanas o padres, se pueden tener diferentes tipos de respuesta, las cuales son las siguientes:

NONE: ocurrió algún error o no se tiene el objeto en la caché.

DIRECT: el objeto se obtuvo desde el servidor de origen.

SIBLING_HIT: el objeto se obtuvo desde un hermano (y en la caché del sibling, se tiene un registro con el cuarto campo con un UDP_HIT y otro registro con el cuarto campo con un TCP_HIT).

SIBLING_UDP_HIT_OBJ: El objeto es lo suficientemente pequeño que cabe en la respuesta del sibling.

PARENT_HIT: el objeto se obtuvo desde un padre (y en la caché del padre, se tiene un registro con el cuarto campo con un UDP_HIT y otro registro con el cuarto campo con un TCP_HIT).

PARENT_UDP_HIT_OBJ: El objeto es lo suficientemente pequeño que cabe en la respuesta del padre.

DEFAULT_PARENT: el objeto se obtuvo desde un padre por defecto.

SINGLE_PARENT: el objeto se obtuvo desde el único padre apropiado.

FIRST_UP_PARENT: el objeto se obtuvo desde el primer padre disponible de la lista.

NO_PARENT_DIRECT: no existen padres para el objeto (por lo que se obtuvo directamente del servidor de origen).

FIRST_PARENT_MISS: el objeto se obtuvo desde el padre con mayor RTT (Round Trip Time).

CLOSEST_PARENT_MISS: el objeto se obtuvo desde el padre con menor RTT.

CLOSEST_PARENT: el objeto se obtuvo desde el padre con menor RTT (nuestro).


102

CLOSEST_DIRECT: el objeto se obtuvo desde un padre propio con menor RTT.

NO_DIRECT_FAIL: no se puede obtener el objeto directamente del servidor de origen ya que existe un cortafuego (firewall).

SOURCE_FASTEST: el ping ha llegado desde el origen más rápido.

ROUNDROBIN_PARENT: el objeto se obtuvo desde un padre elegido por Round Robin.

CACHE_DIGEST_HIT: el objeto se obtuvo desde una cache-digest.

CD_PARENT_HIT: el objeto se obtuvo desde una cache-digest padre.

CD_SIBLING_HIT: el objeto se obtuvo desde una cache-digest hermana.

CARP: el objeto se obtuvo desde un familiar seleccionado mediante el protocolo CARP.

INVALID CODE: código inválido.

Para entender un poco el funcionamiento de la interacción entre las proxy cachés, a continuación se presenta un ejemplo de cómo es que están trabajando tres proxy cachés, las cuales pertenecen a un grupo de proxy cachés cooperativas, y cada una de ellas tiene una jerarquía de sibling. Las direcciones IP’s de estas proxy cachés son 192.168.150.3, 192.168.150.4 y 192.168.150.5.

La máquina con la dirección IP 192.168.150.4 realiza una petición de una URL. Primeramente se buscan los objetos de esta petición en su caché local y como no los tiene, se los pide a sus cachés hermanas, pero como ellas tampoco los tienen, se realiza la petición directamente al servidor de origen.

1089337325.467 975 192.168.150.4 TCP_MISS/200 19418 GET http://www.pello.info/guias/boletin-002.html - DIRECT/213.195.75.231 text/html

1089337325.599 131 192.168.150.4 TCP_MISS/200 17597 GET http://www.pello.info/guias/tux.gif - TIMEOUT_DIRECT/213.195.75.231 image/gif

De la petición anterior de la proxy caché con dirección IP 192.168.150.4 realizada a la proxy caché con dirección IP 192.168.150.5, el resultado en el log indica que se le realizó una petición a través de una consulta (query) pero no se encontraron los objetos. Como podemos observar, el tiempo de la petición que arroja en este log es menor al que se tiene registrado en el log de la proxy caché


103

con dirección IP 192.168.150.4, por lo que podemos concluir que primero se consulta a sus hermanas y posteriormente al servidor de origen.

1089337284.940 0 192.168.150.4 UDP_MISS/000 65 ICP_QUERY http://www.pello.info/guias/boletin-002.html - NONE/- -

1089337285.980 0 192.168.150.4 UDP_MISS/000 56 ICP_QUERY http://www.pello.info/guias/tux.gif - NONE/- -

De la petición anterior de la proxy caché con dirección IP 192.168.150.4 realizada a la proxy caché con dirección IP 192.168.150.3, el resultado en el log indica que se le realizó una petición a través de una consulta (query) pero no se encontraron los objetos.



Posteriormente la proxy caché con dirección IP 192.168.150.5 realiza la misma petición, pero ahora obtenemos respuesta de una de sus hermanas, la proxy caché con dirección IP 192.168.150.4, ya que ésta tiene almacenado los objetos en su caché, pero como el tiempo de respuesta en uno de los objetos es mayor que el tiempo del timeout, este objeto es pedido al servidor de origen.

1089337307.952 33 192.168.150.5 TCP_MISS/200 19459 GET http://www.pello.info/guias/boletin-002.html - SIBLING_HIT/192.168.150.4 text/html


En la petición anterior de la proxy caché con dirección IP 192.168.150.5 realizada a la proxy caché con dirección IP 192.168.150.4, el resultado en el log indica que se le realizó una petición a través de una consulta (query) y como ésta ya tiene los objetos almacenados en su caché, le contesta con un UDP_HIT y posteriormente establece una conexión, lo que produce un TCP_HIT. Se le envía solamente un objeto ya que el tiempo de respuesta del otro objeto es mayor al timeout.


104

1089337347.471 0 192.168.150.5 UDP_HIT/000 65 ICP_QUERY http://www.pello.info/guias/boletin-002.html - NONE/- -

1089337347.483 11 192.168.150.5 TCP_HIT/200 19417 GET http://www.pello.info/guias/boletin-002.html - NONE/- text/html

1089337347.621 0 192.168.150.5 UDP_HIT/000 56 ICP_QUERY http://www.pello.info/guias/tux.gif - NONE/- -

En la petición anterior de la proxy caché con dirección IP 192.168.150.5 realizada a la proxy caché con dirección IP 192.168.150.3, el resultado en el log indica que se le realizó una petición a través de una consulta (query) pero esta proxy caché no tiene los objetos en su caché.



Posteriormente la proxy caché con dirección IP 192.168.150.3 realiza la misma petición, pero ahora obtenemos respuesta de la proxy caché con dirección IP 192.168.150.5, la cual es una de sus hermanas, ya que ésta tiene almacenado los objetos en su caché, pero como el tiempo de respuesta en uno de los objetos es mayor que el tiempo del timeout, este objeto es pedido al servidor de origen.

1089334711.096 24 192.168.150.3 TCP_MISS/200 19552 GET http://www.pello.info/guias/boletin-002.html - SIBLING_HIT/192.168.150.5 text/html


La petición anterior de la proxy caché con dirección IP 192.168.150.3 realizada a la proxy caché con dirección IP 192.168.150.4, el resultado en el log indica que se le realizó una petición a través de una consulta (query) y como ésta ya tiene los objetos almacenados en su caché le contesta con un UDP_HIT, pero la proxy caché que realizó la petición no le solicita los objetos a ésta.



105


La petición anterior de la proxy caché con IP 192.168.150.3 realizada a la proxy caché con IP 192.168.150.5, el resultado en el log indica que se le realizó una petición a través de una consulta (query) y como ésta ya tiene los objetos almacenados en su caché le contesta con un UDP_HIT y posteriormente establece una conexión, lo que produce un TCP_HIT. Se le envía solamente un objeto ya que el tiempo de respuesta del otro objeto es mayor al timeout.


1089337598.532 9 192.168.150.3 TCP_HIT/200 19458 GET http://www.pello.info/guias/boletin-002.html - NONE/- text/html


Ahora se presenta un ejemplo de cómo es que están interactuando tres proxy cachés, las cuales pertenecen a un grupo de cachés cooperativas, dos de ellas tiene una jerarquía de sibling y tienen las direcciones IP’s 192.168.150.4 y 192.168.150.5, y una de ellas tiene la jerarquía de parent con la dirección IP 192.168.150.3.

La máquina con una dirección IP 192.168.150.4 realiza una petición de una URL, primeramente busca los objetos en su caché local y posteriormente como no los tiene estos, se los pide a la proxy caché que tiene configurada como padre con dirección IP 192.168.150.3. En seguida se los pide a sus hermanas pero el padre tiene mayor prioridad. La respuesta la obtenemos tanto de la proxy caché padre como del servidor de origen.

1089341407.121 930 192.168.150.4 TCP_MISS/200 2093 GET http://zeswish.homeip.net/tutoriales/? - DIRECT/62.101.186.90 text/html

1089341407.696 575 192.168.150.4 TCP_MISS/200 2798 GET http://zeswish.homeip.net/tutoriales/estilo.css - TIMEOUT_FIRST_UP_PARENT/192.168.150.3 text/css


106

1089341408.837 1140 192.168.150.4 TCP_MISS/200 12970 GET http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - TIMEOUT_FIRST_UP_PARENT/192.168.150.3 image/jpeg


De la petición anterior de la proxy caché con dirección IP 192.168.150.4 realizada a la proxy caché con dirección IP 192.168.150.3, la cual es su padre, el resultado en el log indica que se le realizó una petición a través de una consulta (query) pero no tiene almacenados los objetos en su caché. Posteriormente el padre realiza la petición al servidor de origen en representación de la proxy caché que realizo la petición. Cuando recibe los objetos la proxy caché padre, guarda una copia de éstos en su caché y posteriormente se los envía a la proxy caché que realizó la petición.

1089338480.546 0 192.168.150.4 UDP_MISS/000 68 ICP_QUERY http://zeswish.homeip.net/tutoriales/estilo.css - NONE/- -

1089338481.088 541 192.168.150.4 TCP_MISS/200 2756 GET http://zeswish.homeip.net/tutoriales/estilo.css - TIMEOUT_DIRECT/62.101.186.90 text/css

1089338481.243 0 192.168.150.4 UDP_MISS/000 74 ICP_QUERY http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - NONE/- -

1089338482.245 1000 192.168.150.4 TCP_MISS/200 12928 GET http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - DIRECT/62.101.186.90 image/jpeg


1089339001.768 139 192.168.150.3 TCP_MEM_HIT/200 2764 GET http://zeswish.homeip.net/tutoriales/estilo.css - NONE/- text/css

1089339001.854 85 192.168.150.3 TCP_HIT/200 12936 GET http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - NONE/- image/jpeg


107

De la petición anterior de la proxy caché con dirección IP 192.168.150.4 realizada a la proxy caché con dirección IP 192.168.150.5, el resultado en el log indica que se le realizó una petición a través de una consulta (query) pero no se encontraron estos objetos en ésta.

1089341367.799 0 192.168.150.4 UDP_MISS/000 68 ICP_QUERY http://zeswish.homeip.net/tutoriales/estilo.css - NONE/- -

1089341368.497 0 192.168.150.4 UDP_MISS/000 74 ICP_QUERY http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - NONE/- -

Posteriormente la proxy caché con dirección IP 192.168.150.5 realiza la misma petición, pero ahora obtenemos una respuesta inmediata por parte de la proxy caché padre con dirección IP 192.168.150.3, ya que se tienen almacenado los objetos en su caché, pero uno de ellos no, así que este objeto es pedido directamente al servidor de origen. La petición se realiza primero a la proxy caché padre y después a la proxy caché hermana.


1089342020.446 63 192.168.150.5 TCP_MISS/200 2806 GET http://zeswish.homeip.net/tutoriales/estilo.css - TIMEOUT_FIRST_UP_PARENT/192.168.150.3 text/css

1089342020.647 200 192.168.150.5 TCP_MISS/200 12978 GET http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - TIMEOUT_FIRST_UP_PARENT/192.168.150.3 image/jpeg

De la petición anterior de la proxy caché con dirección IP 192.168.150.5 realizada a la proxy caché con dirección IP 192.168.150.3, la cual es la proxy caché padre, el resultado en el log indica que se le realizó una petición a través de una consulta (query) y como ésta ya tenía los objetos almacenados en su caché le contesta con un UDP_HIT, y posteriormente se establece una conexión para enviarle los objetos, uno de ellos es obtenido de la memoria con una respuesta TCP_MEM_HIT y otro de la caché obteniendo una respuesta TCP_HIT.

1089339133.194 0 192.168.150.5 UDP_HIT/000 68 ICP_QUERY http://zeswish.homeip.net/tutoriales/estilo.css - NONE/- -


108

1089339133.221 0 192.168.150.5 TCP_MEM_HIT/200 2764 GET http://zeswish.homeip.net/tutoriales/estilo.css - NONE/- text/css

1089339133.411 0 192.168.150.5 UDP_HIT/000 74 ICP_QUERY http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - NONE/- -

1089339133.417 5 192.168.150.5 TCP_HIT/200 12936 GET http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - NONE/- image/jpeg

De la petición anterior de la proxy caché con dirección IP 192.168.150.5 realizada a la proxy caché con dirección IP 192.168.150.4, el resultado en el log indica que se le realizó una petición a través de una consulta (query) y como ésta ya tenia los objetos almacenados en su caché le contesta con un UDP_HIT, pero la proxy caché que realizo la petición no le solicita los objetos a ésta.

1089342059.718 0 192.168.150.5 UDP_HIT/000 68 ICP_QUERY http://zeswish.homeip.net/tutoriales/estilo.css - NONE/- -

1089342059.934 0 192.168.150.5 UDP_HIT/000 74 ICP_QUERY http://zeswish.homeip.net/tutoriales/imagenes/pie.jpg - NONE/- -

Anexo B. Configuración Manual del Navegador

109

ANEXO B

CONFIGURACIÓN MANUAL DEL NAVEGADOR

Para configurar de manera manual al navegador Internet Explorer para que trabaje con una proxy caché, es necesario ir al menú Herramientas y seleccionar la opción Opciones de Internet, seleccionar la ficha Conexiones y hacer clic en el botón Configuración de Lan, como se muestra en la figura b1.

En la ventana de Configuración de la red de área local (LAN) se tienen que activar la casilla de verificación del recuadro de Servidor proxy para indicarle que se va a utilizar un servidor proxy caché y se tiene que escribir la Dirección IP de ésta y el Puerto que se va a utilizar, como se observa en la figura b2.

Anexo B. Configuración Manual del Navegador

110

Figura b1. Ventana de Opciones de Internet

Figura b2. Ventana de Configuración de red de área local

Anexo C. Código del Sistema

111

ANEXO C

CÓDIGO DEL SISTEMA

// Parte del código del archivo config.c char *inetaddr ( u_int32_t ip ) { struct in_addr in; in.s_addr = ip; return inet_ntoa(in); }; // SE CREA EL SOCKET DE ENVÍO DE MENSAJES if((env=socket(AF_INET,SOCK_DGRAM,0)) < 0) { perror("SOCKET: "); exit(0); } // ESTABLECE EL TIMEOUT timeout.tv_sec = 3; timeout.tv_usec = 0; if (setsockopt(env, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout))<0) { perror("SETSOCKOPT: ");


112

exit(1); } // SE MODIFICA LA FUNCIONALIDAD DEL SOCKET A BROADCAST CON LA OPCIÓN SETSOCKOPT opval = 1; if (setsockopt(env, SOL_SOCKET, SO_BROADCAST, &opval, sizeof(opval))<0) { perror("SETSOCKOPT: "); exit(1); } // EL SOCKET DE ENVIÓ LO ASOCIAMOS AL PUERTO 4000 envsock.sin_family = AF_INET; envsock.sin_addr.s_addr = htonl(INADDR_BROADCAST); envsock.sin_port = htons(4000); /************* OBTIENE LA DIRECCIÓN IP DE LA MAQUINA **********/ strcpy(ifr.ifr_name, IFNAME); if(ioctl(env, SIOCGIFADDR, &ifr)<0) { perror("IOCTL :"); exit(1); } /* Copia la direccion IP al mensaje */ memcpy ((void *) &ip, (void *) &ifr.ifr_addr.sa_data + 2, 4); strcpy(msg.datos,inetaddr(ip)); /************* OBTIENE LA MASCARA DE LA RED DE LA MAQUINA **********/ if (ioctl (env, SIOCGIFNETMASK, &ifr) < 0) { perror("IOCTL :"); exit(1); } memcpy ((void *) &ip, (void *) &ifr.ifr_netmask.sa_data + 2, 4); strcpy(NETMASK,inetaddr(ip)); /********************* ENVIO DEL MENSAJE DISCOVER ********************/ /* Envia el mensaje con la IP */ msg.tipo = DISCOVER; printf("Detectando proxy caches activas... \n"); if(sendto(env, &msg, sizeof(msg), 0, (struct sockaddr *)&envsock, sizeof(envsock))< 0) { perror("SENDTO: "); exit(1); } /************************** RECEPCION DEL MENSAJE ACK ********************************/ /*** Recibe a una de las proxy caches activas, y establece una conexión con ella ***/ if((len=recvfrom(env,&msg2,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS))<=0) { // SI DESPUÉS DEL TIMEOUT NO RECIBE EL MENSAJE DE ACK VUELVE A MANDA EL MENSAJE DE // DISCOVER if(sendto(env,&msg,sizeof(msg), 0,(struct sockaddr *)&envsock, sizeof(envsock))< 0) { perror("SENDTO: "); exit(1); } // NUEVAMENTE ESPERA A RECIBIR EL MENSAJE DE CONTESTACIÓN Y SI NO LO VUELVE A RECIBIR if((len=recvfrom(env,&msg2,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS))<=0) existepc=1; else printf("Proxy cache activa detectada: %s \n",msg2.datos); }


113

else printf("Proxy cache activa detectada: %s \n",msg2.datos); // VERIFICA SI ENCONTRÓ A UNA PROXY CACHÉ EN CASO DE QUE NO SE CONFIGURA SOLO if(existepc ==0) { /**** SE ESTABLECE LA CONEXIÓN CON UNA DE LAS PROXY CACHES ACTIVAS ******/ if(!(hent = gethostbyname(msg2.datos)) ) { perror("GETHOSTBYNAME: "); exit(0); } if((cl=socket(AF_INET,SOCK_STREAM,0)) < 0) { perror("SOCKET: "); exit(0); } clsock.sin_family = AF_INET; clsock.sin_addr.s_addr = *(long *) hent->h_addr; /* direccion IP de Maq. Remota */ clsock.sin_port = htons(4001); /* puerto de la maq. remota en formato BIGENDIAN */ if(connect(cl,(struct sockaddr *)&clsock, sizeof(struct sockaddr_in)) == -1) { // VUELVE A INTENTAR ESTABLECER LA CONEXIÓN if(connect(cl,(struct sockaddr *)&clsock, sizeof(struct sockaddr_in)) == -1) { perror("CONNECT: "); close(cl); printf("Error en la conexión \n"); printf("Detectando proxy caches activas... \n"); // SI NO SE PUEDE ESTABLECER LA CONEXIÓN VUELVE A BUSCAR A OTRA PROXY CACHÉ // PARA PEDIRLE LOS PARÁMETROS Y SI PARA ESTA SEGUNDA VEZ NO ENCUENTRA A NADIE // O NO SE PUEDE ESTABLECER LA CONEXIÓN SE CONFIGURA SOLA msg.tipo = DISCOVER; if(sendto(env,&msg,sizeof(msg),0,(struct sockaddr *)&envsock, sizeof(envsock))<0) { perror("SENDTO: "); exit(1); } /** RECEPCIÓN DEL MENSAJE ACK ***/ if((len=recvfrom(env,&msg2,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS))<=0) { // TIMEOUT, VUELVE A MANDA EL MENSAJE DE DISCOVER if(sendto(env,&msg,sizeof(msg),0,(struct sockaddr *)&envsock,

sizeof(envsock)) < 0) { perror("SENDTO: "); exit(1); } if((len=recvfrom(env,&msg2,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS)) <=0) existepc=1; else printf("Proxy cache activa detectada: %s \n",msg2.datos); } else printf("Proxy cache activa detectada: %s \n",msg2.datos); if(existepc ==0) { /**** ESTABLECER LA CONEXION ****/ ... /************************ OBTIENE EL ARCHIVO CONFIG.TXT **************/ if (existepc==0)


114

{ if((conf=fopen("/home/proyecto/config.txt","w+"))) { do { bzero(cadena,10); if((num=read(cl,cadena,sizeof(MAX_LINE)))<0) { perror("READ :"); exit(1); } if(num) { if(NULL!=strstr(cadena,"z")) { for(i=0;cadena[i]!='z';i++) aux[i]=cadena[i]; aux[i]='\0'; if(cadena[0]!='z') strcpy(cadena,aux); }

if(cadena[0]!='z')

{ fwrite(&cadena,strlen(cadena),1,conf); fflush(conf); existepc=1; } if(i!=0 || cadena[0]=='z') existepc=0; } }while(num); } else printf("no se pudo abrir el archivo \n "); close(cl); // SE CIERRA EL SOCKET DE CONEXIÓN } } // SE CONFIGURA EL ARCHIVO SQUID.CONF UTILIZANDO EL ARCHIVO CONFIG.TXT O EL ARCHIVO // CONFIGURE.TXT, EN CASO DE QUE NO SE OBTENGA EL ARCHIVO EN LA TRANSFERENCIA, // SE TOMA EL ARCHIVO QUE SE TIENE POR DEFECTO if (existepc==1) { close(conf); if(!(conf=fopen("/home/proyecto/configure.txt","r+"))) { printf("No se pudo abrir el archivo \n"); } } else fseek(conf,0L,0); ... l_cache_peer=configurar(conf,jerarquia, msg.datos, argumentos, NETMASK); for(i=0;l_cache_peer[i]!='\0';i++) l_c_peer[i]=l_cache_peer[i]; l_c_peer[i]=l_cache_peer[i]; ... // ENVIÓ DE UN MENSAJE PARA TODOS LOS CLIENTES POR SI TIENEN ASIGNADO A UNA PROXY CACHÉ envsock.sin_addr.s_addr = htonl(INADDR_BROADCAST); envsock.sin_port = htons(4445); bzero(msg4,1024); strcpy(msg4,msg.datos); if(sendto(env,&msg4,sizeof(msg4),0,(struct sockaddr *)&envsock, sizeof(envsock))<0) {


115

perror("SENDTO: "); exit(1); } /**************************** ENVIO DEL MENSAJE INFORM *****************************/ bzero(msg3.datos,MAX_LINE); msg3.datos[0]='\0'; msg2.tipo = INFORM; strcpy(msg2.datos,l_c_peer); envsock.sin_port = htons(4000); for(q=INICIO;q!=NULL;) { if(!(hent = gethostbyname(q->cade1)) ) { perror("GETHOSTBYNAME: "); exit(0); } envsock.sin_addr.s_addr = *(long *) hent->h_addr; if(sendto(env,&msg2,sizeof(msg2),0,(struct sockaddr *)&envsock,sizeof(envsock))<0) { perror("SENDTO: "); exit(1); } if((len=recvfrom(env,&msg3,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS))<=0) {

if(sendto(env, &msg2, sizeof(msg2), 0, (struct sockaddr *)&envsock, sizeof(envsock)) < 0) { perror("SENDTO: "); exit(1); } if((len=recvfrom(env,&msg3,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS))<=0); } p=q->sig; free(q); q=p; }//Fin for ... system("/home/proyecto/servidor &"); system("/home/proyecto/offer &"); sleep(10); system("/home/proyecto/inactiva &"); system("/home/proyecto/bajaser &"); sleep(10); system("/home/proyecto/bajatemp &"); system("/home/proyecto/altatemp &");

// Parte del código del archivo servidor.c while(1) { /****** RECEPCION DE MENSAJES (DISCOVER, INFORM O REINFORM) ******/ if((len=recvfrom(res,&msg2,MAX_LINE,0,struct sockaddr *) &ressock, &lenS))< =0) { perror("RECVFROM: "); exit(1); } switch(msg2.tipo) { case DISCOVER: { /*** ENVIO DEL MENSAJE ACK CON SU DIRECCIÓN IP ***/


116

if(sendto(res,&msg,sizeof(msg),0,(struct sockaddr *)&ressock, sizeof(ressock)) < 0) { perror("SENDTO: "); exit(1); } break; } case INFORM: { /*** RECEPCIÓN DEL MENSAJE INFORM Y ENVIÓ DE LA CONFIRMACIÓN ***/ if(sendto(res,&msg,sizeof(msg),0,(struct sockaddr *)&ressock,

sizeof(ressock)) < 0) { perror("SENDTO: "); exit(1); } strcpy(hilosDatos.l_c_peer,msg2.datos); hilosDatos.mensaje=INFORM; strcpy(hilosDatos.dir_ip,msg.datos); pthread_create(&hilos[k], NULL, (void *)&reconfigurar, (void *)&hilosDatos); break; } case REINFORM: { /*** RECEPCIÓN DEL MENSAJE REINFORM Y ENVIO DE LA CONFIRMACIÓN ***/

if(sendto(res,&msg,sizeof(msg),0,(struct sockaddr *)&ressock, sizeof(ressock)) < 0) { perror("SENDTO: "); exit(1); } strcpy(hilosDatos.l_c_peer,msg2.datos); hilosDatos.mensaje=REINFORM; strcpy(hilosDatos.dir_ip,msg.datos); pthread_create(&hilos[k], NULL, (void *)&reconfigurar, (void *)&hilosDatos); break; } }//FIN SWITCH }//FIN WHILE

// Parte del código del archivo reconfig.c // SE REALIZAR LA RECONFIGURACIÓN l_cache_peer=reconfigurar(cambiajerar, msg.datos, argumentos); for(i=0;l_cache_peer[i]!='\0';i++) l_c_peer[i]=l_cache_peer[i]; l_c_peer[i]=l_cache_peer[i]; // ENVIÓ DEL MENSAJE REINFORM Y RECONFIGURACIÓN DE LAS PROXY CACHÉS ACTIVAS

msg2.tipo = REINFORM; strcpy(msg2.datos,l_c_peer); if(NULL==strstr(cambiajerar,jerarquia2)) reconfigurar2(cambiajerar); envsock.sin_port = htons(4000); for(q=INICIO;q!=NULL;q=q->sig) { informe=0; if(!(hent = gethostbyname(q->cade1)) ) { perror("GETHOSTBYNAME: ");


117

exit(0); } envsock.sin_addr.s_addr = *(long *) hent->h_addr; if(sendto(env,&msg2,sizeof(msg2),0,(struct sockaddr *)&envsock,

sizeof(envsock)) < 0) { perror("SENDTO: "); exit(1); } if((len=recvfrom(env,&msg3,MAX_LINE,0,(struct sockaddr *)&envsock,&lenS))

<=0) { // Timeout, vuelve a mandar el mensaje de REINFORM sleep(3); if(sendto(env,&msg2,sizeof(msg2),0,(struct sockaddr *)&envsock,

sizeof(envsock)) < 0) { perror("SENDTO: "); exit(1); } if((len=recvfrom(env,&msg3,MAX_LINE,0,(struct sockaddr *)&envsock,

&lenS))<=0) informe=1; } }//Fin for

// Parte del código del archivo offer.c /*** ENVIÓ DEL ARCHIVO CONFIG.TXT ***/ if((ser2=accept(ser,(struct sockaddr *)&ser2sock, &ln)) < 0) { perror("ACCEPT: "); continue; } if (fork() == 0) { /* SE ATIENDE LA CONEXIÓN */ close(ser); if(conf=fopen("/home/proyecto/config.txt","r")) {

do { cad=leer_linea(conf); if (cad != NULL) { for(i=0;cad[i]!='\0';i++) cadena[i]=cad[i]; cadena[i]=cad[i]; write(ser2,cadena,i); } }while(cad != NULL); close(conf); strcpy(cadena,"z"); write(ser2,cadena,2); printf("Archivo transferido \n"); } else printf("no se pudo abrir el archivo"); close(ser2); exit(0); }

// Parte del código del archivo inactiva.c


118

// DETECCIÓN DE REGISTROS EN EL ARCHIVO CACHE.LOG DE PROXY CACHES CAÍDAS if((cache=fopen("/usr/local/squid/var/logs/cache.log","r"))) { while(!feof(cache)) { cad=leer_linea(cache); if (cad != NULL) { for(i=0;cad[i]!='\0';i++) cad1[i]=cad[i]; cad1[i]=cad[i]; breakpoint2++; if(breakpoint2>breakpoint) { if(NULL != strstr(cad1,"DEAD")) { existepc=0; bzero(ipdown,60); for(i=21;cad1[i]!=':'; i++); for(i++;cad1[i]==' '; i++); for(j=0;cad1[i]!='/'; i++, j++) ipdown[j]=cad1[i]; ipdown[j]='\0'; crearLista(msg.datos); for(q=INI, existe=0;q!=NULL;q=q->sig) { if(NULL!=strstr(q->cade1,ipdown)) { existe=1; break;} } if(existe==1) { printf("Proxy caché con IP %s se detecto como posible caída \n",ipdown);

envsock.sin_port = htons(4004); if(!(hent = gethostbyname(ipdown)) ) { perror("GETHOSTBYNAME: "); exit(0); } // ENVIÓ DEL MENSAJE SURVIVE PARA VERIFICAR SI EL SQUID DE LA OTRA PROXY

// CACHÉ ESTA FUNCIONANDO envsock.sin_addr.s_addr = *(long *) hent->h_addr; msg.tipo = SURVIVE; strcpy(msg2.datos,"NO"); if(sendto(env,&msg,sizeof(msg),0,(struct sockaddr *)&envsock,

sizeof(envsock)) < 0) { perror("SENDTO: "); exit(1); }

if((len=recvfrom(env,&msg2,MAX_LINE,0,(struct sockaddr *)&envsock, &lenS))<=0)

{

// SI DESPUÉS DEL TIMEOUT NO RECIBE EL MENSAJE DE CONFIRMACIÓN VUELVE A // MANDAR EL MENSAJE DE SURVIVE

if (sendto(env,&msg,sizeof(msg),0,(struct sockaddr *)&envsock,



119

// NUEVAMENTE ESPERA RECIBIR EL MENSAJE DE CONFIRMACIÓN // Y SI NO LO RECIBE SE TOMA COMO PROXY CACHÉ CAÍDA

if((len=recvfrom(env,&msg2,MAX_LINE,0,(struct sockaddr *)&envsock,

&lenS))<=0) existepc=1; } if(NULL!=strstr(msg2.datos,"NO") || existepc==1) { desactivar(ipdown, msg.datos); printf("La proxy caché con IP %s se detecto caída \n",ipdown); bzero(msg2.datos,MAX_LINE); msg2.tipo = DESACTIVA; strcpy(msg2.datos,ipdown); // SE ENVÍA EL MENSAJE DEACTIVATE A CADA UNA DE LAS PROXY CACHES ACTIVAS

crearLista(msg.datos); for(q=INI;q!=NULL;q=q->sig)

{ informe=0; if(!(hent = gethostbyname(q->cade1))) { perror("GETHOSTBYNAME: "); exit(0); } envsock.sin_addr.s_addr = *(long *) hent->h_addr; if (sendto(env, &msg2, sizeof(msg2), 0, (struct sockaddr *)&envsock,


// RECEPCIÓN DEL MENSAJE ACK

if((len=recvfrom(env,&msg3,MAX_LINE,0,(struct sockaddr *)&envsock, &lenS))<=0)

{ // TIMEOUT, VUELVE A MANDAR EL MENSAJE DE DEACTIVATE if(sendto(env,&msg2,sizeof(msg2),0,(struct sockaddr *)&envsock,

sizeof(envsock)) < 0) { perror("SENDTO: "); exit(1); } if((len=recvfrom(env,&msg3,MAX_LINE,0,(struct sockaddr *)&envsock,

&lenS))<=0); } }//Fin for // ENVÍA UN SOCKET PARA LOS CLIENTES // ENVIÁNDOLE LA IP DE LA PROXY CACHÉ CAÍDA envsock.sin_addr.s_addr = htonl(INADDR_BROADCAST); envsock.sin_port = htons(4446); bzero(msg4,1024); strcpy(msg4,ipdown);

if(sendto(env,&msg4,sizeof(msg4),0,(struct sockaddr *)&envsock, sizeof(envsock)) < 0)

{ perror("SENDTO: "); exit(1);


120

}

// Parte del código del archivo bajaser.c while(1) { /*** RECEPCION DE MENSAJES (SURVIVE O DEACTIVATE) ***/ if((len=recvfrom(res,&msg2,MAX_LINE,0,(struct sockaddr *)&ressock,&lenS))<=0) { perror("RECVFROM: "); exit(1); } switch(msg2.tipo) { case SURVIVE: { activa=0; strcpy(msg3.datos,"NO"); system("ps -aux |grep 'squid' > /home/proyecto/existe.txt"); if((existe=fopen("/home/proyecto/existe.txt","r"))) { while(!feof(existe)) { cad=leer_linea(existe); if (cad != NULL) { for(i=0;cad[i]!='\0';i++) cad1[i]=cad[i]; cad1[i]=cad[i];

if(NULL== strstr(cad1,"grep") && NULL != strstr(cad1,"[squid]")) { strcpy(msg3.datos,"YES"); break; } } } } close(existe); if(sendto(res,&msg3,sizeof(msg3),0,(struct sockaddr *)&ressock,

sizeof(ressock))<0) { perror("SENDTO: "); exit(1); } break; } case DEACTIVATE: { printf("Detección de proxy caché caída: %s \n",msg2.datos); // ENVIÓ DEL MENSAJE DE CONFIRMACIÓN if(sendto(res,&msg,sizeof(msg),0,(struct sockaddr *)&ressock,

sizeof(ressock))< 0) { perror("SENDTO: "); exit(1); } strcpy(hilosDatos.l_c_peer,msg2.datos); strcpy(hilosDatos.iplocal,msg.datos); pthread_create(&hilos[k], NULL, (void *)&desactivar,(void *)&hilosDatos); pthread_detach(&hilos[k]); k++; if(k>9) k=0;


121

break; } } }

// Parte del código del archivo bajatemp.c // OBTIENE LAS NUEVAS PETICIONES Y LAS GUARDA EN OTRO ARCHIVO if ((log2=fopen("/home/proyecto/access2.txt","r"))) { request2 = analisis(log2, IPpropia); } close(log2); ... // EVALÚA EL NUMERO DE HIT POR PROXY CACHÉ for(porcent=0, q=INI; q!=NULL;q=q->sig) { if(hits != 0) { porcent=(q->hit * 100)/hits; if(porcent < porcentaje && 0!=strcmp(q->ip_proxy,IPpropia) ) //&& q->hit!= 0) { desactivar(q->ip_proxy); printf("Desactivacion temporal de la proxy cache: %s",q->ip_proxy); } } q->hit=0; } ... // ANÁLISIS DE LOS HITS DE LAS PROXY CACHÉS while(!feof(accesslog)) { cad=leer_linea(accesslog); if (cad != NULL) { for(i=0;cad[i]!='\0';i++) cad1[i]=cad[i]; cad1[i]=cad[i]; if(cad1[0]!=10 && cad1[0]!='\0') { request++; for(i=0,j=0, paro=0, n=0;cad1[i]!='\0' && j!=9 && cad1[i]!=10;) { if(n==0 && cad1[i]!=' ') breakpoint[i]=cad1[i]; else if(cad1[i]==' ' && n==0) { n=1; paro=i;} if(cad1[i]==' ' && cad1[i+1]!=' ') j++; if(j==2 && cad1[i]!=' ') { for(k=0;cad1[i]!=' ';i++,k++) iprequest[k]=cad1[i]; iprequest[k]='\0';


122

} else if(j==3 && cad1[i]!=' ') { for(l=0;cad1[i]!=' ';i++,l++) estatus[l]=cad1[i]; estatus[l]='\0'; } else if(j==8 && cad1[i]!=' ') { for(m=0;cad1[i]!=' ';i++,m++) send[m]=cad1[i]; send[m]='\0'; } else i++; }//Fin for if(breakpoint[0]!=10 && cad1[0]!=10) breakpoint[paro]='\0'; if(NULL!=strstr(IPpropia,iprequest)) { if((NULL!=strstr(send,"SIBLING")|| NULL!=strstr(send,"PARENT")||

NULL!=strstr(send,"CARP")|| NULL!=strstr(send,"HIT")) && NULL==strstr(send,"DIRECT"))

{ for(i=0;send[i]!='/';i++); for(j=0,i++;send[i]!='\0';i++,j++) ipsend[j]=send[i]; ipsend[j]='\0'; for(q=INI;q!=NULL;) { if(NULL!=strstr(q->ip_proxy,ipsend)) { q->hit=q->hit+1; q=NULL; } else q=q->sig; } } else if( NULL!=strstr(estatus,"HIT") && NULL==strstr(estatus,"NEGATIVE")) { request++; for(q=INI;q!=NULL;) { if(NULL!=strstr(q->ip_proxy,IPpropia)) { q->hit=q->hit+1; q=NULL; } else q=q->sig; } } } }// FIN if(cad1[i]!=10) }//Fin cad != null }//Fin While return request; // Parte del código del archivo altatemp.c // MODIFICA AL REGISTRO DEL ARCHIVO IPPROXY.TXT PARA INDICAR QUE YA PASO OTRO TIEMPO // DE ESPERA Y SI EL NUMERO DEL SEGUNDO CAMPO Y EL NUMERO DEL TERCER CAMPO COINCIDEN // SE ACTIVA A LA PROXY CACHE if((ipproxy=fopen("/home/proyecto/IPproxy.txt","r+"))) { if((aux1=fopen("/home/proyecto/tempo1.txt","w"))) {


123

while(!feof(ipproxy)) { cad=leer_linea(ipproxy); if (cad != NULL) { for(i=0;cad[i]!='\0';i++) cad1[i]=cad[i]; cad1[i]=cad[i]; num1 = 0; num2 = 0; for(i=0;cad1[i]!=' ';i++) cad2[i]=cad1[i]; cad2[i]='\0'; strcpy(activar_ip,cad2); cad2[i]=cad1[i]; for(r=INI;r!=NULL;r=r->sig) { if(NULL!=strstr(r->ip_proxy,activar_ip)) { for(j=0,i++;cad1[i]!=' ';i++, j++) { cad2[i]=cad1[i]; aux[j]=cad1[i]; } aux[j]='\0'; cad2[i]=cad1[i]; k=i+1; num1=atoi(aux); for(j=0, i++;cad1[i]!='\0' && cad1[i]!=10;i++, j++) aux[j]=cad1[i]; aux[j]='\0'; num2=atoi(aux)+1; if(num1 == num2) { // AÑADE LA IP A LA LISTA p=malloc(sizeof(struct nodo)); strcpy(p->ip_proxy,activar_ip); p->sig=NULL; p->ant=NULL; if(INICIO == NULL) { INICIO = p; q = INICIO; } else { q->sig=p; p->ant=q; q=q->sig; } num2=0; } sprintf(aux,"%d",num2); // lo mismo que itoa for(i=0;aux[i]!='\0';i++, k++) cad2[k]=aux[i]; cad2[k]=10; cad2[++k]='\0'; printf("\n %s",cad2); for(longcad=0;cad2[longcad]!='\0';longcad++); fwrite(cad2,sizeof(char),longcad,aux1); fflush(aux1); break; }//if(NULL!=strstr(r->ip_proxy,activar_ip)) }//for(r=INI;r!=NULL;r=r->sig) }//if (cad != NULL) }/*fin While */ } close(aux1);


124

} close(ipproxy);

// Parte del código del archivo cliente.c while(1) { /*********** RECEPCION DEL MENSAJES POR PARTE DEL CLIENTE NAVEGADOR ******/ if((len=recvfrom(res,&msg2,MAX_LINE,0,(struct sockaddr *)&ressock,&lenS))<=0) { perror("RECVFROM: "); exit(1); } ressock.sin_port = htons(4445); if(sendto(res,&msg,sizeof(msg),0,(struct sockaddr *)&ressock, sizeof(ressock))< 0) { perror("SENDTO: "); exit(1); } }

// Parte del código de la clase Servidor.java // SE OBTIENE LA MASCARA DE LA RED do { r = Runtime.getRuntime(); p = r.exec("ipconfig"); kb = new BufferedReader ( new InputStreamReader(p.getInputStream())); i = 0; while ((line=kb.readLine())!= null) { i++; if(line.length()!=0) { ipconfig.addElement(line); if(line.indexOf("0.0.0.0")!=-1) i=0; } } if(i<=15) { if(k==0) { salida.setText("Cable de red desconectado"); Trans.setEnabled(false); k++; } for(j=0;j<=100000;j++); } }while(i<15); // OBTENGO LA DIRECCION IP DE LA MAQUINA ipaddr = InetAddress.getLocalHost(); ip= ipaddr.getHostAddress(); ipAddr = new byte[4]; i= ipconfig.size(); for(j=0;j!=i;j++) { line= (String)ipconfig.elementAt(j); if(line.endsWith(ip)) mascara=(String)ipconfig.elementAt(j+1); } caracter=' '; for(i=0, dospuntos=0; dospuntos !=2; i++)


125

{ caracter = mascara.charAt(i); if (caracter== ':') dospuntos = 1; if (caracter!= ':' && caracter!= ' ' && dospuntos == 1) dospuntos =2; } subnetmask = mascara.substring(i-1,mascara.length()); // ARMA LA DIRECION BROADCAST for(j=0, k=0, l=0; j<ip.length() && k<subnetmask.length(); l++) { bandera = j; contador = k;

for(caracter=' ' ; caracter!='.' && j<ip.length();j++) caracter=ip.charAt(j); if (j<ip.length()) aux1 = ip.substring(bandera,j-1); else aux1 = ip.substring(bandera,j); for( caracter=' ' ; caracter!='.' && k<subnetmask.length();k++) caracter=subnetmask.charAt(k); if(k<subnetmask.length()) aux2 = subnetmask.substring(contador,k-1); else aux2 = subnetmask.substring(contador,k); if(aux2.equals("255")) ipAddr[l]=(byte)Integer.parseInt(aux1); else ipAddr[l]=(byte)255; } ... // SE ENVÍA UN MENSAJE PARA DETECTAR ALGUNA PROXY CACHES ACTIVA // ACTIVO EL BROADCAST try { SalidaSocket.setBroadcast(true); } catch (SocketException e2) { e2.printStackTrace(); } // CREAMOS UN PAQUETE Y SE ENVIA EN EL DATAGRAMA Salida = new DatagramPacket(bufferSalida,bufferSalida.length, addr,port); try { SalidaSocket.send(Salida); } catch (IOException e3) { e3.printStackTrace(); } // SE COLOCAMOS EL SOCKET DE RECEPCION DE MENSAJES CON TIMEOUT salida.setText("Buscando servidores activos..."); try { EntradaSocket.setSoTimeout(1000); } catch (IOException e4) { e4.printStackTrace(); } bufferEntrada = new byte[1024];


126

// SE RECIBE LA IP DEL SERVIDOR Entrada = new DatagramPacket(bufferEntrada, bufferEntrada.length); try { EntradaSocket.receive(Entrada); } catch (IOException e4) { // SI NO OBTIENE NINGUN MENSAJE DE RESPUECTA VUELVE A ENVIAR OTRO MENSAJE DE // LOCALIZACION DE PROXY CACHÉS ACTIVAS try { SalidaSocket.send(Salida); } catch (IOException e5) { e5.printStackTrace(); } try { EntradaSocket.receive(Entrada); } catch (IOException e6) { // NO SE ENCONTRO A NINGUNA PROXY CACHÉ ACTIVA POR LO QUE SE CONFIGURA AL //INTERNET EXPLORER PARA QUE SALGA DE FORMA DIRECTA

salida.setText("No hay servidores activos..."); servactive=1; desconfigura.Desactiva_serv(); proxyserver="0"; } } // SI SE ENCUANTRAN PROXY CACHES ACTIVAS SE OBTIENE LA DIRECCIÓN IP DE LA PROXY CACHÉ // PARA CONFIGURAR AL ANVEGADOR if(servactive==0) { address = Entrada.getAddress(); aux=address.toString(); ipaux2 = aux.substring(1,aux.length()); proxyserver = ipaux2; salida.setText(ipaux2); configura.Activa_serv(ipaux2); } ...

// Parte del código de la clase Activa.java valor= new Integer(1); // DIRECCIÓN DEL DIRECTORIO DEL REGISTRO DE WINDOWS reg = new RegistryKey(RootKey.HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"); // SE HABILITA LA CASILLA DE VERIFICACION PARA QUE TOME ENCUENTA EL PUERTO Y // LA DIRECCION IP DE LA PROXY CACHÉ CON LA QUE SE VA A TRABAJAR proxy_habilitado = new RegistryValue("ProxyEnable", ValueType.REG_DWORD,valor); reg.setValue(proxy_habilitado); // SE ASIGNA LA DIRECCION IP Y EL PUERTO proxy= new RegistryValue("ProxyServer", ValueType.REG_SZ, ipport); reg.setValue(proxy);


127

// Parte del código de la clase Desactiva.java valor= new Integer(0); // DIRECCIÓN DEL DIRECTORIO DEL REGISTRO DE WINDOWS reg = new RegistryKey(RootKey.HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"); // SE DESHABILITA LA CASILLA DE VERIFICACION proxy_deshabilitado = new RegistryValue("ProxyEnable", ValueType.REG_DWORD,valor); reg.setValue(proxy_deshabilitado);


128

REFERENCIAS

[Baen97] M. Baentsch, L. Baum, G. Molter, S. Rothkugel, P. Sturm, Enhancing

the Web’s Infrastructure – From Caching to Replication, IEEE Internet Computing, Vol. 1, No. 2, Abril 1997

[Baen97a] M. Baentsch, L. Baum, G. Molter, S. Rothkugel, P. Sturm, World-

Wide Web Caching: The Application Level View of the Internet, IEEE Communications, Vol. 35, No. 6, Junio 1997

[Ball04] T. L. Ballari, Sistemas de Distribución de información en ambientes

Web, Laboratorio de Redes / Universidad Nacional de Luján, Argentina. En línea, disponible en http://www.unlu.edu.ar/~tyr/TYR-trab/siuweb/sist-dist-inf-web, 2004

[Bari99] G. Barish, K. Obraczka, A Survey of World Wide Web Caching, USC

Information Sciences Institute, 1999 [Barr02] E. Barril M., M. Cid P., V. Cid P., Squid, Trabajo de Seguridad en

Sistemas Informáticos Curso 2001-2002, Universidad de Vigo, España. En línea, disponible en http://ccia.ei.uvigo.es/docencia/SSI/ TrabajoSquid.pdf, 2002

[Cies99] M Cieslak, D Forster, Web Cache Coordination Protocol V1.0, Cisco

Systems, Junio 1999 [Cies00] M Cieslak, D Forster, G Tiwana, R Wilson, Web Cache Coordination

Protocol V2.0, Cisco Systems, Julio 2000 [Cler02] I. Clerencia, M. J. Pérez, Servicios de Alto Nivel en Redes

Informáticas: Prácticas de la Asignatura, Universidad de Zaragoza, España. En línea, disponible en http://www.sindominio.net/~isaac/ papers/sanri/sanri.pdf, 2002

[Cons04] ConsulIntel, ¿Qué es Caching?, White Papers de CacheFlow. En

línea, disponible en http://www.consulintel.es/Html/Tutoriales/ CacheFlow/wp_que_es_cache.html, 2004

[Coop00] I. Cooper, P.Gauthier, J. Cohen, M. Dunsmuir, C. Perkins Web Proxy

Auto-Discovery Protocol, Equinix, Inktomi Corporation, Microsoft Corporation, RealNetworks Inc., Sun Microsystems Inc., Noviembre 2000


129

[Crov97] Mark E. Crovella, Azer Bestavros, Self-Similarity in World Wide Web

Traffic: Evidence and Posible Causes, IEEE/ACM Transactions on Networking, December 1997

[Davi99] B. D. Davison, A Survey of Proxy Caché Evaluation Techniques,

Proceedings of the Fourth International Web Caching Workshop, WCW99, San Diego, Abril 1999

[Gand00] M. I. Gandía C., Afinament de servidors proxy-cache, Dept.

Comunicacions i Operacions / Centre de Supercomputació de Catalunya. En línea, disponible en http://www.cesca.es/promocio/ aula/afinament.pdf, Diciembre 2000

[Heat04] J. Heaton, Making use of a Proxy/Cache and/or Mirror site to relieve

Network Congestion, Manchester Computing / University of Manchester, United Kingdom. En línea, disponible en http://voyager.mcc.ac.uk/Papers/ProxyMirror.html, 2004

[Lela94] Will Leland, Murad Taqqu, Walter Willinger, Daniel Wilson, On the

Self-Similar Nature of Ethernet Traffic (Extended Version), IEEE/ACM Transactions on Networking, February 1994

[Marl02] G. Marlow, Web Proxy Auto Discovery (wpad) with Squid and

Apache. En línea, disponible en http://www.rumnies.com/gareth/ geek/wpad.html, 2002

[Nets96] Netscape, Netscape Navigator Proxy Auto-Config File Format, Marzo

1996 [Osdn04] OSDN, Open Source Development Network, jRegistryKey Users

Manual, 2004 [Sorr04] K. Sorrentino, Configuring Your Browser for Automatic Proxy,

University of Connecticut. En línea, disponible en http://www.helpdesk.uconn.edu/trouble/proxy/autoprox.html, 2004

[Sosa02] V. J. Sosa S., Arquitectura para la Distribución de Documentos en un

Sistema Distribuido a Gran Escala, tesis de doctorado, Centro de Investigación en Computación, IPN, Marzo 2002

[Sosa02a] V. J. Sosa S., L. Navarro, Arquitectura para el Acceso a

Documentación Distribuida Basada en Cachés en el Web, 9no Congreso Internacional de Investigación en Ciencias Computacionales, Puebla, México, Octubre 2002


130

[Squi04] Squid bajo Windows NT. En línea, disponible en

http://www2.idesoft.com/squid/que.htm, 2004 [Touc98] J. Touch, A. S. Hughes, The LSAM Proxy Cache - a Multicast

Distributed Virtual Cache, USC / Information Sciences Institute. En línea, disponible en http://www.isi.edu/touch/pubs/cnis98/, Agosto 1998

[Vall98] V. Valloppillil, K. W. Ross, Cache Array Routing Protocol v1.0,

Microsoft Corporation, University of Pennsylvania, Febrero 1998 [Vixi00] P. Vixie, D. Wessels, Hyper Text Caching Protocol (HTCP/0.0), Enero

2000 [Wess97] D. Wessels, K. Claffy, Internet Cache Protocol (ICP), version 2,

UCSD / National Laboratory for Applied Network Research. En línea, disponible en http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2186.html, Septiembre 1997

[Wess97a] D. Wessels, K. Claffy, Application of Internet Cache Protocol (ICP),

version 2, UCSD / National Laboratory for Applied, Network Research, Septiembre 1997

[Wess00] D. Wessels, SQUID Frequently Asked Questions, About Squid, this

FAQ, and other Squid information resources. En línea, disponible en http://www.squid-cache.org/Doc/FAQ/FAQ-1.html, 2000

[Wess01] D. Wessels, SQUID Frequently Asked Questions, Squid Log Files. En

línea, disponible en http://www.squid-cache.org/Doc/FAQ/FAQ-6.html, 2001.

[Zhan97] L. Zhang, S. Floyd, V. Jacobson, Adaptive Web Caching, UCLA /

Computer Science Department. En línea, disponible en http://irl.cs.ucla.edu/AWC/, Abril 1997

Centro Nacional de Investigación y Desarrollo ... Xochitl Landa... · Debido a la importancia de...

Documents

Transcript of Centro Nacional de Investigación y Desarrollo ... Xochitl Landa... · Debido a la importancia de...