Download Servicio Aula Virtual de la Escuela Politécnica de Ciceres 1

Document related concepts
no text concepts found
Transcript
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