75.04 Algoritmos y Programación II Trabajo práctico #1: implementación de TDAs Primer cuatrimestre de 2009

Transcripción

1 75.04 Algoritmos y Programación II Trabajo práctico 1: implementación de TDAs Primer cuatrimestre de 2009 $Date: 2009/08/07 15:32:58 $ 1. Objetivos Ejercitar conceptos relacionados con el diseño e implementación C++ de TDAs. Escribir un programa orientado a objetos (y su correspondiente documentación) que resuelva el problema que presentaremos más abajo. 2. Alcance Este trabajo práctico es de elaboración grupal, evaluación individual, y de carácter obligatorio para todos alumnos del curso. 3. Requisitos El trabajo deberá ser entregado personalmente, en la fecha estipulada, con una carátula que contenga los datos completos de todos los integrantes, un informe impreso de acuerdo con lo que mencionaremos en la sección 6.2, y con una copia digital de los archivos fuente necesarios para compilar el trabajo. 4. Descripción En este caso, vamos a trabajar sobre una implementación del trabajo anterior [2]: buscamos realizar extensiones que nos permitan poder alojar múltiples sitios web simultáneamente, y tener mejor soporte del protocolo HTTP Configuración Debido a la cantidad creciente de parámetros requeridos, se hace impráctico usar la línea de comandos para configurar todos los aspectos del programa. Es por esto que vamos a usar un archivo de texto, conteniendo la configuración de nuestro servidor:

2 The ServerName directive sets the hostname and port that the server uses to identify itself. ServerName localhost DocumentRoot: The directory out of which you will serve your documents. By default, all requests are taken from this directory. DocumentRoot "/tmp/prueba/doc_root" ServerAdmin: Your address, where problems with the server should be ed. This address appears on some server-generated pages, such as error documents. ServerAdmin DefaultType is the default MIME type the server will use for a document if it cannot otherwise determine one, such as from filename extensions. If your server contains mostly text or HTML documents, "text/plain" is a good value. If most of your content is binary, such as applications or images, you may want to use "application/octet-stream" instead to keep browsers from trying to display binary files as though they are text. DefaultType text/plain The TypesConfig directive sets the location of the MIME types file. This file sets the default list of mappings from filename extensions to content types. The file contains lines in the format of the arguments to an AddType command: MIME-type extension... The extensions are lower-cased. Blank lines, and lines beginning with a hash character ( ) are ignored. TypesConfig "/tmp/prueba/conf/mime.types" ErrorLog: The location of the error log file. ErrorLog "/tmp/prueba/logs/error_log" 4.2. Tipos MIME Como vimos más arriba, TypesConfig nos permite parametrizar la tabla que usamos en el trabajo anterior para asociar la extensión, con el tipo del contenido solicitado. De esta forma, evitamos tener que modificar y recompilar el programa cada vez que queremos hacer un cambio en ésta. El formato del archivo apuntado por TypesConfig es de dos columnas separadas por espacio: tipo, y lista de extensiones: This is a comment. I love comments. This file controls what Internet media types are sent to the client for 2

3 given file extension(s). Sending the correct media type to the client is important so they know how to handle the content of the file. Extra types can either be added here or by using an AddType directive in your config files. For more information about Internet media types, please read RFC 2045, 2046, 2047, 2048, and The Internet media type registry is at < application/octet-stream zip rar exe dll application/pdf pdf image/gif gif image/jpeg jpeg jpg jpe image/png png text/html html htm shtml text/plain asc txt video/mpeg mpeg mpg mpe video/x-msvideo avi 4.3. VirtualHosts Mediante esta directiva, podemos alojar múltiples sitios web simultáneamente. Por ejemplo, supongamos que queremos alojar y para lograr esto, agregamos las siguientes líneas a la configuración presentada en la sección 4.1: <VirtualHost> ServerName DocumentRoot /www/domain </VirtualHost> <VirtualHost> ServerName DocumentRoot /www/otherdomain DefaultTtype application/octet-stream </VirtualHost> Es decir, se trata de crear un bloque <VirtualHost> para cada uno de las ubicaciones web a servir. Dentro de cada <VirtualHost>, encontramos directivas ServerName y DocumentRoot para designar el nombre del sitio, y la posición del contenido en el sistema de archivos, respectivamente. Observar que la implementación debería permitir redefinir DocumentRoot, DefaultType, y TypesConfig dentro del bloque: en estos casos, las transacciónes HTTP destinadas a estos sitios usarán los valores especializados. En cambio, por omisión, el sitio virtual hereda los valores globales de estos parámetros Conexiones persistentes A diferencia del trabajo anterior, permitiremos realizar múltiples transacciones HTTP GET y HEAD en una misma conexión. Por ejemplo, supongamos que /index.html es un texto que hace una referencia a una imagen alojada en nuestro sitio; y que el cliente usa la misma conexión para hacer ambos pedidos. En intercambio HTTP sería: C: GET /index.html HTTP/1.1 3

4 C: Host: localhost C: S: HTTP/ OK S: Date: Mon, 16 Mar :01:50 GMT S: Content-Type: text/html S: Content-Length: 172 S: S: <IMG SRC="/icons/folder.gif"> C: GET /icons/folder.gif HTTP/1.1 C: Host: localhost C: S: HTTP/ OK S: Date: Mon, 16 Mar :01:50 GMT S: Content-Type: image/gif S: Content-Length: 1233 S: En este último ejemplo, después de haber recibido la segunda respuesta, el cliente HTTP decide finalizar la sesión cerrando el stream HTTP Línea de comando Continuando con lo descripto en el trabajo previo, las opciones -i y -o permiten seleccionar los streams de entrada y salida respectivamente. Por defecto, éstos serán cin y cout. Lo mismo ocurrirá al recibir - como argumento. Similarmente, al finalizar, todos nuestros programas retornarán un valor nulo en caso de no detectar ningún problema; y, en caso contrario, devolveremos un valor no nulo (por ejemplo 1). Esta característica facilita la detección y reporte de errores cuando el programa es invocado por otros programas, como por ejemplo al ser lanzado por inetd. Para pasar el archivo de configuración visto en la sección 4.1, usamos la opción -c. De no estar explícitamente presente esta opción, el programa deberá implementar un único sitio, usando localhost como ServerName,. como DocumentRoot, y adoptando la tabla de tipos MIME usada en el trabajo anterior. 5. Implementación 5.1. Portabilidad Como es usual, necesitamos que la implementación desarrollada provea un grado mínimo de portabilidad: para esto, vamos a correr nuestros programas en Windows/MS-DOS, usando el compilador DJGPP [3]; y alguna versión reciente de UNIX: BSD, o Linux (RedHat, Debian, Ubuntu) Restricción adicional Usar listas enlazadas para agrupar los VirtualHosts y ServerNames. Además, teniendo en cuenta el objetivo principal del trabajo, será necesario 4

5 implementar todos los contenedores de datos usados en la solución propuesta (i.e. no usar STL). 6. Entregables 6.1. Casos de prueba Sugerimos hacer uso del programa runtest, suministrado junto con el código fuente de este trabajo: salvo casos excepcionales -i.e. explícita y debidamente justificados en el informe- todos los casos de prueba deberán ser incorporados en esta herramienta. La misma, provee la infraestructura mínima necesaria para automatizar una parte del proceso de pruebas. Los detalles relacionados con este programa, han sido explicados en la clase del 23/ Informe El informe deberá incluir: Documentación relevante al diseño e implementación del programa; incluyendo la información detallada relacionada con la toma de decisiones a lo largo de todo el TP: problemas encontrados, evidencia, experiencia previa, análisis de soluciones alternativas, etc. Documentación relevante al proceso de compilación: cómo obtener el ejecutable a partir de los archivos fuente. Documentación relacionada con las corridas de prueba. El manual de uso del programa, en formato txt y/o HTML. El código fuente, en lenguaje C++ (en dos formatos, digital e impreso). No usar medios de almacenamiento poco confiables como diskettes. Sí usar medios ópticos (CDs), memorias flash, etc. Para intentar mejorar las chances de poder acceder a la información, se pueden proveer la información usando múltiples formatos. En cualquier caso, consultá con tu ayudante. Este enunciado. 7. Fechas La última fecha de entrega y presentación sería el jueves 4/6. Referencias [1] [2] Código fuente de partida. algo2/tp q tar.gz. [3] DJGPP. 5