Aplicacion Multiproceso

ArquitecturayComputacinParalela
Curso2014/2015
1 PRCTICA
Aplicacin Multiproceso sobre HTTP
1 Objetivos
Se pretende que el estudiante conozca los mecanismos que proporciona el sistema operativo Unix
para el desarrollo de aplicaciones multiproceso, principalmente respecto a la creacin y terminacin
de procesos, y a su intercomunicacin. Tambin se estudiar el manejo de descriptores de E/S.
2 Desarrollo
La prctica est estructurada en cuatro etapas para facilitar su desarrollo (si bien la ltima de ellas es
opcional). Al finalizar cada etapa, el estudiante deber entregar a travs del EVA los resultados
parciales alcanzados. El formato de cada entrega y las fechas correspondientes se especificarn en su
momento en el entregador correspondiente. Esta prctica tiene una duracin total de 6 semanas.
La fecha tope para la entrega de los resultados finales de esta prctica ser el viernes de la semana 7
del primer bimestre a las 12:00 horas. La entrega se realizar mediante la subida al EVA de un nico
fichero zip que contenga el cdigo fuente desarrollado por el estudiante y otros ficheros que se
explican ms adelante. El fichero subido deber ajustarse a las especificaciones indicadas en el
entregador correspondiente. De no respetar dichas especificaciones, el profesor podr considerar no
vlida la entrega.
Esta prctica se realizar en grupos de 3 estudiantes como mximo, teniendo libertad los estudiantes
para elegir la configuracin de estos grupos. Todas las prcticas entregadas sern analizadas para
detectar posibles casos de plagio. En caso de que se compruebe que existe algn caso de plagio,
todos los estudiantes pertenecientes a los grupos implicados tendrn 0 puntos como calificacin final
de esta prctica (es decir, que no podr presentarse a la prueba de evaluacin de esta prctica) y el
hecho ser puesto en conocimiento de la autoridad competente para que tome las acciones
pertinentes.
3 Criterios de evaluacin
Esta prctica tiene un peso total de 10 puntos sobre la calificacin del primer bimestre repartidos de
la siguiente forma:
1. Informe de la prctica que incluye el cdigo de la aplicacin (4 puntos).
2. Evaluacin individual de los resultados de aprendizaje asociados a la prctica (6 puntos).
3. Hasta 2 puntos extra por la realizacin de las partes opcionales (1 punto por opcin).
4 Enunciado
Se va a desarrollar una aplicacin multiproceso que podr atender peticiones concurrentes a travs
del protocolo HTTP, que ser desarrollada en C sobre el sistema operativo FreeBSD. A este tipo de
aplicaciones se las denomina servidores web. Para realizar esta prctica, se le proporcionan los
siguientes recursos (disponibles a travs del EVA): un mdulo de funciones para procesar el
Prctica3pgina1
Curso2014/2015
protocolo HTTP y realizar las comunicaciones de red (ver apartado 4.1.5), un mdulo que servir
para procesar las opciones de ejecucin del programa y establecer los parmetros de configuracin
del servidor, y un fichero Makefile para facilitar la compilacin y el enlazado de la aplicacin, que
ser adaptado por el estudiante.
La prctica se dividir en dos partes:
Una parte obligatoria para todos los estudiantes que abarca las funcionalidades bsicas del
servidor web (ver apartado 4.2).
Una parte opcional que representa algunas mejoras sobre la parte obligatoria, a elegir dentro
de un catlogo propuesto en esta prctica (ver apartado 4.3).
Documentacin a entregar: Se deber entregar el programa codificado en lenguaje C, debidamente

comentado y con un estilo de programacin adecuado, as como cualquier otro fichero necesario para
compilar y enlazar el programa, incluyendo el fichero Makefile. En la ltima entrega se deber
adjuntar un documento en el que se expliquen los detalles de diseo no especificados explcitamente
en el enunciado de esta prctica, tanto de las funciones bsicas como de las mejoras elegidas (parte
opcional). Si la prctica tuviera algn error de funcionamiento conocido por el estudiante, tambin
deber aclararlo en el documento.
4.1 Descripcin del servidor web multiproceso

Para comprender mejor este apartado es interesante consultar el Apndice A.
4.1.1 Gestin de los procesos en el servidor web multiproceso

Un servidor web ha de poder atender simultneamente muchas peticiones HTTP. Por cada
documento HTML que pide un agente de usuario (navegador), se pueden desencadenar mltiples
solicitudes de recursos adicionales (primero el propio documento HTML y despus recursos tales
como imgenes, hojas de estilos, recursos multimedia, ). Muchos agentes de usuario abren varias
conexiones simultneas con el servidor y piden en paralelo los recursos auxiliares para acelerar el
proceso de descarga del documento. A cada uno de los procesos encargados de gestionar una
conexin en el lado del agente de usuario se le denomina proceso cliente.
Cada peticin individual lleva un cierto tiempo de servicio, que no es despreciable. Por ejemplo, el
servidor ha de procesar la peticin para saber qu se le est pidiendo, ha de abrir y leer el documento
pedido o bien generarlo dinmicamente, y ha de transmitirlo al cliente. Si se trata de un recurso
dinmico, ha de ejecutar el programa que lo genera. Todas esas operaciones pueden llevar acarreadas
esperas de E/S y un cierto consumo de tiempo de CPU. Por tanto, si se desea que un servidor web
atienda con diligencia a mltiples agentes de usuario a la vez, es necesario utilizar las capacidades de
multiproceso o multihilo del sistema operativo para procesar concurrentemente tantas peticiones
como sea posible. Aqu es donde la utilizacin de mltiples procesos va a venir muy bien para el
desarrollo del servidor web. Otra posibilidad sera utilizar mltiples hilos.
Existen muchas formas de implementar un servidor web multiproceso. En este apartado se presentar
una posible implementacin partiendo de un diseo bsico para que, en sucesivos refinamientos, se
llegue a la solucin final. En general, todas las implementaciones suponen la existencia de un
proceso maestro que realiza tareas de vigilancia del estado general del servidor, y una serie de
procesos auxiliares que son los que atienden a los clientes y les sirven las peticiones. En adelante se
denominar procesos trabajadores a los de esta segunda categora.
La manera ms simple de gestionar los procesos trabajadores consiste en que, para cada cliente que
se conecte al servidor, el proceso maestro cree un proceso trabajador nuevo y le pase la conexin en
Prctica3pgina2
Curso2014/2015
cuestin. Cuando se cierre la conexin, el trabajador terminar su ejecucin. El inconveniente de

esta tcnica es que la creacin y la destruccin de los procesos es una operacin relativamente
costosa e introduce una sobrecarga en la atencin a los clientes, ya que siempre hay que esperar a
que se cree un proceso trabajador antes de poder empezar a atender peticiones de un cliente.
Una posible mejora consistira en crear, al comienzo de la ejecucin del servidor web, un cierto
nmero fijo de procesos trabajadores, que inicialmente estaran inactivos. Cuando llegue una
peticin de conexin de un cliente, se le asignar a uno de los procesos trabajadores inactivos, que
se encargar de atender sus peticiones. Cuando se cierre la conexin con el cliente (porque el cliente
decida cerrarla, porque se produzca un error, etc.), el proceso trabajador podr finalizar tambin su
ejecucin y crearse otro proceso nuevo para sustituirlo, o bien el proceso trabajador podr volver al
estado inactivo y reutilizarse para procesar conexiones futuras. En este caso, la sobrecarga es mucho
menor, ya que no hay que esperar a que se cree un proceso nuevo para las conexiones que llegan.
Ahora bien, puede darse el caso de que todos los procesos trabajadores estn ocupados cuando llega
una conexin nueva, lo cual demorara la atencin de dicha conexin hasta que alguno de los
procesos trabajadores quede libre.
Un refinamiento de la tcnica anterior consistira en crear inicialmente un cierto nmero de procesos
trabajadores, pero con la posibilidad de crear ms procesos, si en un momento dado todos estn
ocupados y llegan ms peticiones de conexiones de clientes. Al igual que en el caso anterior, los
procesos que terminen con sus conexiones pasarn nuevamente al estado inactivo a la espera de que
haya trabajo para ellos.
Un inconveniente de usar el mtodo anterior es que, si durante un cierto intervalo de tiempo se
produce un pico de conexiones, es probable que el servidor web cree muchos procesos trabajadores.
Cuando el pico haya sido atendido, quedar un gran nmero de procesos trabajadores inactivos
consumiendo recursos del sistema. La solucin a este problema consiste en hacer que el proceso
maestro, si ve que hay demasiados procesos trabajadores inactivos, d orden a algunos de ellos para
que finalicen.
Resumiendo todo lo anterior, el servidor web a desarrollar debe cumplir los siguientes requisitos
respecto a la gestin del servicio:
El servidor constar de un proceso maestro y un nmero variable de procesos trabajadores.
El proceso maestro vigilar peridicamente el estado de los procesos trabajadores y crear o

destruir procesos trabajadores segn sea necesario.
Los procesos trabajadores estarn en un bucle en el que esperarn a que se conecte un

cliente y, entonces, atendern todas sus peticiones hasta la desconexin del cliente. No
atendern a ms clientes hasta que se desconecte el cliente actual.
Inicialmente, el proceso maestro crear un nmero Pini de procesos trabajadores.
Si el proceso maestro detecta que hay menos de Pinact_min procesos trabajadores inactivos,
entonces crear procesos trabajadores adicionales hasta llegar a tener Pinact_min procesos
trabajadores inactivos o se alcance el lmite de Pmax procesos trabajadores.
Si el proceso maestro detecta que han quedado ms de Pinact_max procesos trabajadores

inactivos, ordenar la terminacin de varios de esos procesos inactivos, hasta alcanzar el tope
de Pinact_max procesos trabajadores inactivos.
Para finalizar la ejecucin del servidor web, el proceso maestro dar la orden a todos los
procesos trabajadores para que, cuando terminen de atender la peticin en curso, finalicen su
ejecucin.
Prctica3pgina3
Curso2014/2015
Nota: La gestin de procesos que se pide en esta prctica est basada en la que utilizan servidores
web reales como Apache.
4.1.2 Comunicacin entre los procesos del servidor web

En la aplicacin a desarrollar existen tres casos fundamentales en los que los diferentes procesos que
la componen han de comunicarse:
Los procesos trabajadores han de indicar su estado (activo o inactivo) al proceso

maestro, de forma que ste pueda determinar si es necesario crear nuevos procesos
trabajadores, o eliminar un exceso de procesos trabajadores inactivos. En Unix, y en el
caso particular de FreeBSD, existen diferentes mecanismos de comunicacin entre procesos,
pero en la implementacin del servidor web de esta prctica deber utilizarse memoria
compartida. Para ello, al iniciarse el servidor web, se debe crear, mediante mmap(2), una
zona de memoria que ser compartida por todos los procesos del servidor web. En ella se
almacenar una tabla de tamao Pmax con una entrada para cada posible proceso, que indique,
adems de otros campos, el estado del proceso (activo, inactivo, entrada no usada). Si
el estudiante quiere usar otro mecanismo de comunicacin entre procesos, debe comentarlo
previamente con su profesor.
A veces, el proceso maestro ha de ordenar a los procesos trabajadores inactivos que

terminen su ejecucin, por ejemplo cuando hay exceso de procesos inactivos o cuando se
desea finalizar la ejecucin del servidor web. Para este caso, se propone que el proceso
maestro enve una seal de terminacin (SIGTERM) a los procesos escogidos para su
eliminacin, y que stos la capturen y finalicen ordenadamente. Si el proceso trabajador que
recibe la seal est atendiendo a un cliente, terminar tras procesar la peticin en curso.
Para finalizar de forma ordenada, el proceso maestro debe gestionar la captura de las seales
SIGTERM y SIGINT, de forma que, cuando reciba cualquiera de ellas, d orden a todos los
procesos trabajadores para que terminen su ejecucin al finalizar el procesamiento de la
peticin en curso, cerrando adecuadamente las comunicaciones con los clientes.
Un proceso trabajador que crea un proceso hijo para ejecutar un CGI (Common Gateway
Interface) ha de pasar al CGI informacin sobre la invocacin y recibir de ste su resultado,
tal como se explica en el apartado 4.1.4. En este caso, se propone utilizar tuberas y duplicar
sobre ellas los descriptores STDIN_FILENO (entrada estndar) y STDOUT_FILENO (salida
estndar) del proceso CGI, adems de definir las variables de entorno necesarias.
4.1.3 Parmetros del servidor web

El servidor web a implementar necesita conocer algunos parmetros bsicos para su correcto
funcionamiento; en concreto:
Puerto TCP de escucha (opcin p[ort]). El servidor aceptar las peticiones de conexin
de los clientes en el puerto TCP indicado. Este parmetro es obligatorio
Directorio base (opcin b[ase]) a partir del cual se ubican los recursos que gestiona el
servidor. Por ejemplo, ~/paginas. El servidor deber comprobar que el camino indicado
existe y es un directorio. Si no es as, el servidor deber mostrar, por su salida de error
estndar, un mensaje indicndolo, y terminar su ejecucin.
Prctica3pgina4
Curso2014/2015
Valores relacionados con el control del nmero de procesos trabajadores, ya comentados

anteriormente: Pini (opcin Pini o I), Pmax (opcin Pmax o -M), Pinact_min (opcin Imin o
-n), y Pinact_max (opcin Imax o -m).
Ayuda (opcin h[elp]). Muestra una ayuda acerca del uso del programa, describiendo
brevemente las opciones disponibles, y ejemplos de uso.
Informacin de depuracin (opcin [debu]g). Permite elegir entre mostrar informacin

de depuracin, o no hacerlo. En el caso de usar este parmetro se puede indicar el nivel de
depuracin, mediante un valor numrico para elegir el nivel de detalle, siendo 1 el nivel de
depuracin por defecto (si se selecciona esta opcin sin indicar un nivel especfico). Esta
opcin le permitir comprobar a su eleccin el funcionamiento del programa, o eliminar
todos los mensajes una vez que el programa ha sido depurado completamente.
Los parmetros del servidor web se especificarn como argumentos de la lnea de mandatos. No se
admite que los valores estn incrustados en el cdigo ni que sean constantes de compilacin. Para
facilitar el desarrollo del servidor web, se proporciona un mdulo (ficheros param.c y param.h) para
la gestin de los parmetros bsicos de configuracin del servidor, disponible en el EVA.
4.1.4 Ejecucin de programas CGI

CGI (Common Gateway Interface) es una interfaz estandarizada que se utiliza para que un servidor
web invoque a un programa externo con el propsito generar un recurso web (documento HTML,
imagen, PDF, .) dinmicamente. Puede encontrar informacin ms completa sobre esta interfaz en
http://www.w3.org/CGI/. De manera simplificada y adaptada a las necesidades de esta prctica, la
interfaz CGI consiste en lo siguiente:
El programa CGI ha de recibir por su entrada estndar el cuerpo asociado a la peticin, si no

es nulo (campo cuerpo de la estructura de peticin descrita en el apartado 4.1.5).
El servidor web ha de recoger la salida estndar del programa CGI y enviarla tal cual al
cliente.
El servidor web ha de proporcionar al programa CGI ciertos valores de contexto mediante

variables de entorno. En esta prctica han de definirse las siguientes variables de entorno:
SERVER_NAME:
nombre de la mquina donde se ejecuta el servidor. Se puede obtener mediante
la funcin gethostname(3).
GATEWAY_INTERFACE:
SERVER_PROTOCOL
siempre tendr el valor "CGI/1.1".
siempre tendr el valor "HTTP/1.1".
SERVER_PORT:
su valor es el nmero del puerto TCP en el que escucha el servidor web (en el
que acepta conexiones).
REQUEST_METHOD:
valdr "GET" o "POST", dependiendo del mtodo utilizado en esta peticin

(campo metodo de la estructura de peticin).
SCRIPT_NAME: contendr el nombre del programa CGI a ejecutar (campo fichero de la
estructura de peticin).
QUERY_STRING:
contiene todo lo que va detrs del primer carcter ? del URL, si es que hay
algo (campo argumentos de la estructura de peticin). En caso contrario, esta variable de
entorno no debe estar definida.
REMOTE_ADDR:
direccin IP del cliente (campo ip_cliente de la estructura de peticin).

Prctica3pgina5
Curso2014/2015
CONTENT_TYPE:
valor del campo content_type de la estructura de peticin, siempre que no

sea nulo. En caso contrario, esta variable de entorno no debe estar definida.
CONTENT_LENGTH:
longitud del cuerpo asociado a la peticin, siempre que no sea 0 (campo
long_cuerpo de la estructura de peticin). En caso contrario, esta variable de entorno no
debe estar definida.

Cuando el servidor web invoca al programa CGI, se crea un nuevo proceso que es el que ejecuta el
programa CGI. Puesto que crear un nuevo proceso es una operacin costosa (en tiempo y recursos),
la utilizacin de programas CGI puede ser en algunos casos inviable cuando el servidor tiene muchas
peticiones de CGI. Por esta razn y otras, como la facilidad de programacin, es por la que se han
desarrollado tecnologas de generacin dinmica de documentos como PHP, JSP, ASP, .NET,
JAVA, que no necesitan usar programas CGI externos para crear documentos dinmicos.
4.1.5 API para la comunicacin con los clientes web

Con el fin de aislar al estudiante de la problemtica de la comunicacin con los clientes, se dispondr
de una serie de funciones ya codificadas y que se entregan en un fichero objeto denominado http.o
(disponible en el EVA). El estudiante deber enlazarlo con el resto de los ficheros que conformen su
aplicacin, para producir el ejecutable que implementar el servidor web objeto de esta prctica.
La interfaz y la documentacin completa de las funciones de este mdulo se encuentra en el fichero
http.h (disponible en el EVA). Seguidamente se describen brevemente estas funciones:
http_crear: Devuelve una referencia a un gestor de conexiones HTTP (GestorHTTP)
asociado al puerto TCP que recibe como argumento. Se habilita un puerto TCP para recibir
peticiones de conexin provenientes de los procesos cliente.
http_obtener_descriptor_escucha: Obtiene el descriptor de fichero correspondiente al

puerto TCP asociado a un GestorHTTP. Esta funcin se necesitar para alguna de las
mejoras del apartado 4.3.
http_esperar_conexion: Acepta una solicitud de conexin realizada por un cliente. Esta

funcin espera a que se conecte un cliente y, cuando esto sucede, devuelve (parmetro
resultado pasado por referencia) una referencia a una ConexionHTTP (esta estructura de datos
es la que permite al proceso trabajador comunicarse con el cliente).
http_obtener_ip_cliente: Obtiene la direccin IP del cliente. Dada una referencia a una

ConexionHTTP, devuelve una cadena de caracteres con la direccin IP del cliente asociado.
http_obtener_descriptor_conexion: Obtiene el descriptor de la conexin con el cliente.

Devuelve el descriptor de fichero usado para enviar datos al cliente, y que est asociado a la
ConexionHTTP. Es probable que esta funcin no se necesite para esta prctica.
http_leer_peticion: Lee una peticin realizada por un cliente. Dada una ConexionHTTP
usada para comunicarse con un cliente, lee tanto como pueda de la misma y, si tiene
suficientes datos, genera y devuelve (parmetro resultado pasado por referencia) una
referencia a una Peticion. Tiene dos modos de funcionamiento seleccionables mediante el
parmetro de tipo lgico bloqueante. En modo bloqueante, espera hasta recibir una peticin
completa. En modo no bloqueante, si no dispone de una peticin completa en ese momento,
retorna con la indicacin HTTP_SEGUIR_ESPERANDO. En principio, para esta prctica siempre
se usar el modo bloqueante, salvo que se aborden ciertas mejoras del apartado 4.3.
Prctica3pgina6
Curso2014/2015
http_destruir_peticion: Destruye la peticin. Libera la memoria usada por la estructura

de datos asociada a una Peticion.
http_enviar_respuesta: Enva la respuesta al cliente. Dada una ConexionHTTP y el
descriptor de un fichero (o tubera) abierto para lectura, enva al cliente todo lo que lea a
travs de dicho descriptor. El parmetro es_fichero se usa para indicar si el descriptor est
asociado a un fichero o no. Al enviar la respuesta de un CGI, este parmetro deber ser 0 (ya
que el descriptor usado ser una tubera y no un fichero).
http_enviar_codigo: Enva un cdigo de error al cliente. Dada una ConexionHTTP, un
cdigo de error y un mensaje explicativo (descritos en el Apndice B), enva una respuesta de
error al cliente.
http_enviar_html: Enva datos HTML. Dada una ConexionHTTP y una cadena de texto
HTML, la enva al cliente a travs de dicha conexin. Se puede utilizar para implementar la
mejora 4.3.4.
http_cerrar_conexion: Cierra una conexin. Cierra la conexin con el cliente y libera la

memoria ocupada por la ConexionHTTP.
http_destruir: Destruye el GestorHTTP. Finaliza la escucha en el puerto asociado y libera

la memoria ocupada por el GestorHTTP.
La estructura de datos Peticion usada en las funciones anteriores contiene la siguiente informacin:
Direccin IP del cliente (campo ip_cliente).

Recurso solicitado (fichero, directorio o CGI) extrado del URL solicitado el cliente (campo
fichero).
Otros campos que se utilizarn para proporcionrselos al CGI en caso de haberse solicitado
un recurso de este tipo (campos argumentos, content_type, cuerpo y long_cuerpo).
Otros campos de uso interno por parte del mdulo de comunicaciones (http).
4.2 Funciones bsicas obligatorias

El estudiante ha de desarrollar un
bsicas:
servidor web
que realice, al menos, las siguientes funciones
Recoger y procesar los parmetros de invocacin del programa servidor web, descritos en el
apartado 4.1.3.
Responder adecuadamente a las peticiones de documentos estticos que realicen los clientes.
Realizar la gestin de los procesos

4.1.1.
Ejecutar programas externos CGI, tal y como se describe en el apartado
trabajadores,
tal y como se describe en el
Opcionalmente, implementar las mejoras propuestas en el apartado
apartado
4.1.4
4.3.
4.3 Mejoras
En este apartado se proponen una serie de mejoras que se pueden hacer sobre las funciones bsicas
del servidor web. Se valorar positivamente la implementacin de las mejoras. Se recomienda que el
Prctica3pgina7
Curso2014/2015
estudiante explique previamente a su profesor qu mejoras ha escogido y cul es su planteamiento

para realizarlas. Las mejoras propuestas son:
4.3.1 Lmite en el tiempo de ejecucin de los programas CGI

Si el servidor web lanza un programa CGI y ste se mete en un bucle sin fin, un interbloqueo, una
espera indefinida, o cualquier otra situacin similar, esto puede afectar negativamente al servidor, ya
que el proceso trabajador que est esperando a que termine el CGI para devolver la respuesta al
cliente tambin se quedar bloqueado indefinidamente y sin posibilidad de atender a otras peticiones.
Para proteger al servidor web de esta eventualidad, se puede hacer que la espera a que termine el
programa CGI, por parte del proceso trabajador, est acotada a un intervalo de tiempo que se
considere suficiente para la ejecucin de cualquier programa CGI correcto, por ejemplo 60 segundos.
Si se supera ese lmite, el proceso trabajador finaliza el programa CGI y devuelve una respuesta de
error al cliente (un cdigo de error).
4.3.2 Documento por defecto en un directorio

Algunos URL no especifican el recurso que hay que descargar, sino slo un nombre de directorio. En
condiciones normales esto producira un error, ya que no se puede devolver un directorio. Ahora
bien, en estos casos, muchos servidores web buscan ciertos ficheros con nombres predeterminados
en el directorio especificado y, si existen, devuelven el contenido de dichos ficheros. Los nombres de
fichero predeterminado ms habituales son index.html, index.htm o default.htm. En el caso de
no existir estos ficheros predeterminados, podra devolver un documento HTML que contenga un
listado de todos los ficheros y directorios que se encuentran en el directorio solicitado, con enlaces
en sus nombres para poder descargar los recursos o explorar los directorios.
La mejora que se pide para esta prctica es nicamente la de devolver el fichero por defecto, si
existe, cuando un URL no hace referencia a un recurso, sino a un directorio.
4.3.3 Inactividad de un cliente

Si un cliente se conecta al servidor web y deja de enviar o recibir datos, pero sin cerrar la conexin,
el proceso trabajador que lo atiende se queda bloqueado y no atiende a ningn otro cliente. Esto
podra ser usado para un ataque de denegacin de servicio. Para evitarlo, se puede establecer un
lmite de tiempo de inactividad en el cliente, pasado el cual se cierra la conexin, y el proceso
trabajador vuelve a esperar la conexin de nuevos clientes.
4.3.4 Estadsticas del servidor

Algunos servidores web interpretan ciertos URL como rdenes para el propio servidor. Un ejemplo
es un URL como /estadisticas, que puede servir para que el servidor web genere un documento
HTML con informacin estadstica sobre el servidor. Algunos de los datos que puede proporcionar
son: tiempo que lleva en marcha el servidor, tiempo de CPU consumido por todos los procesos del
servidor web, memoria virtual utilizada actualmente por todos los procesos del servidor web, nmero
de clientes y de peticiones atendidas, nmero de peticiones errneas detectadas, etc. El servidor debe
responder a un URL de este tipo generando un documento HTML con los datos solicitados y
envindoselo al cliente.
Prctica3pgina8
Curso2014/2015
4.3.5 Tratamiento de clientes abusivos

Un mismo cliente puede abrir mltiples conexiones simultneas con un servidor web. En ocasiones
puede interesar que se limite la cantidad de conexiones simultneas por cliente, para evitar que un
solo cliente monopolice el servidor. Para esta mejora se propone que el servidor web tenga dos
umbrales de conexiones simultneas desde un mismo cliente. Si se alcanza el primer umbral, las
conexiones posteriores se atienden, pero el proceso que las atiende reduce su prioridad. Si se alcanza
el segundo umbral, no se atienden ms conexiones del mismo cliente y se cierran sin ms. Para esta
mejora ser necesario registrar las direcciones IP desde las que se conectan los clientes.
4.3.6 Mejora a propuesta del estudiante

El estudiante puede proponer cualquier otra mejora que desee, siempre que guarde relacin con los
objetivos principales de la prctica. En este caso obligatoriamente ha de discutirla previamente con el
profesor y obtener su visto bueno.
4.4 Pruebas del servidor Web

A continuacin se comentan algunas de las pruebas que los estudiantes pueden realizar para
comprobar el funcionamiento de su servidor web. No obstante, se recuerda que las pruebas pueden
servir para poner de manifiesto errores, pero nunca para demostrar la correccin del programa. Es
fundamental hacer un diseo meditado y una codificacin cuidadosa para lograr que un programa
funcione correctamente.
4.4.1 Acceso desde un navegador de la mquina anfitriona

La prueba ms evidente consiste en acceder al servidor web desarrollado por el estudiante usando un
navegador web normal y corriente, como pueda ser Firefox, Google Chrome, Internet Explorer, etc.
Para ello, habr que especificar un URL de la forma: http://XXX.XXX.XXX.XXX:PUERTO/RECURSO
donde XXX.XXX.XXX.XXX es la direccin IP de la interfaz em0 de la mquina virtual donde est
corriendo el servidor, PUERTO es el puerto de escucha TCP usado al arrancar el servidor1 y RECURSO es
el recurso que se desea visualizar o descargar.
Por ejemplo, si la IP de su mquina es 192.168.203.131, se decide usar el puerto 50.000, y se
quiere mostrar los recursos que hay en el directorio /usr/share/doc/ntp de la mquina, ejecute el
servidor web con este mandato: ./servidorWeb -p 50000 -b /usr/share/doc/ntp.
Y en un navegador puede visualizar los recursos mediante el url:
http://192.168.203.131:50000/index.html
Es conveniente no elegir un puerto que ya est usando otro programa, por ello se aconseja usar nmeros mayores de
50.000
Prctica3pgina9
Curso2014/2015
Ilustracin1.Recursoindex.htmldeldirectorio/usr/share/doc/ntp
Para facilitar la realizacin de pruebas completas se ha preparado un conjunto de recursos web y

programas CGI de ejemplo que puede ser utilizado directamente por los estudiantes. Estos recursos
se encuentran disponibles a travs del EVA en el fichero pruebas.tgz. Para probar su servidor con
los recursos de prueba, puede copiar el fichero pruebas.tgz a un directorio de su eleccin (por
ejemplo ~/bimestre1), y ejecutar el mandato tar xzpf pruebas.tgz. Con ello se crear la
estructura de directorios y ficheros necesaria para las pruebas, con sus permisos adecuados.
Para probar estos recursos, arranque su servidor web usando el siguiente mandato:
./servidorWeb -p 50000 -b ~/bimestre1/paginas
Y para visualizar los documentos desde un navegador, use este URL:

http://192.168.203.131:50000/index.html
(suponiendo que la direccin IP de su mquina es 192.168.203.131):
Prctica3pgina10
Curso2014/2015
Ilustracin2.Recursoindex.htmlalmostrarlaspginasdeprueba
Por si est interesado, puede encontrar el cdigo fuente de los programas CGI de ejemplo en el EVA
(en el fichero fuentes-cgi.tgz).
Tenga en cuenta que si est usando un navegador que tenga configurado un servidor Proxy, deber
deshabilitarlo para conectarse a su servidor web.
4.4.2 Programa ejemplo.c

En el EVA encontrar el fichero ejemplo.c que le puede servir como base para comenzar la
codificacin de la prctica. Este ejemplo implementa un servidor web monoproceso que atiende una
peticin de un cliente y finaliza. Una vez compilado puede ejecutarlo de la siguiente forma:
./ejemplo -p 50000 -b
Y a continuacin, desde un navegador, solicitar el url:

http://192.168.203.131:50000/basica.htm
Todo ello suponiendo que la direccin IP de la mquina en la que est ejecutando su servidor web es
192.168.203.131, y que existe el fichero basica.htm en el directorio ~/bimestre1/paginas.
El documento Ejemplo.pdf, que puede encontrar en el EVA, describe paso a paso cmo se ha
construido el cdigo de este programa.
4.4.3 Utilizacin del programa de descarga de recursos wget

El programa wget permite descargar recursos web y guardarlos en ficheros. Se usa con frecuencia
para obtener copias locales de documentos HTML y para automatizar accesos a aplicaciones web.
Prctica3pgina11
Curso2014/2015
Es otra posibilidad ms para realizar pruebas con el servidor web de esta prctica, ya que permite
descargar recursos individuales, mientras que un navegador intentar descargar tambin posibles
referencias dentro del documento HTML, como imgenes, etc. Adems, proporciona alguna
informacin un poco ms detallada sobre el resultado de la operacin.
Para ejecutar wget basta con invocarlo (desde una sesin en la mquina FreeBSD) mediante un
mandato similar al siguiente:
wget O fichero_destino http://localhost:PUERTO/recurso
En el mandato anterior, fichero_destino es el fichero donde se quiere guardar el recurso

descargado. Si no se quiere ese recurso para nada, puede especificarse /dev/null para descartarlo.
El programa wget tiene muchas opciones que permiten hacer multitud de pruebas con un servidor
web, por lo que se recomienda al estudiante que consulte su pgina de manual.
Si wget no est instalado en su mquina, podr instalarlo ejecutando el mandato pkg_add r wget
como superusuario. Para ms informacin sobre la instalacin de paquetes de software en FreeBSD,
consulte el manual en lnea de FreeBSD. Recuerde que si la mquina en la que quiere instalar el
nuevo paquete necesita conectarse a Internet a travs de un servidor Proxy, deber configurarlo
adecuadamente.
4.4.4 Pruebas de carga

Las pruebas interactivas con un navegador web no van a producir suficiente carga de trabajo al
servidor web como para comprobar su respuesta frente a una alta intensidad de peticiones. Para
generar una mayor carga de trabajo ha de utilizarse un programa especial, como puede ser
http_load. Este programa tambin se puede descargar e instalar en su mquina FreeBSD mediante
el mandato pkg_add r http_load. Para la instalacin, tenga en cuenta la configuracin de
PROXY como se indica en el apartado 4.4.3.
El programa http_load es capaz de generar una carga arbitraria de peticiones HTTP a un servidor
web. El estudiante puede consultar su pgina de manual para obtener ms detalles, pero en esencia se
le puede indicar a http_load que haga peticiones a una cierta tasa de peticiones/segundo o tambin
que mantenga un ritmo sostenido de una cierta cantidad de peticiones en paralelo. Las peticiones que
hace http_load se escogen aleatoriamente de entre los URL contenidos en un fichero.
Una forma rpida de generar un fichero en el directorio ~/bimestre1 con todos los URL de los
documentos estticos de prueba contenidos en el manual de ntp es la siguiente:
cd /usr/share/doc/ntp
find . type f print |
~/bimestre1/lista-urls.txt
awk
'{
print
"http://localhost:PUERTO/"
$0
}'
>
A continuacin se podra usar http_load de alguna de las dos maneras siguientes:

http_load checksum rate 15 seconds 10 ~/bimestre1/lista-urls.txt
http_load checksum parallel 15 seconds 10 ~/bimestre1/lista-urls.txt
La primera orden especifica una carga de 15 peticiones/segundo durante un total de 10 segundos. La

segunda orden especifica que se mantenga una carga de 15 peticiones en paralelo durante un total de
10 segundos. No olvide ejecutar el servidor con la opcin -b /usr/share/doc/ntp.
Prctica3pgina12
Curso2014/2015
4.4.5 Programa servidor web de prueba

En el EVA encontrar la implementacin de un servidor web, similar al que se le pide en esta
prctica, que puede usar para hacerse una idea de las funcionalidades que debe soportar su servidor.
Su nombre es servidorWeb.
Para probarlo, puede copiarlo a su mquina y ejecutarlo con las opciones especificadas en este
enunciado. Ante cualquier duda, puede invocarlo con la opcin h para obtener informacin acerca
de su funcionamiento. Recuerde comprobar que el programa servidorWeb de ejemplo tenga permiso
de ejecucin despus de copiarlo a su mquina.
4.4.6 Programa verificador del servidor web

En el EVA encontrar un programa llamado verificador, que ejecuta una amplia batera de
pruebas sobre el servidor web. Esto le resultar de mucha ayuda para detectar posibles fallos o
deficiencias de implementacin en su servidor web.
Para saber cmo utilizar el programa verificador, ejectelo sin ms y siga las indicaciones
mostradas en pantalla. Debe ejecutar este programa en la misma mquina que el servidor web cuyo
funcionamiento quiere verificar. No olvide comprobar que el verificador tiene permiso de
ejecucin despus de copiarlo a su mquina. Tenga en cuenta tambin que este programa usa wget
con lo cual debe haber instalado esta aplicacin previamente tal y como se indica en el apartado
4.4.3.
El programa verificador, antes de empezar a hacer las pruebas, comprueba varias cosas necesarias
y, si alguna no se cumple, se detiene (salvo que hayan puesto la opcin -s) y avisa al usuario. Las
comprobaciones que realiza, entre otras, son:
Que no haya procesos servidorWeb en ejecucin (que seran de pruebas anteriores y pueden
confundir al verificador).
Que existan diversos ficheros en el directorio de las pginas que luego va a usar en las
pruebas y que tengan los permisos esperados en cada caso.
Que est instalado el programa wget.
4.4.7 Programa comprobador de las entregas

En el EVA encontrar un programa llamado comprobar-entrega, que comprueba que el fichero a
subir al EVA cumple con los requisitos de la entrega, para que pueda validarlo antes de subirlo.
5 Fases de realizacin de la prctica

Se recomienda al estudiante ser constante en la realizacin de esta prctica y que reparta el trabajo
adecuadamente. Para ello, se propone una separacin de la prctica en fases, a ttulo orientativo.
Si el estudiante disea y estructura adecuadamente su programa, el paso de una fase a la siguiente
apenas requerir modificaciones en lo ya completado, y nicamente habr que aadir las nuevas
funcionalidades. Se recomienda consultar los sucesivos diseos con el profesor de laboratorio.
5.1 Fase 1. Duracin: de una a dos semanas

Durante la primera fase, el estudiante debe desarrollar un servidor web monoproceso que solamente
sea capaz de servir ficheros estticos. Esto le servir para tomar contacto con la prctica y para
Prctica3pgina13
Curso2014/2015
asegurarse de que sabe manejar adecuadamente la API de comunicaciones HTTP con los clientes.
Evidentemente, este servidor no ser capaz de atender ms que una conexin en cada momento.
Adems, debe realizar el procesamiento completo de los parmetros de configuracin del servidor, e
incluir la gestin de las seales SIGTERM y SIGINT para poder terminar ordenadamente la ejecucin
del servidor web.
A continuacin se muestra un seudocdigo orientativo para la resolucin de esta fase:
Procesar los parmetros de configuracin
Establecer las rutinas de tratamiento de las seales
Crear gestorHTTP ( in puerto ) -> GestorHTTP
Repetir
Esperar conexin de cliente ( in gestorHTTP, out cliente )
Leer peticin ( in cliente, out peticin )
Procesar documento esttico ( in cliente, in peticin )
Destruir peticin ( in peticin )
Cerrar conexin ( in cliente )
Hasta final de programa
Destruir gestorHTTP ( in GestorHTTP )
Procesar documento esttico ( in cliente, in peticin ):

fich = Abrir fichero ( in peticin->fichero )
Si fich == -1 /* Error al abrir el fichero */
Enviar cdigo de error ( in cliente, in 401|402|403 )
Si no
Enviar respuesta ( in cliente, in peticin, in fich )
Cerrar fichero ( in fich )
Fin si
El seudocdigo anterior cierra la conexin con el cliente tras servir una sola peticin. Esto no es muy
eficiente, ya que obliga a abrir una conexin nueva por cada recurso que haya que descargar, y
muchos documentos pueden desencadenar la solicitud de decenas o incluso cientos de recursos
adicionales. No obstante, ser suficiente para esta primera fase puesto que, al tratarse por el momento
de un servidor monoproceso, es incapaz de manejar varias conexiones en paralelo. Hay que tener en
cuenta que algunos agentes de usuario abren varias conexiones simultneas para descargar en
paralelo los recursos de un solo documento. Si el servidor slo es capaz de manejar una conexin en
cada momento y no la cierra despus de atender una nica peticin, esos agentes de usuario no seran
capaces de descargar completamente los documentos. En el momento en el que se pase al servidor
multiproceso, se modificar el seudocdigo anterior para procesar ms de una peticin en cada
conexin.
Obsrvese que, por simplicidad, ni en el seudocdigo propuesto para esta fase ni en los de las dems
fases se explicita en profundidad el tratamiento de los diversos errores y situaciones excepcionales
que pueden producirse durante la ejecucin del programa. No obstante, en su programa, el estudiante
debe detectar y tratar adecuadamente todos esos errores y situaciones excepcionales.
En este seudocdigo, el proceso permanece en un bucle hasta final de programa. Ese final de
programa se producir cuando el proceso reciba la seal SIGTERM o la seal SIGINT. El manejador
asociado a estas seales deber modificar la variable de control de dicho bucle. Tenga en cuenta que,
si se recibe una seal mientras las funciones http_esperar_conexion() o http_leer_peticion()
estn bloqueadas a la espera de recibir una solicitud de conexin o de leer una peticin, estas
funciones retornarn inmediatamente con el cdigo HTTP_ESPERA_INTERRUMPIDA. Obviamente, en
este caso no habr cliente que atender ni peticin que procesar.
Prctica3pgina14
Curso2014/2015
Para probar esta fase se recomienda que el estudiante pruebe a solicitar el recurso
directorio pginas.
basica.htm
del
Ilustracin3.Recursobasica.htmldelaspginasdeprueba
Documentacin a presentar: Cdigo fuente del programa.
5.2 Fase 2. Duracin: de una a dos semanas

En la segunda fase, se puede aadir la capacidad de ejecutar programas CGI al servidor realizado en
la fase anterior, mantenindolo an como un servidor con un slo proceso maestro (ms el proceso
hijo que ejecute el programa CGI). De esta forma, se aprender a crear nuevos procesos para ejecutar
programas externos, a duplicar descriptores y redirigir la entrada/salida, y a manipular variables de
entorno.
A continuacin se muestra un seudocdigo orientativo para la resolucin de esta fase, resaltando en
negrita las modificaciones con respecto al seudocdigo propuesto para la fase anterior:
Establecer las rutinas de tratamiento de las seales
Repetir
Si peticin es CGI
Procesar CGI ( in cliente, in peticin )
Si no
Fin si
Procesar_CGI ( in cliente, in peticin ):
Crear tubera_p-h /* para enviar informacin del padre al hijo */
Crear tubera_h-p /* para enviar informacin del hijo al padre */
Switch ( fork() )
Case Padre:
Si peticin->cuerpo no es nulo
Prctica3pgina15
Curso2014/2015
Escribir cuerpo en tubera_p-h

Fin si
Cerrar tubera_p-h
Enviar respuesta ( in cliente, in peticin, in tubera_h-p)
Esperar la terminacin del programa CGI
Case Hijo:
Establecer variables de entorno
Redirigir su entrada estndar a la tubera_p-h
Redirigir su salida estndar a la tubera_h-p
Ejecutar programa CGI
Si llega aqu, enviar cdigo de error al cliente y terminar
End Switch
Para que las tuberas funcionen correctamente, tanto el proceso padre como el proceso hijo deben
cerrar los extremos de las tuberas que no usan para nada. Esto no ha sido incluido en el seudocdigo
anterior. Adems, una vez que las tuberas han cumplido su funcin, deben cerrarse todos sus
descriptores asociados, puesto que en caso contrario el servidor podra quedarse sin descriptores para
poder abrir nuevos ficheros o tuberas, con lo que no podra seguir atendiendo peticiones. Ser labor
del estudiante determinar en qu puntos de su programa hay que realizar estas operaciones.
Para probar esta fase se recomienda que el estudiante abra los recursos de tipo CGI accesibles a
partir del recurso CGIs.html del directorio de pginas proporcionado.
Ilustracin4.ResultadoobtenidotraspulsarelenlaceCGIbsicoenelrecursoCGIs.htm
Prctica3pgina16
Curso2014/2015
Ilustracin5.ResultadoobtenidotraspulsarelenlaceCGIquemuestralasvariablesdeentornoenelrecursoCGIs.htm
Documentacin a presentar: Cdigo fuente del programa.
5.3 Fase 3. Duracin: dos semanas

En la tercera fase, se convertir el programa en un servidor multiproceso que satisfaga todos los
requisitos bsicos indicados en el apartado 4.2. En esencia, el servidor tendr dos secuencias de
ejecucin diferentes: por un lado estar el cdigo que ejecutan los procesos trabajadores, que
bsicamente coincidir con lo realizado en las fases anteriores (salvo que ya no se cerrar la
conexin con el cliente tras procesar una sola peticin, sino cuando lo decida el cliente), y por otro
lado aparecer como novedad la tarea de vigilancia de los trabajadores, que la realizar el proceso
maestro. Adems, ser necesario introducir una estructura de datos en memoria compartida que sirva
para que los procesos trabajadores comuniquen su estado al proceso maestro. Cuando el maestro crea
los trabajadores, los crea en el estado INACTIVO. Los trabajadores pasarn al estado ACTIVO
cuando tengan establecida una conexin con un cliente, y volvern al estado INACTIVO cuando el
cliente cierre la conexin. Cuando el maestro reciba la seal de terminacin de los trabajadores y
constate su finalizacin, marcar la entrada correspondiente de la tabla de trabajadores como
NOUSADO.
A continuacin se muestra un seudocdigo orientativo del programa principal, que crea los procesos
trabajadores, y a continuacin se comporta como proceso maestro:
Establecer las rutinas de tratamiento de las seales (adems SIGCHLD)
Crear tabla de trabajadores en memoria compartida
Marcar todas las posiciones de la tabla de trabajadores como NOUSADO
Crear Pini trabajadores
Repetir
Sleep(1)
Contar trabajadores inactivos /* en estado INACTIVO */
Si cuenta > Pinact_max
Prctica3pgina17
Curso2014/2015
Enviar SIGTERM a (cuenta Pinact_max) trabajadores inactivos

Si no Si cuenta < Pinact_min
Crear (Pinact_min cuenta) trabajadores, respetando el lmite Pmax
Fin si
Enviar a todos los trabajadores la seal de terminacin
Esperar a que todos los trabajadores hayan terminado su ejecucin
El seudocdigo orientativo para los trabajadores sera el presentado a continuacin. Es anlogo al ya

desarrollado para la fase anterior, aunque se ha modificado para procesar ms de una peticin en una
misma conexin y para actualizar el estado del trabajador en la tabla compartida con el proceso
maestro. No se ha considerado el control de los errores que pueden generar las funciones del mdulo
http, para simplificar los algoritmos. En negrita se resaltan las novedades:
Ajustar los manejadores de las seales
Repetir
Marcar mi posicin en la tabla de trabajadores como ACTIVO
Repetir
Si peticin es CGI
Procesar_CGI(in cliente, in peticin)
Si no
Fin si
Hasta que el cliente se desconecte o me ordenen terminar
Marcar mi posicin en la tabla de trabajadores como INACTIVO
Hasta que me ordenen terminar
El ajuste de los manejadores de las seales puede ser necesario porque el proceso trabajador heredar
los ajustes del maestro y stos podran no ser los adecuados para el trabajador. En concreto:
El trabajador no tiene que procesar SIGINT, ya que eso lo hace el maestro.
La respuesta a SIGTERM tambin es diferente, ya que el maestro tiene que pedir a todos los
trabajadores que terminen, mientras que el trabajador tiene que terminar su ejecucin tras
procesar la peticin actual (si la hubiere). Ahora bien, el manejador de la seal en s podra
ser el mismo si lo nico que hace es cambiar el valor de la variable de control del bucle
principal del proceso.
El procesamiento de SIGCHLD tambin es diferente, puesto que en el maestro hay que
marcar que el trabajador que ha terminado ya no existe, mientras que en el trabajador esta
seal slo se recibe cuando termina un proceso hijo que se ha creado para ejecutar un CGI.
Tngase en cuenta que, para indicar a un trabajador que debe finalizar su ejecucin, el proceso padre
le enva la seal SIGTERM. El trabajador, al recibirla, tomar nota de que debe terminar su ejecucin
cuando concluya el procesamiento de la peticin actual.
Adems, hay que determinar cmo se actualiza la tabla de trabajadores para reflejar la creacin y la
terminacin del proceso trabajador. El paso de NOUSADO a INACTIVO lo podra hacer el proceso
trabajador cuando comienza su ejecucin, pero eso puede generar condiciones de carrera con el
maestro. Por tanto, es conveniente que el maestro lo marque como INACTIVO justo antes de crearlo.
Prctica3pgina18
Curso2014/2015
Si por alguna razn, la creacin del trabajador fallara, el maestro debera volver a marcarlo como
NOUSADO. El paso de INACTIVO a NOUSADO podra hacerlo el trabajador justo antes de terminar, o el
proceso padre cuando recibe la seal SIGCHLD que le indica que un hijo ha terminado. Se recomienda
que sea el maestro el que lo haga (as tambin se marcaran como no usadas las posiciones de los
trabajadores que mueran abruptamente por cualquier motivo).
El maestro necesita conocer el PID de los procesos trabajadores para poder mandarles la seal de
terminacin. Hay que tener en cuenta posibles condiciones de carrera si un trabajador termina
prematuramente (antes de que se haya anotado su PID). Si el maestro recibe la seal SIGCHLD de un
trabajador y trata de localizar la entrada correspondiente de la tabla de trabajadores para marcarla
como NOUSADO, podra no encontrarla (porque an no se haya anotado su PID). Por tanto, habr que
garantizar que esto no ocurre. Una posibilidad es evitar que se procese la seal SIGCHLD hasta que el
PID del nuevo trabajador haya sido anotado (usando sigprocmask(2)).
Se recomienda que los trabajadores ignoren la seal de terminacin de los procesos que ejecutan los
programas CGI, y que sincronicen con ellos directamente, antes de pasar a atender una nueva
peticin. De esta forma, pueden detectar fallos en la ejecucin de los CGI, para avisar al cliente en
esos casos.
Cuando el maestro se entera de que le ha llegado la seal SIGCHLD y pasa a ejecutar la rutina de
atencin correspondiente, puede ser que hayan terminado varios procesos hijos antes de que se
ejecute su rutina de atencin, por lo que deber sincronizar con todos los hijos que estn pendientes
de sincronizar, para evitar que se queden zombis, y para anotar correctamente su estado en la tabla.
Obsrvese que en esta fase ya no hay problemas con los agentes de usuario que abren mltiples
conexiones simultneas con el servidor, ya que el servidor es capaz de atender varias conexiones a la
vez, usando, para ello, varios trabajadores en paralelo. NOTA: si el nmero mximo de procesos
trabajadores es demasiado bajo (menos de 4), s podra haber problemas con esos agentes de usuario.
Por ejemplo, podra verse que, al abrir un documento web con muchas imgenes en un navegador
web, se cargan rpidamente algunas imgenes, mientras que otras tardan mucho ms en cargarse.
5.4 Fase 4. Duracin: una semana

Esta fase final es opcional y se tendr en cuenta para la calificacin de la prctica. El estudiante ha
de escoger una o varias de las mejoras propuestas en el apartado 4.3, e implementarla en su servidor
web. Se recomienda que haga una valoracin previa de lo que cada una de ellas podra suponer, a fin
de escoger la que le resulte ms interesante y ms conveniente de realizar. Tambin se puede
proponer al profesor alguna mejora no recogida en este documento.
Documentacin a presentar: Cdigo fuente del programa junto con un documento que indique qu
mejora opcional se ha realizado.
Prctica3pgina19
Curso2014/2015
Apndice A : Introduccin a las tecnologas web

En su forma ms sencilla, un servidor web es una aplicacin que permite descargar recursos
mediante el protocolo HTTP. La mayora de esos recursos son documentos en formato HTML que
describen la informacin a presentar al usuario final, por lo general estos documentos contienen
referencias a otros tipos de recursos como imgenes, vdeo, hojas de estilo, documentos en lenguaje
de script, documentos PDF, etc., que tambin se pueden descargar del servidor web. Por lo general,
los documentos HTML en cuestin han sido generados de antemano mediante un programa de
edicin de pginas web, o son generados dinmicamente mediante un generador de contenidos u otro
tipo de generacin de contenidos dinmicos, y los recursos referenciados se han almacenado en
algn directorio de la mquina donde se ejecuta el servidor web.
Normalmente, los navegadores web descargan primero el documento que contiene la descripcin de
la pgina en HTML, lo interpretan y, si en l figuran referencias a otros recursos, entonces los
descargan del servidor web. Finalmente, componen con todo ello la imagen que aparece en la
pantalla del cliente. Como es bien sabido, en los documentos HTML tambin pueden aparecer
referencias a otros recursos que no son descargados automticamente sino que se encuentran
accesibles a travs de mecanismos de navegacin (hiperenlaces o hipervnculos). Estos mecanismos
desencadenarn una peticin sobre el servidor correspondiente si el usuario hace clic sobre el
hiperenlace en cuestin.
Por ejemplo, si un usuario utiliza un navegador web para solicitar un recurso con URL
http://www.w3c.es/index.html, el navegador se conecta a la mquina www.w3.org y, mediante
el protocolo HTTP, le pide el fichero /index.html. El servidor web comprueba si existe dicho
documento en su directorio raz y, en caso afirmativo, se lo transmite al cliente como respuesta a su
peticin. En caso negativo, enva un cdigo de error.
Si en el documento anterior figuran referencias a imgenes, por ejemplo a /img/2010/logo-w3cmobile-lg, el navegador, seguidamente, pide al servidor web el documento correspondiente, para
situarlo en la posicin adecuada de la pgina.
A veces, el servidor web procesa de manera especial algunos URL que no corresponden a ficheros
existentes. Por ejemplo, si el cliente solicita abrir el URL http://www.w3c.es/Consorcio y resulta
que Consorcio es un directorio y no un recurso, el servidor web asume que el cliente est solicitando
el fichero por defecto index.html que haya en ese directorio, es decir, /Consorcio/index.html.
Lo que se ha explicado anteriormente corresponde a los denominados documentos estticos. Existen
URL que apuntan a lo que se denominan documentos dinmicos o CGI, es decir, no apuntan explcita
o implcitamente a un documento existente, sino que hacen que el servidor ejecute un programa
externo que genera, por su salida estndar, unos datos que han de llegar al cliente. Lgicamente el
documento que genera se corresponde con un recurso web, por lo que el cliente visualizar,
reproducir o descargar dicho recurso sin apreciar ninguna diferencia por el hecho de que ste haya
sido generado por un programa. Como a cualquier programa, a un CGI se le pueden pasar diferentes
argumentos para que personalice el recurso generado. Por ejemplo, si un cliente solicita el URL
http://www.utpl.edu.ec/cgi/calificaciones?cedula=12345678&materia=232, el servidor
web ejecuta el programa calificaciones, pasndole un argumento de nombre cedula con el valor
12345678 y otro argumento de nombre materia con el valor 23. Se supone que el programa har
algo con dichos argumentos (en este caso, quiz busque en una base de datos la calificacin del
Este URL es slo un ejemplo, no se encuentra disponible.
Prctica3pgina20
Curso2014/2015
estudiante cuyo nmero de cdula es 12345678 en la materia cuyo cdigo es el 23) y finalmente
generar un documento con la informacin resultante en formato HTML, la cual se enviar como
respuesta al cliente. Este documento dinmico podra hacer referencia a otros recursos grficos, de
audio, etc., los cuales descargara el cliente en cuanto interpretara el documento HTML. Existen dos
mtodos alternativos de invocar a los programas CGI, llamados GET y POST.
Existen otras muchas tecnologas que permiten generar recursos dinmicos, como PHP, JSP, ASP,
.NET, JAVA, etc., que simplemente se mencionan a ttulo informativo, ya que no se van a tener en
cuenta en esta prctica.
Los recursos dinmicos son muy tiles en combinacin con los formularios. Un formulario es un
elemento que puede aparecer en un documento HTML y que describe diversos elementos de entrada
que el usuario puede completar, como cajas de texto, listas desplegables, botones de radio, etc. As
mismo, el formulario puede proporcionar algn elemento de accin (botn, imagen, etc.) que, al ser
pulsado por el usuario, hace que el navegador enve a un determinado URL del servidor los valores
introducidos o seleccionados en el formulario como argumentos de la peticin. Ese URL deber ser
un programa CGI, que recoger los argumentos enviados para procesarlos y generar un recurso como
respuesta al cliente.
El URL http://www.utpl.edu.ec/cgi/calificaciones?cedula=12345678&materia=23, usado
como ejemplo anteriormente, podra haberse generado cuando el usuario ha pulsado el botn de
enviar de un formulario que contena una caja de texto llamada cdula en la que haba introducido
la cadena 12345678 y una lista desplegable en la que haba seleccionado la materia Arquitectura y
Computacin Paralela, cuyo cdigo numrico resulta ser el 23.
Los clientes web envan sus peticiones y reciben sus respuestas por medio del protocolo HTTP, cuya
versin ms reciente, HTTP/1.1, se encuentra especificada en la RFC 2616. A grandes rasgos, un
cliente abre una conexin TCP con el servidor web y entonces entra en un bucle de envo de una
peticin (generalmente el mtodo GET) y recepcin de una respuesta. Este bucle se repite hasta que,
bien el cliente, o bien el servidor, deciden cerrar la conexin. Obsrvese que, a travs de una misma
conexin, el cliente no enva una nueva peticin hasta haber recibido la respuesta de la peticin en
curso. Obsrvese, tambin, que un agente de usuario, podra crear varios clientes para abrir varias
conexiones simultneas con el servidor con el fin de hacer varias peticiones en paralelo.
Prctica3pgina21
Curso2014/2015
Apndice B : Cdigos de error

En el protocolo HTTP, toda respuesta de un servidor web debe incluir un cdigo de estado que indica
el resultado de la solicitud HTTP del cliente, descritos en la RFC 2616 del protocolo HTTP. De
manera resumida, el cdigo puede ser de xito (cdigo 200) o de error (cdigos 4XX y 5XX).
El estudiante no debe preocuparse de enviar el cdigo de xito (cdigo 200) en las peticiones
satisfactorias, puesto que ya lo hace automticamente la biblioteca de funciones suministrada. En
cambio, cuando el servidor web del estudiante detecte algn problema que impida responder
satisfactoriamente a una peticin, debe responderse con un cdigo de estado apropiado usando la
funcin http_enviar_codigo de la biblioteca de funciones suministrada.
En este apndice nicamente se tratarn los principales cdigos de estado correspondientes a
problemas que tiene el servidor web para atender una solicitud realizada por un cliente, y que son
suficientes para realizar la prctica. Cuando se da esta situacin, el servidor debe enviar al cliente un
cdigo de error numrico, un mensaje y, opcionalmente, una pgina web con informacin de la causa
del error.
Los cdigos de error ms comunes, junto con un posible mensaje explicativo son:
400 Bad Request. El servidor web no pudo entender la solicitud debido a errores de sintaxis
en la peticin.
403 Forbidden. El servidor entendi la solicitud pero no la va a atender. Un caso tpico de
este error sera cuando el URL solicitado corresponde a un directorio y no a un recurso, en

ese directorio no se encuentra la pgina por defecto y el servidor no permite listar directorios.
Tambin puede deberse a que se ha solicitado un recurso para el que no se tiene permiso de
lectura.
404 Not Found. El servidor no ha encontrado el recurso correspondiente al URL solicitado.
Este error puede deberse a un error de ortografa o de sintaxis en el URL o que se trate de un
recurso que ya no existe en el servidor.
405 Method Not Allowed. El mtodo especificado en la solicitud no se permite para el recurso
solicitado. Este error ocurre por ejemplo cuando se hace una peticin POST y el servidor web
solamente permite peticiones GET para el tipo de archivo correspondiente al URL solicitado.
408 Request Timeout. El servidor recibi una solicitud de conexin de un cliente, pero ste no
lleg a enviar una peticin en el tiempo que el servidor esperaba.
500 Internal error. Ocurri un problema no especificado en el servidor, como falta de
memoria, estructuras de datos corruptas, etc.
Prctica3pgina22
Curso2014/2015
Apndice C : Principales pginas de manual de inters

A continuacin se enuncian algunas de las pginas de manual de FreeBSD ms relevantes que el
estudiante tendr que consultar para realizar la prctica. Para ms informacin sobre ellas, consltese
la correspondiente pgina de manual y la informacin proporcionada en clase.
Pginas de manual para las funciones obligatorias:
fork(2): crea un proceso nuevo.

exec(3): familia de funciones que permiten ejecutar programas.
exit(3): finaliza un proceso.
_exit(2): finaliza un proceso.
kill(2), killpg(2): envan una seal a un proceso o a un grupo de procesos.
signal(3): captura una seal.
sigaction(2): examinar y modificar las acciones a realizar al recibir una seal.
sigprocmask(2): examinar y modificar las seales bloqueadas.
sigsuspend(2): espera inactiva hasta que se reciba una seal.
sigemptyset(3), sigfillset(3), sigaddset(3), sigdelset(3), sigismember(3):
funciones POSIX para manipular conjuntos de seales.
mmap(2): crea zonas de memoria virtual compartida.
open(2): abre un fichero.
read(2), write(2): lee o escribe en un descriptor de E/S.
close(2): cierra un descriptor de E/S.
pipe(2): crea una tubera.
dup(2), dup2(2): duplican un descriptor de E/S. Se suelen utilizar para redireccionar la
entrada o la salida de un proceso.
wait(2), waitpid(2), wait4(2), wait3(2): familia de llamadas al sistema para esperar
y recoger informacin sobre los procesos hijos que han finalizado.
sleep(3): detiene un proceso durante el tiempo especificado.
getenv(3), setenv(3): permiten consultar y modificar variables de entorno.
gethostname(3): permite obtener el nombre de la mquina en la que se ejecuta el programa.
getopt(3), getopt_long(3): analizan los argumentos de invocacin de un programa.
errno(2): variable en la que las llamadas y funciones del sistema devuelven un cdigo
explicativo en caso de error.
stat(2), fstat(2): obtienen informacin sobre los atributos de un fichero.
Pginas de manual para las mejoras:
getpriority(2), setpriority(2): obtienen o cambian la prioridad de un proceso.

getrusage(2): devuelve informacin sobre los recursos consumidos por un proceso.
select (2): permite que un proceso de usuario solicite al kernel la espera de algunos
eventos determinados, reanudndose la ejecucin de dicho proceso nicamente cuando se

produzca alguno de ellos.
setitimer(2), alarm(3): pone en marcha un temporizador.
El mdulo http que se proporciona, ya codificado, al estudiante para gestionar las comunicaciones
con los clientes tambin hace uso de otras llamadas al sistema como, por ejemplo, socket(2),
bind(2), listen(2), accept(2), recv(2), send(2), setsockopt(2), fcntl(2) y shutdown(2).
Prctica3pgina23

Aplicacion Multiproceso

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aplicacion Multiproceso

Diunggah oleh

Hak Cipta:

Format Tersedia

ArquitecturayComputacinParalela

Aplicacin Multiproceso sobre HTTP

Documentacin a entregar: Se deber entregar el programa codificado en lenguaje C, debidamente

4.1 Descripcin del servidor web multiproceso

4.1.1 Gestin de los procesos en el servidor web multiproceso

cuestin. Cuando se cierre la conexin, el trabajador terminar su ejecucin. El inconveniente de

El servidor constar de un proceso maestro y un nmero variable de procesos trabajadores.

El proceso maestro vigilar peridicamente el estado de los procesos trabajadores y crear o

Los procesos trabajadores estarn en un bucle en el que esperarn a que se conecte un

Inicialmente, el proceso maestro crear un nmero Pini de procesos trabajadores.

Si el proceso maestro detecta que han quedado ms de Pinact_max procesos trabajadores

4.1.2 Comunicacin entre los procesos del servidor web

Los procesos trabajadores han de indicar su estado (activo o inactivo) al proceso

A veces, el proceso maestro ha de ordenar a los procesos trabajadores inactivos que

4.1.3 Parmetros del servidor web

Valores relacionados con el control del nmero de procesos trabajadores, ya comentados

Informacin de depuracin (opcin [debu]g). Permite elegir entre mostrar informacin

4.1.4 Ejecucin de programas CGI

El programa CGI ha de recibir por su entrada estndar el cuerpo asociado a la peticin, si no

El servidor web ha de proporcionar al programa CGI ciertos valores de contexto mediante

nombre de la mquina donde se ejecuta el servidor. Se puede obtener mediante

siempre tendr el valor "CGI/1.1".

siempre tendr el valor "HTTP/1.1".

valdr "GET" o "POST", dependiendo del mtodo utilizado en esta peticin

direccin IP del cliente (campo ip_cliente de la estructura de peticin).

valor del campo content_type de la estructura de peticin, siempre que no

longitud del cuerpo asociado a la peticin, siempre que no sea 0 (campo

long_cuerpo de la estructura de peticin). En caso contrario, esta variable de entorno no

debe estar definida.

4.1.5 API para la comunicacin con los clientes web

http_crear: Devuelve una referencia a un gestor de conexiones HTTP (GestorHTTP)

http_obtener_descriptor_escucha: Obtiene el descriptor de fichero correspondiente al

http_esperar_conexion: Acepta una solicitud de conexin realizada por un cliente. Esta

http_obtener_ip_cliente: Obtiene la direccin IP del cliente. Dada una referencia a una

http_obtener_descriptor_conexion: Obtiene el descriptor de la conexin con el cliente.

http_destruir_peticion: Destruye la peticin. Libera la memoria usada por la estructura

http_enviar_respuesta: Enva la respuesta al cliente. Dada una ConexionHTTP y el

http_enviar_codigo: Enva un cdigo de error al cliente. Dada una ConexionHTTP, un

http_cerrar_conexion: Cierra una conexin. Cierra la conexin con el cliente y libera la

http_destruir: Destruye el GestorHTTP. Finaliza la escucha en el puerto asociado y libera

Direccin IP del cliente (campo ip_cliente).

4.2 Funciones bsicas obligatorias

que realice, al menos, las siguientes funciones

Realizar la gestin de los procesos

Ejecutar programas externos CGI, tal y como se describe en el apartado

tal y como se describe en el

Opcionalmente, implementar las mejoras propuestas en el apartado

estudiante explique previamente a su profesor qu mejoras ha escogido y cul es su planteamiento

4.3.1 Lmite en el tiempo de ejecucin de los programas CGI

4.3.2 Documento por defecto en un directorio

4.3.3 Inactividad de un cliente

4.3.4 Estadsticas del servidor

4.3.5 Tratamiento de clientes abusivos

4.3.6 Mejora a propuesta del estudiante

4.4 Pruebas del servidor Web

4.4.1 Acceso desde un navegador de la mquina anfitriona

Para facilitar la realizacin de pruebas completas se ha preparado un conjunto de recursos web y

Y para visualizar los documentos desde un navegador, use este URL:

(suponiendo que la direccin IP de su mquina es 192.168.203.131):

4.4.2 Programa ejemplo.c

Y a continuacin, desde un navegador, solicitar el url:

4.4.3 Utilizacin del programa de descarga de recursos wget

En el mandato anterior, fichero_destino es el fichero donde se quiere guardar el recurso

4.4.4 Pruebas de carga