Trabajo práctico 1 (primer cuat. 2009)

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.
4.1.
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:
# 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
# e-mailed. This address appears on some server-generated pages, such
# as error documents.
#
ServerAdmin webmaster@fi.uba.ar
# 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
# 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 2077. The Internet media type
# registry is at <http://www.iana.org/assignments/media-types/>.
#
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 www.domain.tld y
www.otherdomain.tld: para lograr esto, agregamos las siguientes lı́neas a la
configuración presentada en la sección 4.1:
<VirtualHost>
ServerName www.domain.tld
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost>
ServerName www.otherdomain.tld
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.
4.4.
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
C:
C:
S:
S:
S:
S:
S:
S:
S:
S:
C:
C:
C:
S:
S:
S:
S:
S:
S:
Host: localhost
HTTP/1.1 200 OK
Date: Mon, 16 Mar 2009 00:01:50 GMT
Content-Type: text/html
Content-Length: 172
...
<IMG SRC="/icons/folder.gif">
...
GET /icons/folder.gif HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Mon, 16 Mar 2009 00:01:50 GMT
Content-Type: image/gif
Content-Length: 1233
...
En este último ejemplo, después de haber recibido la segunda respuesta, el
cliente HTTP decide finalizar la sesión cerrando el stream HTTP.
4.5.
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.
5.1.
Implementación
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).
5.2.
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
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/4.
6.2.
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] http://listas.fi.uba.ar/mailman/listinfo/mat7504.
[2] Código fuente de partida. http://webs.sinectis.com.ar/lesanti/
algo2/tp1-2009-1q-0.0.1.tar.gz.
[3] DJGPP. http://www.delorie.com/djgpp/.
5