Sistema para la realización y evaluación de prácticas - IEEE-RITA

Anuncio
IEEE-RITA Vol. 4, Núm. 2, May. 2009
109
Sistema para la realización y evaluación de
prácticas de protocolos de nivel de aplicación
David Melendi, Xabiel G. Pañeda, Member, IEEE, Roberto García, Member, IEEE, Víctor García
Title—System for the study and knowledge evaluation of
application layer protocols.
Abstract - One of the main subjects in computer science and
telecommunication degrees is the study of application protocols.
The increase in the number and use of Internet services has raised
their importance, since new applications which implement them
are developed everyday. However, their study is not easy since
they are hidden behind the services. In this paper we present a
tool to visualize protocol behaviours at the same time the student
is using the associate services. The result is an ideal environment
to learn the message format and interchange order. Moreover, the
tool has a module to evaluate the student progress.
Index Terms—e-learning, knowledge evaluation, laboratory
assignments, application layer protocols
I. INTRODUCCIÓN
E
L conocimiento de los protocolos de comunicaciones es
un elemento muy importante tanto en la formación de
ingenieros en informática como de telecomunicación. Por ello,
en ambas carreras existen materias que afrontan su estudio. Sin
embargo, conseguir una buena comprensión de su
funcionamiento es una tarea compleja, puesto que el
funcionamiento de los protocolos permanece oculto tras
programas y servicios. Raramente el alumno interactúa
directamente con los mismos, lo que dificulta su aprendizaje.
En los últimos años debido al desarrollo de nuevos servicios
para Internet se ha producido una gran proliferación de
protocolos de nivel de aplicación. Este tipo de protocolos se
sitúa en contacto directo con las aplicaciones que
proporcionan los servicios y en gran medida están
condicionados por ellas. Sin embargo, y a pesar de esta
cercanía, los usuarios desconocen totalmente cómo se lleva a
cabo el intercambio de información entre las aplicaciones. De
esta forma, a pesar de que los alumnos utilicen dichos
servicios con asiduidad es habitual que no sepan relacionarlos
con los conocimientos que se explican en las clases teóricas.
El aprendizaje basado en la mera memorización suele dar
lugar a “conocimiento inerte” [1], que permite a los
estudiantes aprobar un examen pero sin comprender
claramente los conceptos subyacentes. En este sentido, la
utilización de herramientas informáticas de apoyo puede
David Melendi, Xabiel G. Pañeda, Roberto García y Víctor García son
miembros del Área de Ingeniería Telemática del Departamento de Informática
de la Universidad de Oviedo. Campus de Viesques, s/n, Xixón/Gijón,
Asturies, Spain, {melendi, xabiel, garciaroberto y victor}@uniovi.es.
DOI (Digital Object Identifier) Pendiente
suponer una mejora clara del proceso educativo [2]. El
aprendizaje de protocolos de comunicaciones no es ajeno a
esta problemática y herramientas de este tipo se utilizan como
apoyo en las aulas [3-7].
Una situación ideal para que un alumno comprenda
plenamente el funcionamiento de un protocolo de nivel de
aplicación sería que éste pueda interactuar con un programa
similar a los convencionales que a su vez muestre los mensajes
intercambiados utilizando el protocolo. Así, el alumno puede
seleccionar el mensaje que desea enviar, incluir los parámetros
que considere oportunos y observar las respuestas que
devuelve el otro extremo. Si este programa se acompaña de
una ayuda detallada, será capaz de entender con claridad las
respuestas, así como los mensajes y parámetros que es
necesario enviar y el orden que debe seguirse.
Buscando cumplir con este objetivo, este artículo presenta
una herramienta que integra clientes de servicios (web, correo
electrónico, ftp, streaming y terminal remota) con las
interioridades de sus protocolos del nivel de aplicación para
facilitar la enseñanza de los mismos. Su utilización permite dar
un paso más en el aprendizaje de protocolos tradicionalmente
basado en la mera memorización, estancado en el nivel más
bajo de la taxonomía de objetivos educacionales de Bloom [8],
para alcanzar unos objetivos más ambiciosos (comprensión,
aplicación y análisis) situados en nivel 4 en dicha taxonomía.
La herramienta se completa con un módulo que permite al
profesor plantear ejercicios a los alumnos y llevar a cabo un
proceso de seguimiento y evaluación de los conocimientos
adquiridos a lo largo de un conjunto de prácticas.
El resto del artículo se estructura de la siguiente forma. En
la sección 2 se comentan los trabajos relacionados. En la
sección 3 se realiza una descripción general del sistema
educativo diseñado. En la 4 se describen en detalle los
protocolos hacia los que la herramienta se ha orientado. las
fuentes de información. En la 5 se describe el sistema de
evaluación y seguimiento implementado. En la sección 6 se
presentan algunos resultados obtenidos tras su utilización. Por
último, en las secciones 7 y 8 se comentan las conclusiones
obtenidas y unos posibles trabajos futuros.
II. TRABAJOS RELACIONADOS
Muchos y diversos han sido los métodos utilizados por los
profesores para conseguir que los alumnos comprendan el
funcionamiento de los protocolos de comunicaciones. Así, las
clases teóricas se han complementado con herramientas de
captura de tráfico, simuladores o emuladores buscando el
paradigma pedagógico learning by doing [9].
ISSN 1932-8540 © IEEE
110
IEEE-RITA Vol. 4, Núm. 2, May. 2009
Las herramientas de captura de tráfico o sniffers fueron
inicialmente diseñadas para la monitorización y gestión de
redes de computadores, aunque también es posible su
utilización en un entorno educativo. Ver el tráfico
intercambiado entre aplicaciones reales proporciona una visión
de la comunicación muy interesante desde el punto de vista
didáctico, tal y como se expone en trabajos como [3] o [4]. En
este tipo de herramientas destaca sobre todo WireShark [10]
por ser muy conocida y de libre distribución. No obstante, la
mera observación implica que el alumno sólo tendrá acceso a
los casos de comunicación más habituales. Por ejemplo, un
cliente de correo electrónico nunca se salta los mensajes de
autenticación antes de intentar acceder a un buzón, situación
cuyas consecuencias no podrían ser analizadas con un sniffer.
También se pueden usar herramientas de este tipo, pero
específicas para un protocolo determinado, como puede ser
Live HTTP Headers [11] o Web Sniffer [12]. Aunque la
información en este caso sería más dirigida y posiblemente
más detallada, su utilización requeriría la instalación de una
aplicación por protocolo.
Otra posibilidad es utilizar simuladores, que permiten
observar los protocolos en funcionamiento siguiendo un patrón
determinado, como en [3] o [5]. Dentro de este campo, la
mayoría de herramientas disponibles son de corte generalista y
se ajustan más al trabajo en a otros niveles de las pilas de
protocolos TCP/IP u OSI. La herramienta más conocida quizás
sea ns2 [13], pero existen otras como OPNET [14] o
WorkBench [15], más orientada a un entorno educativo. Más
específicas, también en entornos educativos, pero enfocadas a
otros niveles existen algunas herramientas como [16], que
permite estudiar MPLS. Específicas del nivel de aplicación se
han publicado pocos trabajos que han sido enfocados en un
protocolo determinado, como [6] que presenta una herramienta
que permite observar el funcionamiento de un servicio de
streaming.
Un inconveniente vuelve a ser la necesidad de instalar una
aplicación por protocolo. Además, en la utilización de
simuladores no se interactúa con una aplicación real que puede
incluso alterar ligeramente su comportamiento a medida que se
va actualizando. Todo lo que se puede experimentar ha sido
inicialmente previsto. Es por ello que su utilización en
ocasiones supone ignorar algunos casos que podrían ser
interesantes para los alumnos.
La emulación también puede ser útil para el estudio de los
protocolos de nivel de aplicación. En este sentido, se puede
estudiar la influencia de la infraestructura de red y protocolos
subyacentes sobre el nivel de aplicación. Así, pueden utilizarse
herramientas como el propio ns2 [13] u otras como Nist Net
[17], Empower [18], NetEm [19] o EmuSocket [20]. No
obstante, en este caso se requeriría un profundo conocimiento
de los protocolos, pudiendo hacer estudios más avanzados, con
lo que sería más adecuado para proyectos fin de carrera que
para asignaturas donde la duración de las prácticas es limitada.
Finalmente, un trabajo interesante que sigue un
planteamiento similar al seguido en el que ahora presentamos
es [7]. Coincide en cuanto a la idea de interactuar con
servidores reales y monitorizar los protocolos presentando los
mensajes en un entorno gráfico. No obstante, sólo se ha
diseñado para el protocolo HTTP, por lo que está muy
limitado en cuanto a la materia a impartir.
El sistema que aquí se describe presenta una serie de
ventajas sobre cualquiera de las otras aproximaciones:
--Integración: el alumno no tiene que lanzar primero un
cliente, realizar una petición y luego capturar los paquetes
como requeriría el uso de un sniffer.
--Guiado: al disponer de una lista con todos los comandos
que puede invocar y los parámetros o cabeceras que puede
utilizar, el aprendizaje resulta guiado. Además se dispone de
una ayuda en línea.
--Visual: existe un entorno gráfico en el que se utilizan
códigos de colores para facilitar el trabajo. Los comandos se
seleccionan de listas y los parámetros se rellenan en huecos.
--Intuitivo: a diferencia de sistemas como los sniffers, no
es necesario introducir filtros para recuperar los paquetes del
protocolo a estudiar.
--Precisión: al contrario de muchos simuladores, la
información proporcionada al usuario es real y precisa.
III. DESCRIPCIÓN GENERAL
La herramienta consiste en un programa Java que se
distribuye mediante la tecnología Java Web Start. Esta
tecnología permite ejecutar una aplicación haciendo clic sobre
un enlace publicado en una página web sin necesidad de una
instalación previa. Se ha seleccionado principalmente porque
facilita la ejecución por parte de los estudiantes, facilita el
proceso de actualización y, en principio, es independiente del
sistema operativo base (se ha ejecutado con éxito en sistemas
Microsoft, Mac y Linux).
La herramienta no es de código abierto pero es accesible de
forma pública desde las páginas de las asignaturas en las que
se utiliza. Una vez que los alumnos acceden a estas páginas,
solamente tienen que hacer clic en el enlace correspondiente y
confirmar su voluntad de ejecutar la herramienta. Tras aceptar
la ejecución arranca el sistema y los alumnos pueden observar
al interfaz de usuario que se muestra en la figura 1.
La herramienta dispone de un menú principal en la parte
superior, un cuadro de búsqueda en la ayuda situado en la
parte superior derecha, una serie de pestañas que dan acceso a
cada uno de los protocolos en la parte central y una barra
horizontal en la parte inferior que indica el código de colores
utilizado para representar el intercambio de mensajes entre las
aplicaciones. Cada una de las pestañas da acceso a una serie de
elementos como los que se pueden apreciar en la figura 1 para
el protocolo HTTP. En la parte superior de cada pestaña hay
unos cuadros para los parámetros a utilizar, en la parte
izquierda una barra vertical para seleccionar el comando a
enviar y un botón para hacer efectivo el envío, en la parte
derecha información detallada sobre cada petición o parámetro
enviado o recibido y en la parte central un área sobre el que se
muestran los mensajes intercambiados.
ISSN 1932-8540 © IEEE
MELENDI et al.: SISTEMA PARA LA REALIZACIÓN Y EVALUACIÓN DE PRÁCTICAS DE PROTOCOLOS
111
aspecto de la aplicación (se proporcionan 3 estilos), acceder a
la documentación de cada uno de los estándares contemplados
y visualizar la ayuda de la herramienta.
IV. PRÁCTICAS CON PROTOCOLOS Y SERVICIOS DEL NIVEL DE
APLICACIÓN
En esta sección se describen las posibilidades que ofrece la
herramienta para cada uno de los protocolos contemplados.
Concretamente, se han considerado los protocolos HTTP,
RTSP, SMTP, POP3, FTP y TELNET.
Fig. 1. Interfaz de usuario de la herramienta
Cuando un alumno ejecuta la herramienta, debe seleccionar
el protocolo que desea probar, introducir los parámetros
necesarios (que dependerán de cada protocolo), seleccionar los
mensajes que desea enviar y observar los mensajes que se
envían y se reciben del otro extremo. Para identificar el
extremo que está enviando el mensaje que se muestra en
pantalla, se utiliza el código de colores descrito en la parte
inferior de la pantalla. Además, se puede consultar el
significado de cada parámetro y mensaje en la zona de
información detallada situada en la parte derecha. En la figura
2 se muestra la ayuda de una cabecera utilizada por el
protocolo HTTP. A esta ayuda también se puede acceder si se
hace doble clic sobre los mensajes intercambiados que se
muestran en la parte central de la herramienta y los servidores,
de forma que cuando el alumno hace clic sobre un mensaje o
parámetro concreto, puede saber para qué se utiliza en el
marco del protocolo bajo estudio.
A. Servicios Web – HTTP
HTTP es uno de los protocolos de nivel de aplicación más
importantes al tratarse de uno de los pilares de los servicios
web. Además de por su relevancia, su estudio se justifica por
tratarse de un protocolo muy sencillo. Ilustra a la perfección el
intercambio de información entre dos programas y sirve de
iniciación en el estudio de otros protocolos similares.
Adicionalmente, su utilización en otros ámbitos como los
servicios de audio/vídeo, la integración de aplicaciones o los
servicios de mensajería instantánea le convierten en un
protocolo muy interesante.
Con la herramienta el alumno puede observar el intercambio
de mensajes resultado de peticiones de tipo OPTIONS, HEAD,
GET, POST y TRACE [20]. Adicionalmente, la herramienta
permite observar el funcionamiento del mecanismo de envío
de datos adjuntos en un entorno de web dinámica. Para ello se
utiliza codificación application/x-www-form-urlencoded [21],
sobre la que también es posible plantear ejercicios. Estos datos
adjuntos se pueden incluir en la URI en el caso de una petición
de tipo GET o se solicitan mediante una ventana emergente en
el caso de peticiones de tipo POST.
El servidor al que se envían las peticiones se obtiene a partir
de la dirección proporcionada por el alumno. Para ayudarle,
cuando el alumno pasa el ratón por el campo de direcciones se
le muestra el formato que debe utilizar para la URI que debe
proporcionar. De ella se extrae el nombre de dominio o IP de
la máquina, además del puerto a utilizar y el nombre de
recurso solicitado (en las peticiones que corresponda).
Un ejemplo de prueba realizada con este protocolo se puede
observar en la figura 1. En concreto, se muestra el resultado
obtenido tras la ejecución de una petición de tipo OPTIONS
contra un servidor web. Tras introducir la URI y presionar el
botón de envío de peticiones situado en la parte izquierda
inferior, se proporcionan detalles sobre la comunicación
indicando cuándo se abre y se cierra una conexión de nivel de
transporte, con qué máquina y puerto se establece esta
conexión, el mensaje de solicitud enviado y el mensaje de
respuesta recibido desde el otro extremo.
Fig. 2. Pantalla de ayuda
En lo que respecta al menú principal, el alumno puede
acceder a las pestañas que corresponden a cada uno de los
protocolos contemplados, configurar un proxy (si fuera
necesario), poner la aplicación a pantalla completa, ajustar el
tamaño de letra utilizado al visualizar los mensajes, cambiar el
B. Servicios de Streaming – RTSP
RTSP es un protocolo de control utilizado en servicios de
audio/vídeo streaming. A pesar de que el protocolo RTSP se
diseñó a partir de HTTP y por lo tanto es muy similar a este,
tiene interés por sus peculiaridades. A diferencia de HTTP,
RTSP es un protocolo con estados y por lo tanto, la conexión
ISSN 1932-8540 © IEEE
112
IEEE-RITA Vol. 4, Núm. 2, May. 2009
entre cliente y servidor que va pasando por diferentes estados
en función de los mensajes intercambiados entre ambos. No
obstante, al contrario de lo que sucede con otros protocolos,
esta conexión no se mantiene abierta a nivel de transporte, sino
que se basa en la utilización de unos identificadores de sesión
que es preciso utilizar. Desde el punto de vista de la
aplicación, si el alumno sigue los pasos adecuados puede
observar cómo la sesión evoluciona o en caso contrario puede
ver cómo se devuelven mensajes de error desde el servidor.
Otra diferencia entre HTTP y RTSP está en el envío de los
datos. Mientras que en el primero los datos se envían en línea,
en el segundo los datos de audio/vídeo se envían mediante una
conexión paralela que utiliza un protocolo diferente cuyos
parámetros es preciso negociar previamente. El alumno debe
encargarse de esa negociación y luego puede proceder con la
recepción de los datos, que también podrá ser observada en
forma de paquetes que se reciben en una conexión paralela.
Estas diferencias hacen que RTSP sea un protocolo algo más
complejo que HTTP. Esto, unido al éxito que han
experimentado los servicios de audio/vídeo en Internet en los
últimos años justifica su estudio.
Con la herramienta el alumno puede observar el intercambio
de mensajes resultado de peticiones de tipo OPTIONS,
DESCRIBE, SETUP, PLAY, PAUSE y TEARDOWN [23]. De
nuevo, el servidor al que se envían las peticiones se obtiene a
partir de la dirección proporcionada por el alumno. De ella se
extrae el nombre de dominio o IP de la máquina, además del
puerto a utilizar y el nombre de recurso solicitado (en las
peticiones que corresponda).
En la figura 3 se observa un ejemplo de utilización de la
herramienta con el protocolo RTSP. En esta gráfica se observa
el envío de un PLAY, posterior al intercambio de mensajes
inicial, y la recepción de la respuesta correspondiente. Se ve
cómo tras la respuesta se inicia la recepción de paquetes
multimedia utilizando el protocolo RTP, para el que se
muestran datos como el número de secuencia o el timestamp.
Además del mero envío de peticiones, se pueden observar
otros aspectos importantes del protocolo. Es posible trabajar
sobre su modelo de estados, observando lo que sucede si se
violan las transiciones esperadas por el servidor. También se
puede estudiar la gestión de sesiones, apreciando la utilización
de identificadores y el uso de temporizadores. Es posible
analizar el método de obtención de descripciones de
contenidos, la negociación de opciones, el mecanismo de
recepción de datos fuera de banda, etc.
C. Servicios de correo electrónico – SMTP y POP3
El servicio de correo electrónico es uno de los servicios más
antiguos y más utilizados de Internet. Esto, unido a sus
particularidades, le convierte en un servicio de gran interés.
Desde que un correo electrónico sale del ordenador del
remitente hasta que llega al ordenador del destinatario, el
mensaje va pasando por diferentes máquinas a la vez que se
utilizan distintos protocolos. En todo este proceso hay dos
fases principales: la de transferencia y la de descarga. La fase
de transferencia es la que se produce desde que el correo sale
del ordenador del remitente hasta que se almacena en el buzón
de correo del destinatario. En esta fase el protocolo más
utilizado es SMTP. Una vez que el correo está en el buzón del
destinatario, el correo se obtiene finalmente por el usuario en
una fase de descarga, en la que se utilizan otros protocolos. De
estos protocolos, el más utilizado es POP3.
Fig. 3. Utilización de la herramienta en el estudio de RTSP
Tanto SMTP como POP3 han sido considerados en la
herramienta. Así, un alumno puede experimentar con el
servidor con el que envía sus correos, a la vez que puede
observar cómo éstos se descargan de su buzón. Para ello, se
han habilitado dos pestañas que dan acceso a cada uno de
estos protocolos. Estos dos protocolos también tienen estados
al igual que sucedía con el protocolo RTSP. Es por ello que la
utilización de la herramienta para su prueba requiere un
conocimiento previo del modelo de estados de cada protocolo.
Para el caso particular de SMTP, el alumno debe
proporcionar el nombre de dominio o dirección IP de la
máquina en la que se ejecuta el servidor así como el puerto a
utilizar. Una vez escritos estos parámetros debe pulsar un
botón para establecer una conexión con el servidor y a partir
de que se establece la conexión puede enviar mensajes al otro
extremo y observar las respuestas obtenidas. En concreto se
han considerado peticiones de tipo HELO, MAIL, RCPT,
DATA y QUIT [24]. Para los mensajes de esta clase que
necesitan algún tipo de parámetro, la herramienta utiliza una
ventana emergente en la que el alumno puede escribir la
información solicitada. Esto sucede cuando se proporcionan
las direcciones de origen, destino y el correo a enviar.
Igualmente, para POP3 el alumno también debe
proporcionar la información necesaria para el establecimiento
de la conexión entre la herramienta y el servidor. Una vez
establecida esta conexión, el alumno ya puede enviar mensajes
al otro extremo y ver las respuestas que se van recibiendo. Los
tipos de petición que se han considerado en este caso son
USER, PASS, STAT, NOOP, LIST, RETR, RSET, DELE y
ISSN 1932-8540 © IEEE
MELENDI et al.: SISTEMA PARA LA REALIZACIÓN Y EVALUACIÓN DE PRÁCTICAS DE PROTOCOLOS
QUIT [25]. Tal y como sucedía con SMTP, Para los mensajes
que necesitan algún tipo de argumento se utilizan ventanas
emergentes en las que el alumno puede escribir. Esto sucede
en la fase de autenticación y para operar con un mensaje (ver
detalles, descarga y borrado).
En el aula se combina la utilización de los protocolos con
clientes de correo convencionales. Esto permite observar
aspectos como el efecto de las cabeceras en la información que
se muestra a los usuarios finales o el resultado de utilizar
mensajes multipart para analizar el envío de adjuntos o
mensajes alternativos. Adicionalmente, con independencia del
estudio de los mensajes de los protocolos, es posible trabajar
sobre sus modelos de estados, experimentar con el formato de
los mensajes haciendo ajustes en su cabecera, entender el
mecanismo de borrado de mensajes en los buzones de correo,
comprender las limitaciones de ambos protocolos en cuanto a
aspectos relacionados con la seguridad, etc.
D. Servicios de transferencia de archivos – FTP
En cuanto a la transferencia de archivos, se estudia el
protocolo FTP. Además de por motivos históricos, FTP tiene
un gran interés debido a la separación existente entre las
conexiones de control y las de transferencia de datos. Mientras
que las primeras se mantienen abiertas permanentemente, las
segundas se abren y se cierran en función de si hay datos que
enviar al otro extremo o no.
Con la herramienta el alumno puede observar el intercambio
de mensajes resultado de peticiones de tipo USER, PASS,
PWD, LIST, CDUP, CWD, DELE, STOR, SYST, PASV y QUIT
[25]. El servidor al que se envían las peticiones se obtiene a
partir la IP o nombre de dominio de la máquina y del puerto,
ambos datos proporcionados por el alumno. En las peticiones
que requieren un parámetro se utiliza una ventana emergente
para que el alumno pueda proporcionar el valor adecuado.
Esta situación se da en los mensajes de autenticación, para ver
detalles de un archivo o directorio, para moverse por el árbol
de directorios y para borrar un archivo. Por otro lado, a la hora
de seleccionar un archivo para su almacenamiento en el
servidor aparece otra ventana que permite elegir un fichero del
disco duro local.
Además de los aspectos comentados, desde el punto de vista
docente la herramienta permite a los alumnos comprender los
tipos de conexiones existentes en el marco de este protocolo y
los mecanismos utilizados para gestionar estas conexiones en
función de cada momento, las diferencia entre los modos
activo y pasivo (algo muy importante cuya comprensión suele
presentar muchas dificultades a los alumnos), las limitaciones
del protocolo en cuanto a aspectos relacionados con la
seguridad, el modelo de estados, etc.
E. Servicios de terminal remoto – TELNET
TELNET es el último protocolo que se ha considerado en la
herramienta. Al igual que FTP se trata de un protocolo
importante y, aunque haya caído en desuso por motivos de
seguridad, permite estudiar el comportamiento de un servicio
de terminal remoto.
113
Aparte del intercambio de texto con el otro extremo, la
funcionalidad más interesante de la herramienta es poder jugar
con la negociación de opciones. Para ello, se han habilitado las
instrucciones DO, DON’T, WILL y WON’T [27] que permiten
enviar instrucciones al otro extremo. Siguiendo las
especificaciones del estándar, la herramienta compone un
código de 3 bytes formado por IAC, el código correspondiente
a la instrucción seleccionada y un valor que se recoge del
usuario que indica qué opción se quiere negociar. Se puede
acceder a estos códigos mediante la ayuda provista.
Adicionalmente y al igual que sucedía con otros protocolos
comentados con anterioridad, la herramienta permite a los
alumnos entender las limitaciones de TELNET con respecto a
aspectos relacionados con la seguridad.
V. SISTEMA DE EVALUACIÓN Y SEGUIMIENTO
La herramienta también dispone de un sistema de
evaluación asociado. De este modo, los profesores pueden
plantear ejercicios y evaluar los resultados obtenidos por los
alumnos, a la vez que estos pueden autoevaluarse.
Este sistema permitirá a los profesores dar de alta, baja o
modificar alumnos, así como crear, borrar o modificar
preguntas de test. A partir de esas preguntas, el profesor puede
crear, borrar o modificar pruebas de evaluación, así como
revisar las respuestas de los alumnos a una prueba
determinada. Para almacenar toda esta información, junto con
los datos de autenticación, se utiliza un gestor de base de datos
Oracle, que es necesario siempre y cuando se desee utilizar
esta parte del sistema. En la figura 4 se muestra una pantalla
que permite modificar preguntas que han sido creadas con
anterioridad.
Fig. 4. Vista de profesor de la herramienta de evaluación
Por otro lado, los alumnos pueden cargar las pruebas de
evaluación creadas por el profesor, completar las respuestas
planteadas en la prueba y ver el resultado obtenido en la
misma.
Una opción en el menú principal de la herramienta permite
acceder al sistema de evaluación, que se realiza de forma
autenticada. En función del tipo de usuario que se autentique
el sistema permite llevar a cabo unas acciones u otras.
ISSN 1932-8540 © IEEE
114
IEEE-RITA Vol. 4, Núm. 2, May. 2009
Cuando accede un alumno a la herramienta en el intervalo
de tiempo indicado por el profesor se le ofrece una prueba de
evaluación con distintos modelos de test, tal y como se
muestra en la figura 5. El alumno contesta las preguntas
marcando las opciones que considera oportunas y cuando ha
finalizado las guarda en el sistema con el botón disponible en
la parte inferior, tras lo que se le muestran los resultados
obtenidos en la misma.
resultados del test se han comparado con las calificaciones
obtenidas en las convocatorias oficiales de febrero de los
cursos 2006/07 y 2007/08, en los que no se había utilizado
ninguna herramienta de apoyo. Se ha elegido esta convocatoria
para realizar las comparaciones debido a que la asignatura
elegida se imparte en el primer cuatrimestre. Así, se trata de la
primera prueba teórica a la que se enfrenta la mayoría de los
alumnos, de ahí su idoneidad.
Los criterios de calificación han sido idénticos en las tres
pruebas, de forma que 3 preguntas erróneas descuentan 2
preguntas correctas. Debido a este mecanismo de penalización
se han obtenido calificaciones negativas, que se han
normalizado a cero tras un proceso de reajuste.
Las calificaciones obtenidas se muestran en la figura 7, en la
que se observa el porcentaje de repeticiones registradas de
cada calificación, en intervalos de 1 punto de 0 a 10. En la
tabla 1 se muestra un resumen de estas calificaciones.
35
% Repeticiones
30
Fig. 5. Prueba de evaluación
25
20
15
10
Posteriormente, los profesores también pueden ver los
resultados obtenidos por los alumnos para hacer un
seguimiento del proceso de aprendizaje. En la figura 6 se
muestra la pantalla que permite acceder a los resultados de los
tests realizados por los alumnos. El profesor debe seleccionar
el alumno en la parte superior y en la inferior se muestran los
resultados que ha obtenido, diferenciando respuestas erróneas
de aquellas que han sido contestadas correctamente.
5
0
[10,9]
(9,8]
Febrero 2006/07
VI. EVALUACIÓN DEL SISTEMA
(6,5]
(5,4]
(4,3]
(3,2]
(2,1]
(1,0]
Febrero 2007/08
Test Prácticas
Figura 7: Comparación de calificaciones
TABLA I:
RESUMEN DE CALIFICACIONES
Febrero 06/07
Febrero 07/08
Test Prácticas
Para comprobar los beneficios de la herramienta, se ha
realizado un test en las clases prácticas de la asignatura de
Servicios de Comunicaciones de los estudios de Ingeniería
Técnica en Informática. El test se efectuó tras dos semanas de
prácticas, sin previo aviso y sin la posibilidad de utilizar la
herramienta durante su realización. Posteriormente, los
(7,6]
Calificación
Convocatoria
Fig. 6. Resultados obtenidos por un alumno
(8,7]
Alumnos
%
Calificación
Varianza
Evaluados Aprobados Promedio
76
71,05
5,7697
4,3125
89
82,02
6,5353
3,9453
49
87,76
7,0204
5,6119
En los datos mostrados se puede observar una tendencia
ascendente en las calificaciones en el tiempo. En la
convocatoria de febrero del curso 2006/07 se hacía un examen
de test. Éste fue complementado con 2 cuestiones teóricas en
la del curso 2007/08, mejorando las calificaciones obtenidas.
Finalmente, se observa cómo las calificaciones obtenidas de
los tests ejecutados tras las prácticas son mejores, a pesar de
haberse realizado en condiciones que supuestamente son más
desfavorables para los alumnos (sin previo aviso).
A pesar de que la varianza es ligeramente superior, la
calificación promedio en la prueba práctica es casi medio
punto superior a la de febrero de 2007/08 y más de un punto
superior a la de esa misma convocatoria en el curso 2006/07.
Cabe destacar que gracias a la realización de estos tests
durante las prácticas fue posible detectar de forma temprana
alumnos que se habían descolgado de la asignatura. Los
resultados obtenidos se comentaron de forma personalizada
con cada uno de los alumnos para resolver sus dudas. Durante
ISSN 1932-8540 © IEEE
MELENDI et al.: SISTEMA PARA LA REALIZACIÓN Y EVALUACIÓN DE PRÁCTICAS DE PROTOCOLOS
este proceso, se observó que los dos únicos alumnos que
obtuvieron una calificación de cero se sentaban juntos y no
acudían a las clases teóricas. Probablemente, su falta de
atención provocó los resultados obtenidos. De este modo, sin
necesidad de que el profesor dijera nada, los alumnos fueron
conscientes de que su actitud debía corregirse. Igualmente, el
profesor resolvió las dudas de los alumnos y les recomendó
acudir a tutorías para resolver dudas de mayor calado.
Además de estudiar los beneficios de la herramienta en la
adquisición de conocimientos por parte de los alumnos, se han
analizado los accesos para determinar si éstos utilizan el
sistema durante el estudio o no. En la figura 8 se muestran los
accesos registrados desde el 20 de octubre de 2008 al 22 de
diciembre de este mismo año.
115
Tras su utilización en las clases prácticas la herramienta ha
generado un efecto positivo en el proceso de aprendizaje como
muestran los datos presentados en el apartado anterior. Los
resultados obtenidos se pueden considerar satisfactorios en los
siguientes términos:
--Desde el punto de vista de la adquisición de
conocimientos: los alumnos complementan sus conocimientos
teóricos trabajando en un entorno abierto, sencillo y usable, en
el que pueden llevar a cabo diferentes experimentos. Pudiendo
incluso llegar en algunos casos a probar comandos por el mero
hecho de ver cuál es el resultado, siguiendo sus propias
inquietudes. Por otro lado, los alumnos pueden comprobar sus
avances en la adquisición de conocimientos. Como en el caso
comentado en el que dos alumnos con malos resultados se
dieron cuenta de su inadecuado progreso.
--Desde el del seguimiento del proceso de aprendizaje:
el profesor es capaz de hacer un seguimiento exhaustivo de lo
que hacen los alumnos, tanto durante las clases de laboratorio
como fuera del aula. Esto le proporciona un conocimiento muy
preciso del proceso de aprendizaje.
VIII. TRABAJOS FUTUROS
Fig. 8. Accesos al sistema durante el periodo de estudio
Obviando los siete lógicos picos registrados los días en los
que hubo clases prácticas, se ve cómo la herramienta se usa a
lo largo del tiempo, prolongando su utilidad más allá del aula.
Tras la conclusión de este tipo de prácticas, se observan
accesos en el tiempo realizados por alumnos que
complementan la materia impartida en las clases teóricas con
las pruebas que llevan a cabo con el sistema proporcionado.
VII. CONCLUSIONES
El estudio de protocolos de nivel de aplicación es una
materia muy importante en los estudios de Ingeniería en
Informática y de Telecomunicación, así como en sus
modalidades Técnicas. No obstante, los métodos docentes
utilizados para su aprendizaje y comprensión se sustentan en la
mayoría de los casos en la impartición de clases magistrales
acompañadas en ocasiones por la utilización de analizadores
de tráfico y simuladores. Hasta dónde sabemos, no hay
ninguna herramienta de apoyo al aprendizaje basada en la
interacción con servidores reales y que permita a los alumnos
actuar y observar el resultado obtenido.
En este artículo se presenta una herramienta con esas
características, que persigue mejorar el proceso de aprendizaje
de protocolos de nivel de aplicación. Para ello integra el papel
de usuario de un servicio con el de estudiante de Ingeniería en
Informática y de Telecomunicaciones, tratando de mostrar la
relación de los elementos técnicos con los puramente
asociados al uso.
Hay una ampliación evidente del sistema desarrollado
encaminada a la incorporación de nuevos protocolos de nivel
de aplicación. Por ejemplo, protocolos como DNS o IMAP son
susceptibles de ser incorporados en un futuro cercano.
Por otro lado, la parte de interacción con los servidores se
podría mejorar de forma que, además de observar los
protocolos en funcionamiento, se tuviera una vista del
resultado que verían los usuarios finales del servicio. Por
ejemplo, se podría renderizar un documento web obtenido
mediante una petición HTTP o reproducir un vídeo a la vez
que se lleva a cabo el control con el protocolo RTSP.
Asimismo, la parte de evaluación de la herramienta se puede
mejorar notablemente. Ahora solo permite realizar tests, pero
podría incorporar la posibilidad de hacer preguntas de
desarrollo corto, listas de elementos enlazables, modelos de
estados en formato gráfico con información a completar, la
subida de archivos adjuntos (por ejemplo para el envío de una
memoria), etc. Igualmente, los tests se podrían generar de
forma aleatoria, reduciendo la posibilidad de copia a la
mínima expresión. Esta parte de la herramienta también podría
ser complementada con una sección de estadísticas
configurable que nos permita hacer el seguimiento agrupado
de los alumnos, explotando la información de la base de datos.
De esta forma se podrían estudiar resultados obtenidos por
grupo de prácticas, por convocatoria, por curso, etc.
AGRADECIMIENTOS
Este trabajo está financiado parcialmente por la Universidad
de Oviedo mediante el proyecto “Estudio y valoración de la
incorporación de vídeo de forma adaptativa en un entorno de
tele-enseñanza” (PC-07-007) y por el Ministerio de Educación
y Ciencia Español mediante el proyecto INTEGRAMEDIA
(TSI2004-00979).
ISSN 1932-8540 © IEEE
116
IEEE-RITA Vol. 4, Núm. 2, May. 2009
REFERENCIAS
[1] Bereiter, C. y Scardamalia, M. (1985). Cognitive coping
strategies and the problem of “inert knowledge”. En
Thinking and Learning Skills: Research and Open
Question, vol. 2, pp.65-80, Hillsdale, NJ, Erlbaum
[2] Fernandez, I. (2007) Innovar en las aulas escolares a
través de las TIC. En Organización y gestión educativa:
Revista del Fórum Europeo de Administradores de la
Educación, Vol. 15, n 6, pp 30-31
[3] Hnatyshin, V.Y. y Lobo, A.F. (2008) Undergraduate data
communications and networking projects using Opnet and
wireshark software. En Proceedings del 39th SIGCSE
Technical Symposium on Computer Science Education.
Portland, OR, USA
[4] Jipping, M.J., Bugaj, A., Mihalkova, L., Porter, D.E.
(2003) Using Java to teach networking concepts with a
programmable network sniffer, En proceedings del 34th
SIGCSE Technical Symposium on Computer Science
Education, Reno, Nevada, USA
[5] Riabov, V.V. (2006) Challenging projects and virtual labs
in web-enhanced networking technology classes. En
Journal of Computing Sciences in Colleges, Vol. 21, Issue
6, pp. 88 – 99
[6] Melendi, D., Pañeda, X.G., Neira, A., García, R., García,
V. (2005) Simulador Educacional de un Servicio de
Audio/Vídeo Bajo Demanda. En Revista Iberoamericana
de Informática Educativa, IE Comunicaciones. Núm. 2,
pp 35-46.
[7] Imai, A y Yukita, S. (2002) HLPM - A High Level
Protocol Monitoring Tool for Education. En proceedings
del 1st International Symposium on Cyber Worlds
(CW’02), Tokio
[8] Bloom, B.S., Engelhart, M.D., Furst, E.J., Hill,W.H. y
Krathwohl, D.R. (1956). Taxonomy of educational
objectives: The classification of educational goals.
Handbook 1: Cognitive domain. NY, David McKay
[9] Anido, L., Llamas, M., Fernández, M.J. (2001) Internetbased learning by doing. En IEEE Transactions on
Education, Vol 44, n. 2
[10] Combs,
G.
(2008)
Wireshark
Accesible
en
http://www.wireshark.org/, visitado por última vez en
Noviembre de 2008
[11] Savard,
D.
(2008)
Live
http
Headers.
http://livehttpheaders.mozdev.org. Visitada por última vez
en Diciembre de 2008
[12] Lingo4you (2008) Web Sniffer. http://web-sniffer.net/.
Visitada por última vez en Diciembre de 2008
[13] Information Sciences Institute (2008) The Network
Simulator
ns.
http://nsnam.isi.edu/nsnam/index.php/User_Information.
Visitada por última vez en Diciembre de 2008
[14] OPNET Technologies (2008) OPNET modeler: making
networks and applicatios perform. http://www.opnet.com.
Visitada por última vez en Diciembre de 2008
[15] Pullen, J.M. (2000) The Network Workbench: network
simulation software for academic investigation of Internet
Concepts. Comp. Networks, Elsevier, n 32, pp 365-378.
[16] Domínguez, M., Rodríguez, F. J., González, J. L. (2007)
Simulador MPLS para Innovación Pedagógica en el Área
de Ingeniería Telemática. En Revista Iberoamericana de
Tecnologías del Aprendizaje, Núm. 1, Vol. 2, pp 27-34
[17] Carson, M. y Santay, D. (2003) NIST Net: a linux-based
network emulation tool. ACM SIGCOMM Computer
Communication Review, 33(3):111–126
[18] Zheng, P. y Ni., L.M. (2003) Empower: A network
emulator for wireline and wireless networks. En IEEE
INFOCOM’03, San Francisco
[19] Hemminger, S. (2005) Network Emulation with NetEm.
Proceedings del 2005 Linux Conf. (LCA-2005), Australia
[20] Avvenuti, M., Vecchio, A. (2006) Application-level
network emulation: the EmuSocket toolkit. En Journal of
Network and Computer Applications, n 29, pp 343–360
[21] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., Berners-Lee, T. Hypertext Transfer
Protocol -- HTTP/1.1. The Internet Society, 1999
[22] Berners-Lee, T., Connolly, D. Hypertext Markup
Language – 2.0. The Internet Society, 1995
[23] Schulzrinne, H., Rao, A., Lanphier, R. Real Time
Streaming Protocol (RTSP) The Internet Society, 1998
[24] Postel, J.B. Simple Mail Transfer Protocol. The
Information Sciences Institute, 1982
[25] Myers, J., Rose, M. Post Office Protocol – Version 3. The
Internet Society, 1996
[26] Postel, J., Reynolds, J. File Transfer Protocol (FTP). The
Information Sciences Institute, 1985
[27] Postel, J., Reynolds, J. Telnet Protocol Specification. The
Information Sciences Institute, 1983
ISSN 1932-8540 © IEEE
David Melendi Palacio es doctor e ingeniero en
informática y profesor titular de universidad interino
del Área de Ingeniería Telemática del Departamento de
Informática de la Universidad de Oviedo. Es miembro
de diferentes organizaciones, plataformas y comités de
investigación como el SYMM del W3C. Especialista en
servicios de audio/vídeo para Internet.
Xabiel G. Pañeda es doctor e ingeniero en informática
y profesor titular de universidad interino del Área de
Ingeniería Telemática del Departamento de Informática
de la Universidad de Oviedo. El miembro de diferentes
organizaciones, plataformas y comités de investigación
como el SYMM (Shychronized Multimedia) del W3C.
Especialista en servicios de audio/vídeo para Internet.
Roberto García Fernández es doctor e ingeniero de
telecomunicación y profesor titular de escuela
universitaria del Área de Ingeniería Telemática del
Departamento de Informática de la Universidad de
Oviedo. Es especialista en redes de cable e integración
servicios de audio/vídeo sobre las mismas.
Víctor Guillermo García García es doctor e ingeniero
de telecomunicación y catedrático de escuela
universitaria del Área de Ingeniería Telemática del
Departamento de Informática de la Universidad de
Oviedo. Es especialista en redes de cable.
Descargar