(P10): Prácticas de Diseño Segundo Semestre Curso 2012/2013

SO #2013/1
Sistemas Operativos
(P10): Prácticas de
Diseño
Segundo Semestre
Curso 2012/2013
Angel Rodríguez
Índice
1. Información general sobre las prácticas 3
1.1. Valoración de cada ejercicio . . . . . . . . . . . . . 3
1.2. Ejercicio presencial . . . . . . . . . . . . . . . . . . 3
2. Descripción general de los ejercicios de prácticas de
diseño 5
2.1. Ejercicios a realizar . . . . . . . . . . . . . . . . . . 5
2.2. Tutorías y consultas . . . . . . . . . . . . . . . . . 5
2.3. Notación . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Apertura de cuenta . . . . . . . . . . . . . . . . . . 6
2.5. Código fuente de apoyo . . . . . . . . . . . . . . . 6
2.6. Protección frente a copias . . . . . . . . . . . . . . 7
2.7. Normas de presentación de los ejercicios . . . . . . 8
2.8. Entrega de los ejercicios . . . . . . . . . . . . . . . 9
2.9. Plazos de entrega . . . . . . . . . . . . . . . . . . . 10

SO #2013/1 Revisión 12.1
3. Busca - Herramienta de selección de archivos 11
3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Descripción . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Acciones del mandato . . . . . . . . . . . . . . . . 13
3.4. Páginas del Manual a Consultar . . . . . . . . . . . 21
4. Cargador - Herramienta para la carga de módulos
dinámicos 23
4.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Descripción . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Acciones del mandato . . . . . . . . . . . . . . . . 25
4.4. Páginas del manual a consultar . . . . . . . . . . . 38
5. Servidor - Implementación del servidor de un
pseudo-FTP 40
5.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . 40
5.2. Descripción . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Apartados . . . . . . . . . . . . . . . . . . . . . . . 40
5.4. Páginas del manual a consultar . . . . . . . . . . . 46
Registro de Revisiones 47
(2)

01/02/2013 SO #2013/1
1. Información general sobre las prácticas
La parte de prácticas de diseño de SSOO (P10) consiste en una
batería de ejercicios independientes que se deben programar en
C sobre UNIX. Dichos ejercicios consisten en mandatos sencillos
cuyo funcionamiento se detalla en este documento.
1.1. Valoración de cada ejercicio
Cada ejercicio se valora de forma independiente según la siguiente
tabla:
Cuadro 1: Tabla resumen de ejercicios a realizar
Ejercicio Puntos máximos Puntos mínimos
busca 35 0
cargador 55 0
servidor 30 0
presencial 10 5
Cada ejercicio dispone de un corrector asociado que devuelve un
valor con los puntos alcanzados en ese ejercicio así como la traza
de la corrección. Esta traza será la referencia que se debe utilizar
para depurar el código fuente.
La nota total obtenida en prácticas se calcula como el total de puntos
obtenidos ponderados según lo establecido en el “Cuaderno de
Normas” de esta asignatura. Para superar las prácticas de diseño
habrá pues que superar los puntos mínimos de cada ejercicio, y
además la nota total obtenida deberá alcanzar el mínimo compensable
indicado en el “Cuaderno de Normas” de esta asignatura.
1.2. Ejercicio presencial
Una vez finalizados los plazos de entrega de los diferentes ejercicios
prácticos, se procederá a la realización de un ejercicio más, de
(3)

SO #2013/1 Revisión 12.1
carácter presencial, en el cual se exigirá sacar la nota mínima recogida
en la tabla anterior. Sólo se podrán presentar a este ejercicio
aquellos alumnos que hayan alcanzado con los demás ejercicios nota
suficiente para poder aspirar a superar el mínimo compensable.
El profesorado de la asignatura podrá decidir eximir de la realización
de la prueba a aquellos alumnos de los que tenga constancia
que durante el curso han realizado un buen aprovechamiento de
los ejercicios prácticos de diseño.
(4)

01/02/2013 SO #2013/1
2. Descripción general de los ejercicios de prácticas de
diseño
2.1. Ejercicios a realizar
La práctica de diseño consiste en la siguiente batería de ejercicios:
➀ busca: Utilidad para buscar contenidos en el árbol de directorios.
➁ cargador: Utilidad para gestionar la carga dinámica de un
plugin y controlar la ejecución de instancias del mismo.
➂ servidor: Implementación de un servidor reducido de un protocolo
pseudo-FTP en base a sockets.
➃ ejercicio presencial: Este ejercicio se realizará de forma
presencial.
2.2. Tutorías y consultas
Los profesores encargados de esta práctica y su dirección de correo
son:
Angel Rodríguez
2.3. Notación
A lo largo del enunciado de los diferentes ejercicios se usará la
siguiente notación:
texto Secuencia de caracteres proporcionada por el usuario.
texto Salida generada por el programa por su salida estándar.
texto Salida generada por el programa por su error estándar.
✿✿✿✿✿✿✿
(5)

SO #2013/1 Revisión 12.1
Importante: Sea muy cuidadoso en lo correspondiente
a entradas y, sobre todo, salidas del
programa. La corrección automática buscará una
salida determinada y concreta en cada prueba de
ejecución de los programas.
2.4. Apertura de cuenta
Para la entrega de las prácticas, cada alumno debe abrir cuenta
en la máquina UNIX denominada triqui(1, 2, 3 ó 4), para lo
cual, el interesado deberá acudir al Centro de Cálculo con un justificante
de estar matriculado en la asignatura.
Es obligatoria la entrega de las prácticas desde la máquina asignada
por el Centro de Cálculo. Sin embargo, para la realización de
las mismas es posible utilizar otras máquinas o realizar las mismas
desde casa. La entrega obligatoriamente se debe hacer desde
triqui(1, 2, 3 ó 4).
Importante: Los horarios concretos de acceso a
las máquinas serán gestionados por el Centro de
Cálculo
2.5. Código fuente de apoyo
Normalmente, para la realización de cada ejercicio práctico,
no se partirá de cero, sino de un determinado material de
apoyo. Este material podrá obtenerse desde la página web
de la asignatura http://laurel.datsi.fi.upm.es/docencia/
asignaturas/so6 y consistirá en un paquete con el nombre del
ejercicio en cuestión, identificación del año en curso y extensión
de archivo comprimido (P. ej. .2013.tar.gz).
(6)

01/02/2013 SO #2013/1
Una vez en su cuenta y desde su home, descomprima y desempaquete
estos ficheros.
sh> gunzip -c .2013.tar.gz | tar xvf -
sh> rm .2013.tar.gz
2.6. Protección frente a copias
El objetivo primordial de las prácticas es conseguir que el alumno,
con su realización, obtenga una experiencia que le será muy útil.
Persiguiendo esta meta fundamental, prestaremos especial interés
en detectar los intentos de copia total o parcial de prácticas.
Para evitar problemas de confidencialidad y posibles copias, deberá
tenerse especial cuidado en proteger la propia cuenta de accesos
no deseados. Para ello se deben seguir las siguientes pautas:
✍ En cuanto le abran cuenta, proceda a entrar en la misma
para protegerla.
✍ Ponga inmediatamente una palabra clave de acceso a su
cuenta usando el mandato passwd. Pasado un tiempo desde
su apertura, se procederá a cerrar las cuentas sin palabra
clave. Escoja una palabra clave que tenga caracteres especiales
para que la protección sea más efectiva. No le diga su
palabra clave a nadie.
✍ Proteja el directorio home de su cuenta contra todo tipo de
acceso de cualquier otro usuario usando el mandato chmod
0700 $HOME.
✍ Cambie la mascara de creación de ficheros para proteger
cualquier fichero que cree en su cuenta. Para ello añada al
final del fichero .bashrc el mandato umask 077.
✍ No saque listados si no puede esperar a recogerlos.
(7)

SO #2013/1 Revisión 12.1
✍ Si sospecha que le han robado los fuentes con la solución de
alguna práctica, comuníquelo al profesor de la misma utilizando
correo electrónico y, MUY IMPORTANTE, adjunte
la versión perdida del documento.
login: MiCuenta
Password: ****
sh> passwd
New password: MiComplejaPalabraClave
Retype new password: MiComplejaPalabraClave
sh> chmod 0700 $HOME
sh> echo umask 0077 >> $HOME/.cshrc
2.7. Normas de presentación de los ejercicios
❒ El código fuente de las prácticas, esto es, el de los programas
que exija cada enunciado, debe residir, en su cuenta
en la máquina de prácticas, en un directorio que identifica
la asignatura, el ejercicio y el curso al que pertenece:
DATSI/so6/ (tres niveles desde el directorio
HOME de la cuenta). El nombre del directorio se obtiene
directamente al desempaquetar el software de apoyo en el
directorio HOME del alumno.
❒ No es necesario entregar ningún documento en papel para
entregar cada ejercicio. Toda la entrega se realiza de forma
telemática, ejecutando un programa en la misma máquina
en la que se hace el desarrollo.
❒ Antes de realizar la entrega ejecute make entrega para eliminar
tanto ficheros ejecutables como ficheros .o, dejando
únicamente las fuentes comprimidas en un fichero denominado
.2013.entrega.tar.gz.
❒ El mandato a ejecutar para entregar las prácticas está en
el directorio /usr/local/bin/ y se llama entrega.so6.
(8)

01/02/2013 SO #2013/1
Asegúrense de que la entrega se realiza correctamente. En caso
de error, la utilidad de entrega lo indicaría. Este mandato
realiza la recolección de los ficheros indicados en el apartado
Documentación a Entregar de cada ejercicio. En concreto
siempre se recogerán los siguientes:
➀ autores.txt Fichero ASCII con los datos del autor del
ejercicio.
Cada línea presentará cinco tiras de caracteres separadas
por blancos o tabuladores. DNI o número de Pasaporte,
primer apellido, segundo apellido, nombre y
número de matrícula. Separe las partes de los nombres
o apellidos compuestos con el caracter subrayado ( ),
no utilice blancos ni tabuladores.
Ejemplo:
P12456212F Garcia De La Torre Maria Dolores
910347
➁ bitacora.txt Fichero ASCII con comentarios reseñables
sobre la realización del ejercicio, que deberá desarrollar
los siguientes puntos: autor, problemas que se han
planteado, comentarios personales, crítica constructiva,
propuesta de mejoras, estimación del tiempo dedicado
en la realización, etc.
2.8. Entrega de los ejercicios
El mandato a ejecutar para entregar cada ejercicio será:
sh> make entrega
sh> entrega.so6 .2013
Este mandato recogerá los siguientes ficheros:
autores.txt
Descrito en el apartado 2.7 Normas de presentación.
(9)

SO #2013/1 Revisión 12.1
bitacora.txt
Descrito en el apartado 2.7 Normas de presentación.
.2013.entrega.tar.gz
Fichero comprimido de los códigos fuente, correspondiente a
la batería de ejercicios (creado al ejecutarse make entrega).
2.9. Plazos de entrega
Cada ejercicio deberá entregarse de forma independiente antes de
la fecha tope de entrega indicada en la página web de la asignatura.
Dicha fecha será inamovible. Los puntos correspondientes a un
ejercicio que no se hayan conseguido antes de la fecha tope de
entrega se habrán perdido.
Junto con las fechas tope de entrega, se publicarán unas fechas
adicionales que reconocerán el esfuerzo realizado al entregar los
ejercicios anticipadamente y alcanzar al menos el 90 % de la nota
máxima correspondiente al ejercicio. Aquellos alumnos que cumplan
este requisito de entrega anticipada en todos los ejercicios
obligatorios, serán eximidos de cumplir el requisito de asistencia
obligatoria al horario reservado para las prácticas de diseño.
Importante: No se permitirá entregar un ejercicio
fuera de su correspondiente plazo.
(10)

01/02/2013 SO #2013/1
3. Busca - Herramienta de selección de archivos
3.1. Objetivos
El alumno debe desarrollar una aplicación capaz de realizar la
búsqueda de ficheros dentro del árbol de directorios de acuerdo
a unos criterios especificados como argumentos en la ejecución
de la aplicación. Los resultados de la búsqueda se mostrarán por
pantalla (en el caso más sencillo) o se convertirán en argumentos
para la ejecución de otros mandatos.
La aplicación, denominada busca, se ejecutará con determinados
argumentos, y retornará los resultados de las operaciones solicitadas
o mensajes de error en caso de producirse algún problema.
3.2. Descripción
3.2.1. Uso de la aplicación: El programa “busca” se invocará
desde el intérprete de mandatos (shell) indicándole una serie
de argumentos que parametrizan su funcionamiento. El objeto general
del programa es realizar una búsqueda de los archivos desde
el directorio que se indica como primer argumento en adelante.
Los archivos que se seleccionarán serán aquellos que cumplan con
una determinada condición indicada también como argumento del
programa. Esta parte de los argumentos se denominará en adelante
criterio de selección.
Una vez seleccionados los archivos que cumplen el criterio de selección,
el programa “busca” puede, o bien presentar la lista de
los que cumplen la condición de selección, o ejecutar un programa
que reciba dicha lista de archivos. Otra alternativa es la ejecución
de un programa por cada archivo seleccionado (que reciba
dicho archivo como argumento). Esta parte de los argumentos se
denominará de aquí en adelante acción a aplicar.
La búsqueda de archivos se realizará solo en el directorio indicado
como argumento, no en subdirectorios que estén dentro de él. Es
decir, no se realizará búsqueda recursiva.
(11)

SO #2013/1 Revisión 12.1
Si por cualquier motivo, alguna operación no se puede realizar (por
ejemplo, entrar en un directorio), el programa sacará por el error
estándar un mensaje con el formato: "%s:␣Error(%d),␣%s\n"
donde:
❒ ␣ es un espacio en blanco.
❒ El primer campo ( %s) es el nombre completo del ejecutable
(argv[0]).
❒ El segundo campo ( %d) es el código de error (ver sección
3.3.5 y los diferentes tipos de errores correspondientes a las
distintas opciones seleccionables).
❒ El último campo ( %s) es el texto del mensaje de error generado.
Alguna de las operaciones pueden generar errores (por ejemplo,
no poder leer un archivo). En ese caso el programa generará un
error, pero continuará ejecutando el resto de operaciones que pueda
completar (por ejemplo, seguir leyendo el contenido de otros
archivos.). Los errores no abortan la ejecución del programa. El
programa devolverá por medio de la llamada exit(int) el valor
de error de la última operación que dio error ó 0 si ninguna operación
dio problemas. Los códigos de error que se pueden dar en
cada operación vienen indicados en los siguientes apartados.
Ejemplo de salida del programa:
[usuario@maquina ~] busca . -n .doc -print
./fichero.doc
./texto.doc
./tecto.doc.bak
Ejemplo de caso de error:
(12)

01/02/2013 SO #2013/1
[usuario@maquina ~] busca /home/frosal -n .doc
-print
busca: Error(2), No se puede leer el directorio
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
3.2.2. Sintaxis de la ĺınea de mandato del programa: La estructura
general de una llamada a busca se encuentra recogida en
la ✞ siguiente estructura:
☎
busca directorio inicial criterio de seleccion acción a aplicar
✝
✆
Todos los argumentos son obligatorios.
El argumento directorio inicial indica la ruta, absoluta o relativa
desde la cual se realizará la búsqueda.
El criterio de seleccion representa cuáles serán los archivos seleccionados.
En las siguientes secciones se irán indicando las diferentes
opciones de selección que se deberán implementar.
La acción a aplicar representa qué es lo que se hace con los archivos
seleccionados. Las diferentes acciones a implementar también
se discutirán en las siguientes secciones.
3.3. Acciones del mandato
El mandato busca deberá realizar las siguientes acciones:
➀ Selección basada en tipo de archivo
➁ Selección basada en nombre de archivo
➂ Selección basada en permisos
➃ Acción de imprimir archivos seleccionados
➄ Gestión de errores básicos
➅ Selección basada en el contenido del archivo (lectura del mismo).
(13)

SO #2013/1 Revisión 12.1
➆ Selección basada en el contenido del archivo (proyección en
memoria).
➇ Acción de procesar la lista de archivos por medio de otro
programa.
➈ Acción de ejecutar un programa por cada archivo.
Se recuerda que en el filtro de selección de archivos, el propio
proceso de búsqueda sólo se aplica al directorio indicado como
primer argumento, no es una búsqueda recursiva.
3.3.1. Selección por tipo de archivo: Consiste en seleccionar
aquellas entradas del directorio a analizar que cumplan la condición
de ser fichero (f) o directorio (d).
Este ✞ criterio de selección se declara como: ☎
busca directorio inicial -t [f|d] acción a aplicar
✝
✆
La combinación -t f seleccionará los ficheros y la opción -t d
seleccionará los directorios.
ERROR
Código Mensaje
1 Opcion no valida
Este error se produce cuando el tipo de entrada
que se pide seleccionar no es ni f ni d. Este
error se aplicará también a otros parámetros no
válidos.
3.3.2. Selección por nombre de archivo: Consiste en seleccionar
aquellas entradas del directorio a analizar que cumplan la
condición de contener en el nombre la subcadena pasada como
argumento. Si dicha cadena aparece dentro del nombre, el fichero
pasará el criterio de selección.
(14)

01/02/2013 SO #2013/1
Este ✞ criterio de selección se declara como:
☎
busca directorio inicial -n cadena acción a aplicar
✝
✆
La llamada con -n pepe seleccionará todos los ficheros y directorios
que contengan pepe en su nombre.
3.3.3. Selección por permisos de archivo: Consiste en seleccionar
aquellas entradas del directorio a analizar que cumplan la
condición de ser ejecutables (x) o de tener permisos de lectura (r)
o de escritura (w).
Este ✞ criterio de selección se declara como:
☎
busca directorio inicial -p [x|r|w] acción a aplicar
✝
✆
Los archivos seleccionados deberán disponer del permiso indicado
para el usuario. Es decir, que se debe verificar el primer bloque de
permisos, si es el mismo usuario, el segundo bloque si es un usuario
del mismo grupo, o en caso contrario el último bloque. Para ello
se deberá gestionar correctamente la identidad del usuario.
✍ NOTA: La identidad de grupo que se cotejará será la del grupo
primario del usuario. Es decir la asignada como identificador de
grupo del proceso.
✍ NOTA: Es necesario tener en cuenta la identidad efectiva del
proceso, es decir el EUID y el EGID (no la real, UID y GID)
ERROR
Código Mensaje
1 Opcion no valida
Este error también se produce cuando el permiso
no es ni x, ni r, ni w.
3.3.4. Impresión de archivos: Es la acción a aplicar más básica.
Consiste en mostrar por la salida estándar la lista de archivos que
cumplan el criterio de selección.
Esta ✞ acción se declara como:
☎
busca dir inicial crit de seleccion -print
✝
✆
(15)

SO #2013/1 Revisión 12.1
La lista de archivos generada mantendrá la ruta incluyendo el
directorio indicado como argumento. Por ejemplo si se busca desde
el directorio /tmp las salidas serán del tipo /tmp/pepe.c. Si
por contra, se busca en el directorio actual (.), las salidas serán
./pepe.c.
✍ NOTA: La salida de los resultados se realizará en el mismo
orden en el que aparezcan en el directorio consultado. No será necesario
ordenar los archivos bajo ningún criterio. Se mostrarán
según se obtengan de las funciones POSIX que recorren el directorio
(opendir, readdir, etc.).
✍ NOTA: Las entradas de directorio que comiencen por un punto
(.) se ignorarán.
3.3.5. Gestión de errores básicos: Debe implementarse el control
de los siguientes tipos de errores básicos:
ERROR
Código Mensaje
1 Opcion no valida
Este error, que ya hemos visto antes, se producirá
siempre que los argumentos de un criterio
de selección o de una acción a aplicar sean incorrectos.
ERROR
Código Mensaje
2 No se puede leer el directorio
Este error se producirá cuando los permisos del
directorio sobre el que se realiza la búsqueda no
permitan efectuar las operaciones de recorrido
de sus entradas.
3.3.6. Selección por contenido de archivo (lectura): En este
caso se seleccionarán los archivos que contengan una determinada
(16)

01/02/2013 SO #2013/1
subcadena pasada como argumento adicional de esta selección.
Este ✞ criterio de selección se declara como:
☎
busca directorio inicial -c cadena acción a aplicar
✝
✆
Los archivos seleccionados serán aquellos en cuyo interior se localice
la cadena indicada. La búsqueda de esta cadena se realizará
abriendo el fichero, y leyendo del mismo su contenido. Dentro
de este contenido se buscará la cadena solicitada.
✍ NOTA: Los directorios no se consultarán. Un directorio nunca
se podrá seleccionar por medio de este criterio de selección.
ERROR
Código Mensaje
3 No se puede leer el archivo
Este error se generará por cada uno de los archivos
sobre los que no se tenga permiso de lectura
3.3.7. Selección por contenido de archivo (proyección): En
este caso, al igual que en el anterior, se seleccionarán los archivos
que contengan la cadena indicada como argumento adicional de
esta selección.
Este ✞ criterio de selección se declara como:
☎
busca directorio inicial -C cadena acción a aplicar
✝
✆
Los archivos seleccionados serán aquellos en cuyo interior se localice
la cadena indicada. La búsqueda de esta cadena se realizará,
en este caso, proyectando el archivo en memoria.
✍ NOTA: Los directorios no se consultarán. Un directorio nunca
se podrá seleccionar por medio de este criterio de selección.
ERROR
Código Mensaje
3 No se puede leer el archivo
Este error se generará por cada uno de los archivos
sobre los que no se tenga permiso de lectura
(17)

SO #2013/1 Revisión 12.1
3.3.8. Procesar lista de archivos: En este caso, el resultado del
proceso de selección, la lista de archivos seleccionados, se pasa
por medio de un pipe (tubería) a otro programa. Este programa
se facilita como argumento de la acción a aplicar junto con los
argumentos que a su vez necesite.
Esta ✞ acción se declara como:
☎
busca dir inicial crit de selección -pipe mandato [argumentos ...]
✝
✆
La lista de archivos generada, que en el caso de la acción -print
se sacaba por la salida estándar, se pasa al mandato que aparece
a continuación. Dicho mandato se ejecutará con los argumentos
indicados.
La acción a realizar debe ser análoga a sacar los datos por la salida
estándar y redirigir ésta por un pipe a la entrada estándar de otro
proceso.
Ejemplo de salida del programa con un pipe:
[usuario@maquina ~] busca . -n .doc -print | sort
./documento.doc
./hola.doc
./practica.doc
Ejemplo de salida con pipe integrado:
[usuario@maquina ~] busca . -n .doc -pipe sort
./documento.doc
./hola.doc
./practica.doc
ERROR
Código Mensaje
4 No se puede ejecutar el mandato
Este error se dará si el mandato que se indica
no se puede ejecutar correctamente
(18)

01/02/2013 SO #2013/1
✍ NOTA: En este caso el valor de retorno (el de la llamada
exit(int)) será el recogido del mandato que se ha ejecutado como
receptor de la lista de archivos.
3.3.9. Ejecución secuencial de un programa por archivo: Esta
acción consiste en lanzar un proceso por cada uno de los archivos
que cumplan el criterio de selección. La ejecución de estos procesos
será secuencial, es decir, que se ejecutarán uno a uno, esperando
a la finalización de cada uno para lanzar el siguiente.
Esta ✞ acción se declara como:
☎
busca dir inicial crit de seleccion -exec mandato [argumentos ...]
✝
✆
Los procesos hijo que se arrancarán por cada fichero seleccionado
serán ✞ de la forma:
☎
mandato [argumentos ...] fichero seleccionado
✝
✆
Siendo mandato y argumentos los que aparecen tras la directiva
-exec en la llamada al mandato busca.
Ejemplo de ejecución de un progrma por archivo:
[usuario@maquina ~] busca . -C data -exec wc -l
2 23 100 ./datost
138 230 2900 ./fichero grande
En este ejemplo se ve cómo se ejecuta el mandato wc una vez por
cada fichero que contiene la cadena “data” en su interior. Este
mandato cuenta la líneas, palabras y caracteres que aparecen en
el fichero.
Timeout: Para la ejecución de programas por cada archivo, el
programa busca debe establecer un control que prevenga ejecuciones
excesivamente largas por parte de los procesos lanzados. Para
ello, busca leerá una variable de entorno, denominada BUSCATIME,
(19)

SO #2013/1 Revisión 12.1
que indicará el número de segundos, como máximo, que esperará
busca a que todos los mandatos hayan concluido. Este
timeout comenzará a contar antes de arrancar el primer mandato.
En el momento en que se cumpla, no se arrancarán nuevos
procesos (de quedar pendiente alguno), y se abortará la ejecución
del que pueda estar en curso. Para abortar el posible proceso en
ejecución se le mandará una señal SIGKILL (ver kill(2)). Si la
variable de entorno BUSCATIME no existiera, se deberá tomar 0
como valor por defecto.
ERROR
Código Mensaje
5 Timeout
Este error se generará si el timeout indicado por
la variable BUSCATIME se cumple antes de haber
finalizado la ejecución de todos los procesos.
✍ NOTA: En este caso el valor de retorno (el de la llamada
exit(int)) será el recogido del mandato que se ha ejecutado como
receptor de la lista de archivos (en el caso de que la ejecución no
haga saltar el timeout, si dicha temporización vence se dará el
error antes citado (Error 5))
Adicionalmente se podrá dar el caso de no poder ejecutar uno o
varios errores de tipo 4:
ERROR
Código Mensaje
4 No se puede ejecutar el mandato
Este error se dará si el mandato que se indica no
se puede ejecutar correctamente. Aparecerá por
la salida de error estándar una línea por cada
mandato que no se pueda ejecutar.
(20)

01/02/2013 SO #2013/1
3.4. Páginas del Manual a Consultar
A título de ayuda se recomienda la consulta de los siguientes servicios
o funciones en las páginas del manual. Dichas páginas se
pueden consultar vía el mandato man):
❒ stat(2)
❒ opendir(3)
❒ readdir(3)
❒ closedir(3)
❒ Alternativa a las tres anteriores: scandir(3)
❒ getuid(2)
❒ geteuid(2)
❒ getgid(2)
❒ getegid(2)
❒ open(2)
❒ read(2)
❒ mmap(2)
❒ munmap(2)
❒ close(2)
❒ memmem(3)
❒ fork(2)
❒ execvp(3)
❒ dup(2)
(21)

SO #2013/1 Revisión 12.1
❒ pipe(2)
❒ wait(2)
❒ kill(2)
❒ sigaction(2) o signal(2)
❒ getenv(3)
❒ alarm(2)
❒ exit(2)
(22)

01/02/2013 SO #2013/1
4. Cargador - Herramienta para la carga de módulos
dinámicos
4.1. Objetivos
El alumno debe desarrollar una aplicación capaz de cargar dinámicamente
un módulo (implementado como una biblioteca dinámica
con extensión .so) que contendrá la descripción de un plugin.
Este plugin contendrá una serie de funciones de control, que deberán
ejecutarse bien como un proceso o bien como un thread
controlado por el programa cargador.
La aplicación, llamada cargador, se implementará como un proceso
con la capacidad de cargar un módulo que contiene la implementación
de un plugin, arrancar instancias del mismo y controlar
su ejecución (detener, reanudar y finalizar su ejecución), usando
para ello mecanismos de control de procesos y de threads, tales como
señales o mecanismos de sincronización específicos de procesos
ligeros.
4.2. Descripción
4.2.1. Uso de la aplicación: El programa “cargador” se invocará
desde el intérprete de mandatos (shell) indicándole un argumento
que parametriza su funcionamiento. El objeto general del
programa es controlar y manipular la ejecución de un plugin.
Si por cualquier motivo, alguna operación no se puede realizar
(por ejemplo, cargar el módulo dinámico), el programa
sacará por el error estándar un mensaje con el formato:
"%s:␣Error(%d),␣%s\n" donde:
❒ ␣ es un espacio en blanco.
❒ El primer campo ( %s) es el nombre completo del plugin que
ha generado el error (arg).
❒ El segundo campo ( %d) es el código de error (ver sección
4.3.7).
(23)

SO #2013/1 Revisión 12.1
❒ El último campo ( %s) es el texto del mensaje de error generado.
El programa terminará por medio de la llamada exit(int), indicando
el código de error de la operación que dio error ó 0 si la
operación no dio problemas. Los códigos de error que se pueden
dar en cada operación vienen indicados en los siguientes apartados.
4.2.2. Sintaxis de la ĺınea de mandato del programa: La estructura
general de una llamada a cargador se encuentra recogida
en ✞ la siguiente estructura:
☎
cargador opción [fichero mandatos]
✝
✆
El primer argumento determina el tipo de mecanismo que se va
a usar para la ejecución del plugin, que deberá soportar tanto el
uso de procesos convencionales (opción -p) como el de procesos
ligeros, threads, (opción -t).
El segundo argumento, que es opcional, permite cargar un fichero
de mandatos a ejecutar por el programa cargador. En el caso
de proporcionarle este fichero, el funcionamiento del programa
será en “modo batch”, cargando los mandatos del fichero como si
se hubiesen proporcionado por línea de mandatos.
4.2.3. Conceptos: A efectos aclaratorios, resulta necesario distinguir
entre:
❒ Módulo plugin: Biblioteca dinámica que contiene el código
de un plugin. El programa cargador sólo puede tener un
módulo cargado por ejecución.
❒ Instancia del plugin: El código de un plugin cuando
está en ejecución. El programa cargador puede lanzar más
de una instancia por ejecución del programa, pudiendo haber
varias de estas instancias arrancadas y en ejecución a
(24)

01/02/2013 SO #2013/1
la vez. También puede haber arrancada una sola instancia
en cada momento, pero una misma ejecución del programa
cargador puede arrancar y finalizar varias instancias antes
de terminar.
4.3. Acciones del mandato
El mandato cargador deberá realizar las siguientes acciones:
➀ Funcionamiento básico
➁ Carga del módulo de plugin
➂ Arranque y finalización usando procesos
➃ Arranque y finalización usando threads
➄ Parada y re-arranque en procesos y threads.
➅ Gestión de varias instancias de procesos/threads.
4.3.1. Funcionamiento básico: El programa cargador, al arrancarse
en modo interactivo (sin el segundo argumento de fichero de
mandatos), muestra un prompt que permite al usuario ir dictándole
órdenes, en forma de mandatos, para el cargador. Si se trata de
una ejecución con fichero de mandatos, estas órdenes se leerán del
fichero indicado como segundo argumento.
Ejecución interactiva:
[usuario@maquina ~] cargador -t
cargador> echo Hola mundo
Hola Mundo
✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> quit
(25)

SO #2013/1 Revisión 12.1
Ejecución con fichero de mandatos:
[usuario@maquina ~] cargador -t ordenes
Hola Mundo
✿✿✿✿✿✿✿✿✿✿✿✿✿
En cualquiera de los casos, el código de apoyo facilitado al alumno
proporciona la estructura básica para manipular estas dos formas
de introducir órdenes al programa cargador. Esta estructura básica
invocará una función distinta para cada uno de los diferentes
tipos de mandatos. Es tarea del alumno implementar cada una de
estas funciones.
Este primer apartado incluye la implementación de los tres mandatos
más sencillos:
➊ Mandato de salida:
Mandato de Salida:
echo mensaje
Este mandato debe sacar por la salida estándar de error el
mensaje que aparece a continuación del propio mandato.
➋ Mandato de espera:
Mandato de Espera:
sleep segundos
Este mandato debe suspender la ejecución del programa
cargador, no de las instancias de plugins que estén ejecutándose,
durante una serie de segundos (indicados como
(26)

01/02/2013 SO #2013/1
argumento). Es obligatorio implementar este mandato por
medio de la llamada al sistema nanosleep(2). Este mandato
no debe generar mensaje alguno (ni por error ni por salida
estándar) salvo en el caso especificado en la Sección 4.3.7).
➌ Mandato de salida:
Mandato de Salida:
quit
Este mandato termina la ejecución del programa cargador
y de todas las instancias de plugins que tenga en ejecución.
El programa debe finalizar con un código de terminación 0
si no hubo errores, o el código del último error en caso de
haber habido alguno. Este mandato no debe generar mensaje
alguno (ni por error ni por salida estándar).
4.3.2. Carga básica del módulo del plugin: Esta parte implica
la implementación del mandato:
Mandato de Carga:
load módulo
Este mandato carga el fichero indicado por el parámetro módulo.
Para flexibilizar el uso de esta herramienta, los módulos que
implementan los plugins se cargarán dinámicamente. Para ello, se
sugiere el uso de las funcionalidades de carga dinámica de bibliotecas
(ver la llamada dlopen).
El procedimiento para la carga de los plugins debe ser el siguiente:
(27)

SO #2013/1 Revisión 12.1
1. Se solicitará la apertura de la biblioteca dinámica.
2. Se buscará en ella el símbolo plugin info (el símbolo buscado
se corresponderá con el nombre de una función que
devuelve una estructura con información del módulo).
3. Se ejecutará dicha función (obteniendo un puntero a dicha
estructura de información).
4. Finalmente, se guarda el puntero a esta estructura que contiene
los punteros a todas las funciones del plugin.
La definición del prototipo de dicha función, así como la estructura
devuelta se encuentran descritos en el fichero de apoyo
plugin info.h. Los campos de la citada estructura son:
typedef struct plugin info st {
char* banner;
void (*plugin loop) ();
void (*plugin stop) ();
void (*plugin resume) ();
int (*plugin finish) ();
} plugin info t;
plugin info t* plugin info();
La estructura que devuelve plugin info incluye los siguientes
campos:
❒ banner: Es la cadena de caracteres que identifica al plugin.
Cuando se tenga que indicar el nombre del plugin se usará esta
cadena.
❒ plugin loop: Es un puntero a una función que se invoca en
cada una de las iteraciones del bucle de ejecución del plugin.
En otras palabras, la ejecución del plugin (en un proceso o
en un thread) consistirá en un bucle infinito en el que se
invoca a esta función.
(28)

01/02/2013 SO #2013/1
❒ plugin stop: Es un puntero a una función que se invoca por
parte del plugin, cuando se haya solicitado una parada del
mismo.
❒ plugin resume: Es un puntero a una función que se invoca
cuando habiéndose detenido previamente el plugin, se solicita
que reanude su ejecución.
❒ plugin finish: Es un puntero a una función que se invoca
cuando se finaliza una instancia en ejecución del plugin.
Este mandato debe verificar que se puede cargar el módulo sin
problemas, que existe el símbolo buscado y que se ejecuta correctamente.
Para ello puede dar lugar a dos tipos de errores diferentes
(ver sección de errores, Sección 4.3.7).
Si este mandato se ejecuta con éxito, debe mostrar el mensaje:
“Modulo nombre módulo cargado correctamente” en una línea
por el error estándar.
4.3.3. Arranque y finalización usando procesos: Una vez cargado
un módulo, y dependiendo del modo en el que se haya ejecutado
el programa cargador es posible lanzar la ejecución de
una instancia del plugin. Ésta se lanzará como un proceso si el
programa cargador se ejecutó con la opción “-p”.
Esta parte implica la implementación del mandato:
Mandato de arranque:
start
Este mandato lanza un nuevo proceso (usando el servicio fork del
sistema operativo), que ejecutará una instancia, que no es más que
un bucle infinito de llamadas a la función plugin loop.
(29)

SO #2013/1 Revisión 12.1
El resultado de arrancar con éxito un plugin debe mostrar, por la
salida de error estándar, dos mensajes, uno a continuación del
otro: “Módulo iniciado: instancia ” y “Numero de modulos
iniciados: n instancias ”, cada uno de los mensajes en una
línea diferente. El valor de instancia se corresponderá a un número
consecutivo que se dará a las mismas, cada vez que se llame
al mandato start. Dicho número emprezará en cero (0) e
irá incrementándose con cada uno de estos mandatos. El valor de
n instancia es el número de instancias que se han arrancado.
✍ NOTA: Recuerde que en este caso sólo habrá una instancia
en ejecución en cada momento, pero sí pueden ejecutarse dos instancias
en secuencia, primero una, finalizar su ejecución y luego
otra.
El mandato complementario al arranque de una instancia del plugin
es su finalización. Cuando una instancia esté en ejecución se
puede finalizar en cualquier momento. El proceso de finalización
debe concluir la ejecución del proceso que ha arrancado dicha instancia
de forma inmediata, independientemente de que se encuentre
ejecutando dentro de la función plugin loop.
Para implementar este mecanismo de parada asíncrona se deben
utilizar señales, en concreto la señal SIGTERM. Dicha señal se debe
mandar al proceso que ejecuta el bucle infinito de la instancia
del plugin. Al recibir la señal, y antes de finalizar el proceso, el
propio proceso asociado a la instancia debe llamar a la función
plugin finish, que le devuelve un valor que es el que se usará como
valor de la llamada exit con la que finalizará el proceso que
ejecuta la instancia.
Esta parte implica la implementación del mandato:
Mandato de finalización:
finish instancia
(30)

01/02/2013 SO #2013/1
El parámetro instancia es opcional y, en caso de no indicarse, se
tomará el valor cero (0), primera instancia.
Si el mandato de finalización tiene éxito, se debe devolver el mensaje:
“Modulo finalizado: instancia (valor retorno )”, donde
instancia indica el número de instancia que ha finalizado y valor
retorno es el valor de retorno que ha devuelto la llamada exit
del proceso que ejecutaba la instancia y ha finalizado.
Si el proceso que ejecutaba la instancia del plugin finaliza con
una señal, se debe generar el error correspondiente (ver sección de
errores, Sección 4.3.7).
Ejemplo de uso:
[usuario@maquina ~] cargador -p
cargador> echo Comienzo
Comienzo
✿✿✿✿✿✿✿✿✿✿
cargador> load modulo-foo.so
Modulo modulo-foo.so cargado correctamente
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> start
Modulo iniciado: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Numero de modulos iniciados: 1
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> sleep 3
cargador> finish
Modulo finalizado: 0 (4)
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> quit
4.3.4. Arranque y finalización usando threads: Esta parte de
la práctica es análoga a la anterior, pero utilizando procesos ligeros,
threads, en lugar de procesos normales. Los mandatos usados
son realmente los mismos que en el caso de los procesos, diferenciándose
en que el programa cargador se debe ejecutar con la
opción “-t”.
El comportamiento debe ser idéntico al caso de los procesos, pe-
(31)

SO #2013/1 Revisión 12.1
ro con threads, utilizando también la misma señal SIGTERM para
finalizar la ejecución, esta vez, del thread.
4.3.5. Parada y re-arranque: Cuando una instancia está en ejecución,
el estado de esta ejecución debe poder manipularse mediante
una serie de mandatos. La manipulación que se va a realizar
consiste en la posibilidad de detener y de reanudar la ejecución.
A diferencia del proceso de finalización antes visto, la operación
de parada no es inmediata sino que se espera a que se finalice la
llamada en curso de la función plugin loop. Como se ha comentado,
el flujo de ejecución del proceso/thread asociado a la instancia
es un bucle infinito que llama de forma repetida a esta función. La
orden de parada sólo se hará efectiva al final de una ejecución de
esta función, si se ha solicitando durante la ejecución de la misma
y no ha sido revocada por una orden de re-arranque antes de ello.
Una vez solicitada la parada de la instancia, ésta se quedará bloquedada
hasta que se solicite una operación de re-arranque.
Justo antes de detener un proceso, el proceso/thread que ejecuta
la instancia deberá llamar a la función plugin stop. Asimismo,
después de re-arrancar y antes de entrar de nuevo en el bucle de
llamadas a plugin loop, el proceso/thread que ejecuta la instancia
deberá llamar a la función plugin resume.
La orden de parada de la instancia se realiza por medio del mandato:
Mandato de parada:
stop instancia
El parámetro instancia es opcional y, en caso de no indicarse, se
tomará el valor cero (0), primera instancia.
(32)

01/02/2013 SO #2013/1
Cuando se ejecuta el mandato de parada, se debe devolver el mensaje:
“Modulo detenido: instancia ”, donde instancia indica el
número de instancia que se ha parado.
La orden de re-arranque de la instancia se realiza por medio del
mandato:
Mandato de re-arranque:
resume instancia
El parámetro instancia es opcional y, en caso de no indicarse, se
tomará el valor cero (0), primera instancia.
Cuando se ejecuta el mandato de parada, se debe devolver el mensaje:
“Modulo reiniciado: instancia ”, donde instancia indica
el número de instancia que se ha parado.
La implementación de esta funcionalidad sí que es diferente en el
caso de threads y procesos, debido a la compartición o no de espacio
de memoria común. Por ello, se exige que la implementación
de estos dos mandatos siga las siguientes restricciones:
❒ Threads: La solicitud de parada y re-arranque se debe realizar
por medio de mecanismos de sincronización entre threads,
es decir mutex y variables condicionales.
❒ Procesos: La solicitud de parada se realizará por medio
del envío de la señal SIGUSR1, mientras que la orden de rearranque
se realizará por medio de la señal SIGCONT. A pesar
de utilizar señales, se recuerda que la orden de parada no se
debe ejecutar inmediatamente, sino que se debe diferir su
efecto al momento en el que se haya terminado de ejecutar
la llamada a la función plugin loop, es decir una vez por
iteración del bucle.
(33)

SO #2013/1 Revisión 12.1
Un ejemplo de uso (válido tanto para procesos como para threads)
es: Ejemplo de uso:
[usuario@maquina ~] cargador -t
cargador> echo Comienzo
Comienzo
✿✿✿✿✿✿✿✿✿✿
cargador> load modulo-foo.so
Modulo modulo-foo.so cargado correctamente
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> start
Modulo iniciado: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Numero de modulos iniciados: 1
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> sleep 2
cargador> stop
Modulo detenido: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> sleep 2
cargador> resume
Modulo reiniciado: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> finish
Modulo finalizado: 0 (4)
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> quit
4.3.6. Gestión de varias instancias: El último de los apartados
observa la gestión de más de una instancia en ejecución al mismo
tiempo. Se podrá invocar varias veces el mandato start sin
necesidad de haber hecho un finish de la instancia correspondiente
y el programa cargador deberá ser capaz de lanzar varios
procesos/threads a la vez.
Para la gestión adecuada de estos procesos, resulta indispensable
que los mandatos de stop, resume y finish incluyan el parámetro
adicional que identifica sobre qué instancia se aplican.
Las órdenes de parada y re-arranque se deben aplicar a nivel de
instancia (se detiene o se reanuda la ejecución de cada instancia
(34)

01/02/2013 SO #2013/1
por separado).
✍ NOTA: El comportamiento de varias instancias en ejecución
puede ser diferente si se lanzan como threads o como procesos, dependiendo
del uso de variables globales o no por parte del módulo
que define el plugin. Si éste define una variable global en su implementación,
dicha variable estará compartida en la versión de
threads y no en la de procesos.
Esta indicación depende de la librería que define el módulo, que
el alumno no tiene que modificar, pero ese comportamiento debe
tenerse en cuenta a la hora de usar variables globales o no en el
código del programa cargador.
Un ejemplo de uso (válido tanto para procesos como para threads)
es:
Ejemplo de uso:
(35)

SO #2013/1 Revisión 12.1
[usuario@maquina ~] cargador -p
cargador> echo Comienzo
Comienzo
✿✿✿✿✿✿✿✿✿✿
cargador> load modulo-foo.so
Modulo modulo-foo.so cargado correctamente
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> start
Modulo iniciado: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Numero de modulos iniciados: 1
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> sleep 1
cargador> start
Modulo iniciado: 1
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Numero de modulos iniciados: 2
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> sleep 2
cargador> stop 0
Modulo detenido: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> sleep 2
cargador> resume 0
Modulo reiniciado: 0
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> finish 1
Modulo finalizado: 1 (6)
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> finish 0
Modulo finalizado: 0 (2)
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
cargador> quit
4.3.7. Errores posibles: La ejecución de estos mandatos puede
dar lugar a una serie de errores que deben ser notificados por el
programa cargador.
(36)

01/02/2013 SO #2013/1
ERROR
Código Mensaje
1 No se puede cargar
Este error lo da cuando ha habido un problema
en la carga del fichero indicado como módulo.
El error puede ser tanto que el fichero no exista,
como que no sea una biblioteca dinámica válida.
ERROR
Código Mensaje
2 No se encuentra simbolo
Este error aparece cuando, una vez cargado el fichero
indicado como módulo, éste no contiene el
símbolo plugin info, por lo tanto no se puede
ejecutar para obtener la estructura de información
del plugin.
ERROR
Código Mensaje
3 Parametro de mandato no valido
Este error se da en todas las solicitudes de mandatos
que lleven asociado un parámetro, cuando
dicho parámetro no es del tipo adecuado. Por
ejemplo, si al mandato sleep se le pasa un argumento
que no es un número entero.
ERROR
Código Mensaje
4 Finalizacion anomala del plugin
Este error se produce cuando el thread/proceso
correspondiente a una instancia finaliza de forma
anómala (con una señal).
(37)

SO #2013/1 Revisión 12.1
ERROR
Código Mensaje
5 Error al crear instancia
Este caso de error se obtiene cuando el arranque
de una instancia del plugin (tanto en threads como
en procesos) de un error y no se llegue a crear
el thread/proceso correspondiente.
4.4. Páginas del manual a consultar
A título de ayuda se recomienda la consulta de las siguientes funciones
o llamadas en las páginas del manual. Dichas páginas se
pueden consultar vía el mandato man:
❒ nanosleep(2)
❒ dlopen(3)
❒ dlsym(3)
❒ dlclose(3)
❒ waitpid(2)
❒ fork(2)
❒ sigaction(2)
❒ kill(2)
❒ pause(2)
❒ strtol(3) / atoi(3)
❒ pthread create(3)
❒ pthread exit(3)
(38)

01/02/2013 SO #2013/1
❒ pthread join(3)
❒ pthread mutex init(3)
❒ pthread mutex lock(3)
❒ pthread mutex unlock(3)
❒ pthread mutex destroy(3)
❒ pthread cond init(3)
❒ pthread cond destroy(3)
❒ pthread cond signal(3)
❒ pthread cond wait(3)
❒ pthread kill(3)
(39)

SO #2013/1 Revisión 12.1
5. Servidor - Implementación del servidor de un pseudo-
FTP
5.1. Objetivos
El alumno debe desarrollar una implementación de un sencillo servidor
de un protocolo simplificado de tipo FTP, para transferencia
de ficheros por medio de sockets.
5.2. Descripción
5.2.1. Uso de la aplicación: El programa “servidor” se invocará
desde el intérprete de mandatos (shell), este programa no
recibe ningún parámetro y, al ponerlo a ejecutar, se debe quedar a
la espera de peticiones por parte de uno o varios clientes, de forma
secuencial.
5.2.2. Sintaxis de la ĺınea de mandato del programa: La estructura
general de una llamada a servidor se encuentra recogida
en ✄ la siguiente estructura:
✂servidor
✁
Como ya se ha dicho, este programa no recibe ningún parámetro.
5.3. Apartados
5.3.1. Funcionamiento básico: El servidor se encuentra inicialmente
escuchando mensajes por un puerto UDP. Los mensajes
representan solicitudes de transferencia de ficheros. Las transferencias,
en esta versión simplificada del servidor FTP siempre se
harán del servidor hacia el cliente. El cliente transmite un mensaje
en el cual indica la operación a realizar y el nombre del fichero
original (en el servidor) y el nombre local (en el cliente).
El servidor responde con la misma estructura de mensaje (vía
UDP también) indicando si se puede realizar o no la operación
(40)

01/02/2013 SO #2013/1
(dependiendo de que el fichero original exista o no) y, en el caso
de ser posible la transferencia, el puerto TCP que se va a usar.
La transmisión del fichero se realiza a través de conexiones stream
por medio de TCP.
5.3.2. Descripción general del protocolo: Una transferencia tipo
entre cliente y servidor consta de los siguientes pasos:
➀ El servidor arranca, reserva un puerto UDP y se queda a la
escucha en él.
➁ El cliente accede a dicho puerto de servicio UDP y transmite
un mensaje de tipo REQUEST indicando un nombre de
fichero en el servidor y el nombre local que se usará cuando
se transfiera a local.
➂ El servidor comprueba que el fichero existe. Si no existe responde
con un mensaje de tipo ERROR.
➃ Si el fichero existe, el servidor abre un puerto TCP y responde
al cliente, usando el anterior puerto UDP con un mensaje
de tipo OK, en el que incluye el número de puerto TCP que
ha reservado (el cliente no lo conoce a priori).
➄ El servidor se queda esperando en el nuevo puerto TCP y el
cliente abre dicha conexión.
➅ Por la conexión TCP establecida se transmite el contenido
completo del fichero.
➆ El servidor cierra la conexión con el cliente y se queda, de
nuevo, esperando nuevos mensajes en el puerto UDP.
(41)

SO #2013/1 Revisión 12.1
5.3.3. Configuración y puertos: El servidor, que el alumno debe
implementar, debe reservar dos puertos que estén libres, primero
uno UDP y luego otro de tipo TCP. Para realizar esta reserva y
asegurarse que se busca un puerto libre, se solicitará al sistema
(en la llamada bind) el puerto 0. Dicho número de puerto indica
al sistema que debe buscar un puerto libre cualquiera.
✍ NOTA: No se debe ir probando puertos de forma secuencial
hasta que uno esté libre. Se debe solicitar uno libre por medio
de este número de puerto 0, y luego se debe consultar cuál es el
número de puerto asignado (ver llamada getsockname)
La forma mediante la cual se notifica al cliente el puerto utilizado
es diferente para cada tipo (UDP y TCP, en este programa):
❒ Puerto UDP: En un caso real estos puertos son puertos
estándar, pero, para permitir que varios usuarios ejecuten
servidores en la misma máquina, se asigna buscando un puerto
UDP cualquiera que esté libre y el servidor escribe en un
fichero el número de puerto usado. El cliente lee este fichero
y así sabe qué puerto es el del servidor. Hay que tener
en cuenta que este mecanismo es un poco artificial, pero
permite que se ejecuten prácticas independientes en la misma
máquina. El código de apoyo incluye la función para
escribir este fichero y que lo pueda leer el cliente (función
Escribir Puerto).
❒ Puerto TCP: Por su parte, el puerto TCP se notifica como
respuesta válida del servidor a una petición de transferencia.
Cuando se comprueba que se puede hacer la transferencia se
transmite el número de puerto TCP que se va a usar.
5.3.4. Estructura de los mensajes UDP: Todos los mensajes
intercambiados entre cliente y servidor por medio de UDP se basan
en la estructura UDP Msg. Dicha estructura, descrita en el fichero
message.h, contiene los siguientes campos:
(42)

01/02/2013 SO #2013/1
typedef struct UDP Msg st {
int op; /* Operación */
char local[128]; /* Fichero local */
char remoto[128]; /* Fichero remoto */
int puerto; /* Puerto del servidor para la transmisi
del fichero vía TCP */
} UDP Msg;
El campo op puede tomar los siguientes valores:
❒ REQUEST: Petición del cliente de una transferencia.
❒ OK: Respuesta afirmativa del servidor, el fichero existe y se
puede hacer la transferencia.
❒ ERROR: Respuesta negativa del servidor, el fichero no existe
y no se puede hacer la transferencia.
❒ QUIT: Petición del cliente para que el servidor finalice su
ejecución.
Los campos local y remoto sólo tienen sentido en el mensaje
REQUEST del cliente al servidor. Indican el nombre del fichero local
(para el cliente) y remoto (del servidor). La transmisión siempre
es del servidor hacia el cliente.
El campo puerto es el que rellena el servidor en la respuesta OK
y en dicho campo se indica el puerto TCP reservado.
5.3.5. Traza de ejecución esperada en el servidor: Para comprobar
que el servidor está funcionando correctamente, y detectar
eventuales errores, se exige una secuencia de trazas (impresas por
la salida estándar del programa servidor) estricta.
(43)

SO #2013/1 Revisión 12.1
Dicha secuencia es la siguiente: Ejemplo de trazas:
[usuario@maquina ~] servidor
SERVIDOR: Creacion del socket UDP: OK
SERVIDOR: Asignacion del puerto servidor: OK
SERVIDOR: Puerto guardado en fichero
./puerto servidor: OK
SERVIDOR: Creacion del socket TCP: OK
SERVIDOR: Asignacion del puerto servidor: OK
SERVIDOR: Aceptacion de peticiones: OK
SERVIDOR: Puerto TCP reservado: OK
SERVIDOR: Esperando mensaje.
SERVIDOR: Mensaje del cliente: OK
SERVIDOR: REQUEST(prueba.txt.local,prueba.txt)
SERVIDOR: Enviando del resultado [OK]: OK
SERVIDOR: Llegada de un mensaje: OK
Cada mensaje se producirá tras la ejecución de una de las operaciones
principales del servidor, y se indicará si ha funcionado o
no.
❒ SERVIDOR: Creacion del socket tipo : Tras la creación
del socket del tipo correspondiente (UDP o TCP).
❒ SERVIDOR: Asignacion del puerto servidor: Tras finalizar
la reserva del puerto (ver bind). Debe haber dos trazas
de este tipo en el servidor una por tipo de puerto (TCP o
UDP) usado.
❒ SERVIDOR: Aceptacion de peticiones: Después de haber
invocado listen.
❒ SERVIDOR: Puerto TCP reservado: Una vez finalizada la
creación y reserva del socket TCP.
(44)

01/02/2013 SO #2013/1
❒ SERVIDOR: Esperando mensaje: Antes de quedarse bloqueado
en una recepción de mensaje UDP.
❒ SERVIDOR: Mensaje del cliente: Después de recibir un
mensaje UDP.
❒ SERVIDOR: Enviando del resultado [mensaje ]: Envio del
mensaje de respuesta correspondiente (OK o ERROR) al cliente.
❒ SERVIDOR: Llegada de un mensaje: Antes de quedarse
bloqueado en la espera de una conexión TCP (ver accept).
5.3.6. Finalización del servidor: Para finalizar la ejecución del
servidor, el cliente puede mandar un mensaje de tipo QUIT en lugar
de una petición REQUEST) de un fichero. Tras la recepción de este
mensaje el servidor debe terminar su ejecución.
5.3.7. Código de apoyo: En este programa, el código de apoyo
proporcionado contiene algún elemento más que o habitual en los
otros programas. El código de apoyo incluye:
❒ cliente.c: En el subdirectorio Cliente se incluye una implementación
de un cliente para el protocolo propuesto. Esta
implementación no se debe modificar, pero conviene
consultarla para ver el tipo de interacción que espera la otra
parte del protocolo.
❒ message.h: Define el prototipo de estructura intercambiada
por medio de los mensajes UDP, así como varias constantes
usadas, tanto por cliente como por servidor.
❒ lanzador.sh: Un sencillo script de apoyo que permite arrancar
una instancia del servidor y toda una batería de clientes
que soliciten transferencia de ficheros. Este script es especialmente
útil para automatizar ciertas pruebas.
(45)

SO #2013/1 Revisión 12.1
5.4. Páginas del manual a consultar
A título de ayuda se recomienda la consulta de las siguientes funciones
o llamadas en las páginas del manual. Dichas páginas se
pueden consultar vía el mandato man:
❒ socket(2)
❒ bind(2)
❒ accept(2)
❒ listen(2)
❒ connect(2)
❒ getsockname(2)
❒ sendto(2)
❒ recvfrom(2)
❒ send(2)
❒ recv(2)
❒ exit(2)
(46)

01/02/2013 SO #2013/1
Registro de Revisiones
Este documento ha sido publicado como informe docente número
2013/1 por el Departamento de Arquitectura y Tecnología de Sistemas
Informáticos de la Facultad de Informática de la Universidad
Politécnica de Madrid como parte de la asignatura Sistemas Operativos.
El histórico de revisiones realizadas a este documento son:
• Revisión 12.1 (01/02/2013). Versión completa
• Versión inicial (20/01/2006).
Este documento se encuentra actualmente mantenido por: Angel
Rodríguez. c○ Departamento de Arquitectura y Tecnología de Sistemas
Informáticos, Facultad de Informática.
(47)