6HUYLFLR$XOD9LUWXDOGHOD(VFXHOD3ROLWpFQLFDGH&iFHUHV $QWRQLR3OD]D&DUORV$5DPRV$OIRQVR*D]R-RVp/XLV*RQ]iOH] 'HSDUWDPHQWRGH,QIRUPiWLFD 8QLYHUVLGDGGH([WUHPDGXUD(VFXHOD3ROLWpFQLFDGH&iFHUHV $YGDGHOD8QLYHUVLGDGVQ&iFHUHV(VSDxD DSOD]D#SROLFFXQH[HV&DUORV5DPRV#DERQDGRVFSOXVHVDJD]R#SROLFFXQH[HVMOJV#XQH[HV 5HVXPHQ (QOD(VFXHOD3ROLWpFQLFDGH&iFHUHVVHKDLPSOHPHQWDGRXQVHUYLFLRGHDFFHVRUHPRWRTXH SHUPLWHDODFRPXQLGDGXQLYHUVLWDULDDFFHGHUGHVGHVXGRPLFLOLRDFXDOTXLHUDGHORVVLVWHPDV PXOWLXVXDULRGHO&HQWUR\WDPELpQDODUHG,QWHUQHW/DDVSLUDFLyQGH$XOD9LUWXDOHVRIUHFHU OD SRVLELOLGDG GHO WHOHWUDEDMR DO SHUVRQDO XQLYHUVLWDULR VREUH WRGR D ORV HVWXGLDQWHV TXH SXHGHQ DFFHGHU D ORV VLVWHPDV LQIRUPiWLFRV HQ FXDOTXLHU PRPHQWR DSURYHFKDQGR KRUDULR QRFWXUQR\SHULRGRVYDFDFLRQDOHVHYLWDQGRDVtORVSUREOHPDVGHVDWXUDFLyQHQHODFFHVRDODV VDODV TXH DORMDQ GLFKRV VLVWHPDV \ IDYRUHFLHQGR OD H[SORWDFLyQ GH ORV PLVPRV (Q HVWH VHQWLGR $XOD 9LUWXDO SURSRQH PHMRUDV VXVWDQFLDOHV HQ HO GHVDUUROOR GH OD GRFHQFLD IDFLOLWDQGRODIXWXUDLPSODQWDFLyQGHXQDIUHHQHW\SHUPLWLHQGRHODFFHVRD6,3(36LVWHPDGH ,QIRUPDFLyQ3~EOLFDGHOD(VFXHOD3ROLWpFQLFDTXHRIUHFHVHUYLFLRVWHOHPiWLFRVGHHVSHFLDO LQWHUpVSDUDHVWXGLDQWHVFRPRODFRQVXOWDGHH[SHGLHQWHVDFDGpPLFRVWDEORQHVGHDQXQFLRV FRPXQLFDFLyQFRQHOSURIHVRUDGRFRQVXOWDGHIRQGRVELEOLRJUiILFRVWHOHPDWULFXODFLyQHWF 6H HVWi WUDEDMDQGR HQ OD UHDOL]DFLyQ GH H[WHQVLRQHV PXOWLPHGLD GH $XOD 9LUWXDO GRWDQGR DO VHUYLFLR GH VLVWHPDV GH DXGLR \ YtGHR FRQIHUHQFLD TXH SHUPLWDQ OD HPLVLyQ GH FODVHVRFRQIHUHQFLDVDHVWXGLDQWHVJHRJUiILFDPHQWHGLVSHUVRV 3DODEUDV&ODYH/LQX[, teletrabajo, IUHHQHW, conexión remota, ancho de banda, protocolos de comunicaciones, RTB, ATM, RDSI, multimedia, multicast, 4R6'90533,0073503 ,QWURGXFFLyQ En el contexto universitario las áreas de aplicación de Internet son prácticamente ilimitadas. Desde las aulas de todas las Universidades españolas se realiza gran número de los accesos que la Red recibe diariamente, pero existe el gran inconveniente de que se requiere la presencia de los usuarios Universitarios en sus aulas y/o despachos o el alta en un PSI (Proveedor de Servicios Internet) para poder acceder desde domicilios particulares. Aula Virtual también soluciona este problema aunque esta no sea su principal objetivo. La funcionalidad general del servicio se presenta en la )LJXUD. 1 Este proyecto ha sido desarrollado en parte con los fondos aportados por la Consejería de Educación y Juventud de la Junta de Extremadura para la mejora de la calidad docente (expediente MCD97D024) )LJXUD)XQFLRQDOLGDGJHQHUDOGH$XOD9LUWXDO Aula Virtual pone el teletrabajo al alcance de la Comunidad Universitaria proporcionando a sus usuarios la posibilidad de acceder de forma remota a todos los sistemas multiusuario que la Escuela Politécnica de Cáceres dispone en sus aulas y laboratorios, solventando problemas bastante habituales en todas las Universidades como la masificación de aulas y los inconvenientes derivados de sus horarios de apertura y cierre. De esta forma, los estudiantes pueden acceder a los sistemas de forma “virtual” desde cualquier lugar, en cualquier momento del día y cualquier día de la semana sin estar sujetos a horarios de docencia ni de apertura y cierre de laboratorios. También profesores, investigadores y PAS ven considerablemente facilitada su labor. En la )LJXUD se aprecian las posibilidades de conexión que se ofrecen a los usuarios remotos, que pueden acceder a multitud de sistemas de muy diversas configuraciones, como terminales $6&,,, estaciones de trabajo en red local (la sala 1RUEDpresenta una configuración con más de treinta puestos /LQX[ a los que se puede acceder independientemente) y equipos de altas prestaciones como estaciones de trabajo 6XQ ó 6LOLFRQ *UDSKLFV. Aula Virtual permite además la posibilidad de acceder a unos sistemas a través de otros (por ejemplo, un usuario accede a su cuenta en una máquina /LQX[ a través de su cuenta en otra máquina 6RODULV), favoreciendo así la versatilidad en su explotación. El servicio Aula Virtual ha sido desarrollado teniendo en cuenta una serie de requerimientos principales propuestos como objetivos alcanzables desde el contexto de un Proyecto Fin de Carrera de Ingeniería Informática: • Disponer de un sistema de conexión remota y distribuido para acceder a los equipos multiusuario del Centro (8QL[, 2SHQ906, 1HWZDUH /LQX[), a servicios telemáticos implantados en el mismo como SIPEP (Sistema de Información Pública de la Escuela • • • • • Politécnica de Cáceres) o el acceso a fondos bibliográficos, y a la red ,QWHUQHW a través de la Red Telefónica Básica. Permitir que el acceso de los clientes de Aula Virtual pueda realizarse desde cualquier entorno informático personal (06'26, :LQGRZV[[, 1HWZDUH, 0DF, 8QL[, /LQX[, etc.) Cuidar la calidad del servicio ofrecido (4R6) y también la problemática relacionada con la inseguridad y el uso abusivo e indebido del mismo aplicando restricciones de acceso sobre los usuarios. Registrar información sobre todos los accesos al sistema de forma que puedan elaborarse estadísticas que permitan evaluar la efectividad del servicio y el uso que se hace del mismo. Implementar la solución en una arquitectura de bajo coste que permita una migración del servicio a plataformas de prestaciones más elevadas. Sentar la base para poder ofrecer servicios multimedia de audio y vídeo conferencia sobre tecnología 5'6, y $70 y aprovechando las aplicaciones 0%RQH. 'HFLVLRQHVGHGLVHxRGH$XOD9LUWXDO La elección del sistema operativo en el que se implementa el servicio es una decisión fundamental en el desarrollo del mismo. Las características proporcionadas por el sistema operativo escogido deben ajustarse adecuadamente a los requisitos planteados. La necesidad de disponer de un sistema operativo de red que permita diseñar aplicaciones portables hace que la configuración más adecuada sea la proporcionada por un sistema tipo 8QL[ (ya sea una versión comercial del mismo como 6RODULV o bien una distribución /LQX[[1]). El sistema se ha desarrollado en su primera versión en el sistema operativo /LQX[ que. Las características más interesantes que /LQX[ ofrece para la implementación de Aula Virtual se resumen en sus grandes posibilidades en cuanto a conectividad, su gran capacidad para actuar de forma eficiente como servidor de módems y el soporte de protocolos de comunicación como SLIP (6HULDO/LQH,QWHUQHW3URWRFRO) y PPP (3RLQWWR3RLQW3URWRFRO) [2]. Aula Virtual soporta dos tipos de conexiones remotas diferentes: • El tipo más sencillo permite una conexión por medio de emulación de terminal basada en una sesión WHOQHW con el servidor (ordenador u ordenadores en los que se implementa el servicio Aula Virtual) mediante un determinado programa de emulación de terminal. • A través de Aula Virtual puede accederse a la información multimedia existente en la red Internet, para lo que se requiere la utilización de una conexión analógica GLDOXS a través de los protocolos de comunicación SLIP ó PPP. PPP [3] proporciona permisos o autorizaciones de conexión a los clientes en los dos sentidos de la comunicación. Estos procedimientos de autentificación son totalmente independientes entre sí y se puede diferenciar entre dos protocolos distintos según sea el tipo de autentificación que se realice: • • PAP ó 3URWRFRORGHDXWHQWLFDFLyQSRUFRQWUDVHxD trabaja básicamente de la misma forma que el procedimiento normal de ORJLQ, es decir, el cliente se autentifica a sí mismo enviando un nombre de usuario y una contraseña (opcionalmente encriptada) al servidor, la cual es comparada por el servidor con su base de datos de claves. CHAP ó 3URWRFROR GH DXWHQWLFDFLyQ SRU UHWR no tiene estos defectos, pues el servidor envía una cadena denominada “GHUHWR” generada aleatoriamente al cliente junto con su nombre de máquina local. El cliente utiliza este nombre para buscar la clave apropiada, la combina con la cadena “GHUHWR” y encripta la cadena resultante utilizando una función de codificación unidireccional. El resultado es devuelto al servidor junto con el nombre del ordenador cliente. El servidor realiza ahora la misma computación y advierte al cliente si llega al mismo resultado. La determinación de /LQX[ como sistema operativo y PPP como protocolo de comunicaciones son las decisiones de diseño clave para la implantación de una solución inicial de bajo coste basada en un modelo con una única línea telefónica y un módem de forma que solamente se permite una conexión remota. Esta aproximación inicial resulta de gran utilidad, pues permite definir sobre ella todas las políticas de seguridad referentes a usuarios remotos y realizar pruebas de compatibilidad del sistema, intentando acceder al mismo desde distintas localizaciones y a través de diferentes equipos y sistemas operativos. 6ROXFLyQGHILQLWLYD Una vez superadas las correspondientes pruebas de campo sobre la arquitectura inicial de bajo coste, ésta debe ser ampliada en una serie de puntos clave para obtener el sistema definitivo, que deberá cumplir los siguientes requisitos: • Permitir la gestión eficiente de un número elevado de conexiones remotas al servidor mediante la instalación de un mayor número de líneas de acceso al servicio. Se requiere la incorporación de dispositivos de salto capaces de multiplexar las conexiones remotas que lleguen vía RTB entre los diferentes módems que constituyen la batería de servicio. • Aumentar las prestaciones del sistema facilitando el acceso a través de líneas 5'6,, aumentando el ancho de banda a 64 Kbits/seg e introduciendo la posibilidad de establecer comunicaciones multimedia (voz, datos, imágenes, vídeo). Entre las extensiones multimedia más interesantes podemos citar la incorporación de sistemas de audio y vídeo conferencia basados en la utilización de grupos PXOWLFDVW. • Asegurar la portabilidad del sistema diseñado a otros sistemas 8QL[. Esta portabilidad también debe ser manifiesta entre diferentes versiones del sistema operativo /LQX[. • Gestionar de forma eficiente los datos que debe manejar el sistema referentes a usuarios del servicio, características de las conexiones proporcionadas por el mismo y estadísticas de uso mediante un modelo de base de datos relacional con posibilidad de distribución como 25$&/( ó 64/ 6HUYHU con el claro objetivo de que Aula Virtual tenga la funcionalidad de sistema distribuido. • Reforzar la aplicación de las políticas de seguridad sobre los usuarios mediante la incorporación del software necesario para que el sistema funcione estrictamente como un ILUHZDOO, aunque su comportamiento es ya de por sí una simulación de un cortafuegos en función de las políticas de seguridad aplicadas. Actualmente, el sistema se encuentra en fase de explotación sobre dos PCs con sistema operativo /LQX[ y la configuración que se observa en la )LJXUD, lo cual no impide que, al mismo tiempo, se estén introduciendo modificaciones para mejorarlo. Entre estas modificaciones resaltaremos la creación de una red independiente del bus (WKHUQHW disponible en el campus, entre las máquinas que conforman el sistema Aula Virtual. De este modo se alcanzan tres objetivos: a) El funcionamiento interno del sistema no se verá afectado por condiciones de tráfico denso o saturación en el bus (WKHUQHW del campus, ya que los ordenadores que componen el sistema serán ajenas a todo este tráfico, b) El sistema no introducirá tráfico de red en el bus (WKHUQHW del campus más que para la transmisión de datos con las máquinas externas al sistema, ya que todas las transmisiones de datos que involucren sólo a máquinas del Aula Virtual se realizará a través de su propia red, y c) de este modo se consigue la implantación final de un ILUHZDOO, ya que las máquinas del sistema Aula Virtual no serán visibles desde el exterior (a excepción del ordenador que disponga del interfaz (WKHUQHW conectado al bus del campus). Además se ha optado por distribuir los módem entre los sistemas que componen el Aula Virtual, para repartir la carga de trabajo. El que un ordenador tenga a su cargo algún módem hace que esta máquina deba disponer de los datos acerca de los usuarios registrados en el sistema. Estos datos deben ser compartidos entre todos los ordenadores del sistema, ya que nunca se podrá asegurar que un determinado usuario siempre accederá a través de un determinado módem. En consecuencia, es necesaria una GLVWULEXFLyQ de estos datos, y que, en la medida de lo posible, sea WROHUDQWH D IDOORV. Por ello, se optó por configurar uno de los ordenadores del sistema como VHUYLGRU 1)6 [4], para poder exportar el sistema de ficheros que contiene los datos relativos a los usuarios del sistema. El resto de las máquinas PRQWDUi este sistema de ficheros exportado por NFS sobre su propio sistema de ficheros. Si uno de los clientes "cae", el resto no se verán afectados, consiguiéndose de este modo que su funcionamiento sea independiente. ,PSOHPHQWDFLyQ Aula Virtual ha sido desarrollado siguiendo los pasos del ciclo de vida estructurado de desarrollo de un proyecto de ingeniería: • Se comenzó definiendo claramente el problema a resolver. • Se realizó un estudio de viabilidad en el que se establecieron un prototipo inicial de bajo coste o simulación del sistema y la solución definitiva como extensión del prototipo. • Se llevó a cabo un análisis de los datos que el sistema debe manejar (relativos a usuarios del sistema, sistemas a los que se proporciona acceso y a ORJV o información general sobre cada una de las conexiones establecidas). • Se estudiaron las entradas y salidas del sistema y se definió la interfaz de usuario para los programas elaborados (diseño del sistema) • Finalmente, se llevó a cabo la implementación definitiva del sistema y, de forma paralela, se realizó el mantenimiento del mismo, aplicando las correspondientes políticas de seguridad sobre datos de usuarios, contraseñas y ficheros. Comenzamos analizando las modificaciones realizadas en la configuración del sistema operativo base para implementar el servidor Aula Virtual. &RQILJXUDFLyQGHOVLVWHPDRSHUDWLYR Para incorporar el hardware de red al servidor es necesario realizar un estudio previo de los GULYHUV de dispositivos soportados por el NHUQHO de /LQX[ y los nombres de las interfaces que utilizan [5]. El nombre de interfaz genérico para la mayoría de las tarjetas (WKHUQHW es (WKQ para la tarjeta Q-ésima. Existen otros manejadores de LQWHUIDFH como los de RDSI que pueden ser añadidos en el futuro. Una vez determinados los manejadores de interés se procede a la instalación de la tarjeta de red (WKHUQHW en el ordenador servidor. En tiempo de arranque, el NHUQHO intentará localizar la tarjeta y determinar su tipo. Si el proceso de autoverificación no consigue detectar la tarjeta, será necesario indicar explícitamente al NHUQHO el nombre y dirección base de la misma en el programa de arranque del sistema [6]. El siguiente paso es realizar la incorporación de los módems a la configuración. Para poder establecer conexiones desde el módem y permitir llamadas entrantes se utiliza el GDHPRQ XXJHWW\, que requiere la previa actualización del fichero de configuración HWFJHWW\GHIV, incluyendo las entradas correspondientes para cada uno de los módems [7]. Una vez hecho esto, es necesario añadir una entrada en el fichero HWFLQLWWDE para que XXJHWW\ se ejecute en el puerto serie adecuado, incluyendo la información adecuada para que XXJHWW\ se ajuste a nuestro entorno local: dispositivo serie, velocidad, situación del fichero de configuración del dispositivo y tipo de terminal. Una vez incorporados los módems, el lanzamiento del proceso LQLW permitirá que el sistema operativo compruebe continuamente las líneas serie para detectar posibles conexiones a través de él. Este es el momento de incorporar el software de gestión de conexiones remotas $XODG, que recibe este nombre debido a sus características de GDHPRQ que se activará cada vez que se reciba una entrada remota por alguna de las líneas serie WW\V. En este punto Aula Virtual está capacitado para actuar como servidor de conexiones remotas tipo WHOQHW. El fichero HWFKRVWV debe contener los sistemas a los que el servidor Aula Virtual proporciona acceso remoto. Para que el sistema adquiera además la funcionalidad de PSI es necesario configurar el protocolo TCP/IP en el servidor, asignándole un nombre de KRVW y una dirección IP, habilitando un mecanismo de resolución de nombres mediante la inclusión de entradas en el fichero HWFUHVROYFRQI y asignando a la interfaz (WKHUQHW la dirección IP de la máquina local mediante la utilidad LIFRQILJ. La asignación de direcciones IP a los usuarios remotos será dinámica, es decir, cada vez que un usuario remoto se conecte a Aula Virtual se le asigna una dirección IP diferente en función del módem que haya atendido su petición [8] [9] [10]. Por último, es necesario incorporar la funcionalidad de servidor PPP al servidor Aula Virtual, lo que se consigue modificando el programa $XODG para que permita conexiones PPP mediante la ejecución del VFULSW o programa VKHOO de entrada HWFSSSSSSORJLQ, encargado de establecer una conexión PPP entre el servidor y la máquina llamante mediante la ejecución del programa SSSG con las opciones adecuadas. Con respecto a los procedimientos de autentificación de PPP, decir que SSSG mantiene las claves secretas PAP y CHAP para los sistemas remotos en los ficheros HWFSSSSDSVHFUHWV y HWFSSSFKDSVHFUHWV. En el fichero HWFSSSRSWLRQV se puede activar la opción DXWK para hacer que SSSG solicite a los sistemas remotos que se autentifiquen mediante CHAP o PAP (por este orden) siempre y cuando se disponga de una clave para el sistema remoto en HWFSSSFKDSVHFUHWV o en HWFSSSSDS VHFUHWV. De esta forma puede garantizarse que ningún sistema se conecta al servidor sin ser previamente autentificado [11]. *HVWLyQGHFRQH[LRQHVUHPRWDV La interacción entre el servicio Aula Virtual y los usuarios remotos del mismo se muestra gráficamente en la )LJXUD. Nos detendremos de forma más específica en el proceso de gestión de conexiones remotas, realizada por el programa $XODG. Este programa funciona como un GDHPRQ que se activa cada vez que se produce una conexión remota por medio del programa XXJHWW\, encargado de proporcionarle el ORJLQ del usuario remoto como se observa en la )LJXUD. La primera operación que realiza $XODG es la validación del usuario remoto solicitando su SDVVZRUG, encriptándola y comparando el resultado con el que tiene almacenado en su registro de datos. Si el usuario no existe en la base de datos o la contraseña no es correcta, $XODG cierra automáticamente la conexión. Si por el contrario la validación de la clave es satisfactoria, se muestran al usuario las diferentes modalidades de conexión de que dispone. )LJXUD,QWHUDFFLyQHQWUH$XOD9LUWXDO\ XVXDULRVUHPRWRV Una vez que el usuario remoto ha realizado su selección, aprovechando las características multiproceso del sistema operativo base, el proceso $XODG crea un proceso KLMR que se encargará de establecer la conexión solicitada por el usuario. Mientras tanto, el proceso $XODG se encarga de controlar el tiempo que el usuario permanece dentro del sistema. Para ello, entra en un bucle del que saldrá cuando finalice el tiempo diario asignado al usuario remoto o bien cuando reciba un VLJQDO 6,*865 del proceso KLMR indicándole que el usuario remoto ha cerrado la conexión. El proceso KLMR debe replicarse de nuevo en un proceso KLMR. Esto se debe a la posibilidad de que KLMR termine de forma anormal al recibir alguna señal, con lo que no podría enviar la correspondiente señal al proceso SDGUH indicándole que ha terminado su tarea. Será por tanto KLMR el proceso encargado de establecer la conexión remota. Cuando KLMR termine, enviará una señal a KLMR; en el momento que KLMR la detecte, enviará un VLJQDO 6,*865 al proceso $XODG que, al recibirlo, enviará un VLJQDO 6,*.,// a KLMR, matándolo. El proceso $XODG también puede matar a KLMR sin haber recibido el VLJQDO 6,*865. Este hecho se produce cuando $XODGdetecta que el usuario ha consumido su tiempo diario de conexión, cerrando automáticamente la conexión. Cuando falte un minuto para que expire el tiempo del usuario, $XODG le enviará un mensaje de aviso, concediéndole así el tiempo necesario para salvar su trabajo en disco (a no ser que el sistema esté soportando un número muy reducido de conexiones remotas en ese momento, caso en el que se permitirá la continuidad del usuario cuyo tiempo ha expirado). La última tarea que realiza el proceso $XODG es anotar en forma de ORJ cierta información significativa sobre la conexión remota que acaba de tener lugar, como el ORJLQ del usuario remoto que inició la conexión, el nombre del sistema al que ha accedido, la fecha en que se produjo la conexión, la hora exacta en que comenzó y la duración total de la misma. Cada ORJ describe únicamente una conexión. Toda esta información se utiliza para generar estadísticas de uso del sistema y para mantener el DFFRXQWLQJ de Aula Virtual. A continuación se detallan los procesos que tienen lugar en la gestión de conexiones en pseudocódigo: 3URFHVR$XODG^ 3URFHVRKLMR^ Obtener 3DVVZRUG del usuario remoto; Encriptar 3DVVZRUG y comparar con el almacenado en el registro; Si 3DVVZRUG correcta { Obtener Tiempo_Máximo de permanencia del usuario; Tiempo_Aviso=Tiempo_Máximo-60 segundos; Mostrar opciones de conexión al usuario; Solicitar al usuario el Tipo_Conexión que desea; Crear Hijo1; Salir=FALSO; Mientras (No Salir) { Si Signal_Recibida=SIGUSR1 { Salir=CIERTO } Si Tiempo_Usuario>Tiempo_Aviso mensaje $9,62 a usuario; Si Tiempo_Usuario=Tiempo_Máximo { mensaje ),1&21(;,Ï1 a usuario; Salir=CIERTO; } Enviar_Signall(SIGKILL,Hijo1); Anotar información relevante sobre la conexión (ORJ) } Crear Hijo2; Salir=FALSO; Mientras (No Salir) { Si Signal_Recibida=SIGUSR2 { Enviar_Signal(SIGUSR1,Aulad); Salir=Cierto; } } ` 3URFHVRKLMR^ Si Tipo_Conexión=PPP Ejecutar script ppp-login Si Tipo_Conexión=Telnet Ejecutar comando telnet Enviar_Signal(SIGUSR2, Hijo1) ` ` )LJXUD3URFHVRVTXHLQWHUYLHQHQHQODJHVWLyQGHFRQH[LRQHVUHPRWDV 6HJXULGDGGHOVLVWHPD\HYDOXDFLyQGHVXUHQGLPLHQWR Para garantizar la correcta explotación del servicio es indispensable aplicar una serie de políticas de seguridad sobre los usuarios remotos con el fin de controlar la utilización que éstos realizan de los recursos del sistema. En un sistema como el que nos ocupa, con una demanda elevada y previsiblemente creciente con el paso del tiempo, es innegable la necesidad de implantar mecanismos capaces de evitar la monopolización y el reparto inadecuado de recursos. • El sistema únicamente permite el acceso de usuarios registrados. En la solicitud de alta en el servicio el usuario especificará los sistemas a los que desea tener acceso. Esta solicitud será revisada por el personal competente. Una vez que el usuario haya sido dado de alta formalmente, se le asignarán datos administrativos como un tiempo máximo diario de permanencia en el sistema y una fecha tope como usuario válido. • Para evitar la sobrecarga de los sistemas multiusuario se limitará la utilización de los mismos de forma remota en horas punta, es decir, en horas en que la utilización de los mismos por estudiantes presentes en las salas que los albergan sea tal que se desaconseje la explotación remota simultanea. El estudio de la información contenida en los ficheros de ORJV permite elaborar estadísticas de uso del servicio para evaluar la FDOLGDG del servicio ofrecido. Aula Virtual dispone de un programa de administración independiente del programa de gestión de conexiones mediante el que se puede efectuar la gestión de usuarios y sistemas accedidos. Además, este programa es capaz de generar diversas de estadísticas de interés para los administradores, como el número de veces que un determinado usuario ha utilizado el servicio; el tiempo total que ha utilizado cada uno de los sistemas a los que ha accedido; porcentajes de utilización del servicio según franjas horarias o días de la semana; porcentaje de utilización de cada uno de los sistemas, etc. Es importante destacar que este programa de gestión únicamente puede ser utilizado por los administradores del sistema. (VWDGtVWLFDVGHXVRGHOVLVWHPD Aula Virtual se encuentra en plena fase de implantación y explotación y los primeros resultados de uso del sistema ()LJXUD) coinciden con la celebración de las VIII Jornadas de Paralelismo en la ciudad de Cáceres, organizadas por el Dpto. de Informática de la Escuela Politécnica en Septiembre de 1997. Durante las jornadas, Aula Virtual registró una gran actividad al dar servicio a todos los asistentes a las jornadas. El limitado número de usuarios inicial se ha visto incrementado de forma progresiva, aumentando el porcentaje de utilización del sistema por mes, valor que alcanza un máximo en periodos vacacionales en los que los que se favorece la explotación remota de los sistemas. El número de usuarios está en pleno crecimiento lo mismo que las horas de presencia en el sistema. 100 90 80 70 60 50 40 30 20 10 0 s ep -9 7 oct -97 nov-97 N úmero de usuarios dic-97 ene-98 feb-98 m ar-98 abr-98 m ay -98 Horas de uso del sistema (Elapsed time) )LJXUD(VWDGtVWLFDVGHXVRGH$XOD9LUWXDO 7UDEDMRVIXWXURV La propuesta del servicio Aula Virtual va más allá de proporcionar acceso controlado a los sistemas multiusuario de la Universidad, o acceso a la propia Internet. En este aspecto, se proponen los siguientes trabajos como ampliación del sistema, algunos de los cuales están siendo desarrollados actualmente: • • • Dotar de características multimedia al sistema, tanto en tiempo diferido como en tiempo real. De este modo, el personal docente podrá poner a disposición de los alumnos material multimedia como sesiones prácticas o teóricas accedidas desde audio e incluso vídeo. Del punto anterior surge la necesidad de incorporar al Aula Virtual un esquema organizativo que permita a los profesores anunciar la disposición de este material audiovisual. Cada profesor dispondrá de un espacio delimitado y organizado de forma que se establezca una estructura claramente definida, de modo que el sistema resulte claro, intuitivo e útil. Para realizar todo esto, se propone la implantación de un interfaz basado en web. Optimizar las transmisiones de información multimedia, tanto en tiempo real como en tiempo diferido, incorporando métodos de transmisión PXOWLFDVW[12] al sistema. La • implantación de estos métodos permitirá a) reducir el ancho de banda consumido debido a la replicación de los paquetes que contienen la misma información y b) reducir el tiempo de computación necesario para la propia replicación de estos paquetes, lo que permitirá optimizar los recursos informáticos con los que se cuenta[13]. Como protocolos de transmisión, inicialmente se proponen DVMRP[14] y PIM. Realización de un estudio sobre los protocolos PXOWLFDVW empleados. Los protocolos propuestos ofrecen FDOLGDG (QoS)[15] de servicio, pero no garantizan la entrega de los paquetes PXOWLFDVW a todos los miembros del grupo. Se propone el estudio de protocolos que, ofreciendo garantía de servicio, como MTP[16] o RMP, no resultan adecuados para la transmisión de información multimedia, debido a que utilizan una gran cantidad de recursos de comunicación en realizar una garantía HIHFWLYD de servicio. Por ello, se tratará de desarrollar un protocolo que, resultando adecuado para la transmisión de información multimedia, también pueda ofrecer JDUDQWtD de servicio (GoS). &RQFOXVLRQHV Aula Virtual es un servicio que se ofrece como resultado del desarrollo de un PFC de Ingeniería Informática que además puede ser utilizado desde el punto de vista docente en las prácticas de asignaturas como Redes de Computadores, Servicios Telemáticos, Administración de Sistemas e incluso Ingeniería del Software, pues en su elaboración se han empleado técnicas del ciclo de vida estructurado. Su principal motivación es facilitar el desarrollo de la docencia, proporcionando un mecanismo de acceso remoto a sistemas multiusuario de características diversas y aplicando políticas orientadas a garantizar la calidad del servicio ofrecido y a regular su seguridad y su adecuada explotación. Aula Virtual presenta importantes funcionalidades adicionales como sistema distribuido con extensiones multimedia y aspiraciones de IUHHQHW en un contexto universitario. 5HIHUHQFLDV [1] Linux, the Complete Reference, 5LFKDUG3HWHUVHQ, O´Reilly & Associates, 1995 [2] Using Linux, -DFN7DFNHWW, Prentice Hall 1996 [3] http://sunsite.unc.edu/mdw/LDP-books/nag-1.0/nag.html 7KH1HWZRUN$GPLQLVWUDWLRQ*XLGH2ODI.LUVFK [4] http://sunsite.unc.edu/mdw/HOWTO/NFS-HOWTO.html 1)6+RZ7R [5] http://sunsite.unc.edu/mdw/HOWTO/kernel-HOWTO.html .HUQHO+RZ7R [6] http://sunsite.unc.edu/mdw/HOWTO/NET-2-HOWTO.html 1HWZRUN&RQILJXUDWLRQ+RZ7R [7] http://www.in.net/info/modems/index.html 6HULDO+RZ7R [8] TCP/IP Illustrated, Volumes I & II, :5LFKDUG6WHYHQV, Addison-Wesley 1994 [9] http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade 7&3,3+RZ7R [10] Unix Network Programming, :5LFKDUG6WHYHQV Prentice-Hall 1990 [11] http://www.interweft.com.au/other/ppp-howto/ppp-howto.html 333+RZ7R [12]0%RQH\ODVDSRUWDFLRQHVGHOPXOWLFDVWLQJDORVVHUYLFLRVPXOWLPHGLDHQ,QWHUQHW, José Luís González, J. Caballero, M.S. Sánchez, Novática 1996 [13] 5HTXLUHPHQWVIRU0XOWLFDVW3URWRFROV. RFC-1458 [14] 'LVWDQFH9HFWRU0XOWLFDVW5RXWLQJ3URWRFRO. RFC-1075 [15] WK,),3,QWHUQDWLRQDO:RUNVKRSRQ4XDOLW\RI6HUYLFH,:426 [16] 0XOWLFDVW7UDQVSRUW3URWRFRO. RFC-1301 $701HWZRUNV&RQFHSWVSURWRFROVDSSOLFDWLRQV Händel, Huber y Schröder $V\QFKURQRXV7UDQVIHU0RGH6ROXWLRQIRUEURDGEDQG,6'1. Martin de Pricker http://webepcc.unex.es: Páginas de información del Servicio Aula Virtual