$XOD9LUWXDOH[WHQVLRQHVPXOWLPHGLD

Transcripción

1 $XOD9LUWXDOH[WHQVLRQHVPXOWLPHGLD $OIRQVR*D]R&HUYHUR$QWRQLR3OD]D0LJXHO -RVp/XLV*RQ]iOH]6iQFKH]$QWRQLR0DQXHO6LOYD/XHQJR 'HSDUWDPHQWRGH,QIRUPiWLFD 8QLYHUVLGDGGH([WUHPDGXUD(VFXHOD3ROLWpFQLFDGH&iFHUHV $YGDGHOD8QLYHUVLGDGVQ&iFHUHV(VSDxD 5HVXPHQ (QXQLQWHQWRSRUDSRUWDUQXHYDVWpFQLFDVSDUDODPHMRUDGHODFDOLGDGGRFHQWHVHSURSXVRHQOD(VFXHOD 3ROLWpFQLFDGH&iFHUHV HO SUR\HFWR $XOD 9LUWXDO FRQ OD LQWHQFLyQ GH RIUHFHU OD SUiFWLFD GHO WHOHWUDEDMR D WRGD OD FRPXQLGDG XQLYHUVLWDULD 0HGLDQWH FRQH[LRQHV UHPRWDV VH SHUPLWH HO DFFHVR D WRGRV ORV VLVWHPDV LQIRUPiWLFRV PXOWLXVXDULR GHO FHQWUR \ D,QWHUQHW (O p[lwr GHO VHUYLFLR KD MXVWLILFDGR OD UHDOL]DFLyQ GH H[WHQVLRQHV PXOWLPHGLD SDUD GRWDU D $XOD 9LUWXDO GH VLVWHPDV GH DXGLR \ YtGHRFRQIHUHQFLD TXH SHUPLWHQ OD HPLVLyQ GH FODVHV \R FRQIHUHQFLDVDUHFHSWRUHVJHRJUiILFDPHQWHGLVSHUVRV /DV FDUDFWHUtVWLFDV PXOWLPHGLD VRQ DSRUWDGDV SRU GRV YtDV GLIHUHQWHV GH XQ ODGR OD JUDEDFLyQ GH FODVHV WHPDVRFXDOTXLHUPDWHULDOGRFHQWHSDUDTXHORVHVWXGLDQWHVSXHGDQUHYLVDUORHQGLIHULGRFXDQGRHVWpQLQWHUHVDGRV \ SRU RWUR ODGR OD SRVLELOLGDG GH DFFHGHU SRU DXGLR \ YLGHRFRQIHUHQFLD D VHVLRQHV HPLWLGDV HQ WLHPSR UHDO /D LPSODQWDFLyQGHOVLVWHPDQRKDHVWDGRH[HQWDGHFRPSOHMLGDGHVTXHVRQEUHYHPHQWHUHODWDGDVHQHVWHGRFXPHQWR 3HUR VREUH WRGR HO VHUYLFLR QRV HVWi SHUPLWLHQGR UHDOL]DU HVWXGLRV GH ORV IOXMRV GH LQIRUPDFLyQ JHQHUDGRV H LQYHVWLJDUODSURSXHVWDGHSURWRFRORVGHFRPXQLFDFLRQHVTXHDSRUWHQ4R6HQUHGHV,3\$70 3DODEUDV &ODYH ancho de banda, $70, conexión remota, IUHHQHW, información multimedia, /LQX[, PXOWLFDVW, protocolos de comunicaciones, 4R6teletrabajo, 57%, 5'6,.,QWURGXFFLyQ Aula Virtual [1] fue un primer intento por ofertar a la comunidad universitaria el teletrabajo y paliar los inconvenientes de salas colapsadas en horas punta y vacías en horarios no lectivos (horarios nocturnos, fines de semana y periodos vacacionales). Posteriormente se ha demostrado la necesidad de acceder a informaciones multimedia lo que ha propiciado elaborar extensiones del sistema dando lugar a $XOD 9LUWXDO 0XOWLPHGLD. El servicio está operativo y en explotación y se presenta como un sistema distribuido pensado para soportar la conexión remota a sistemas operativos multiusuario (8QL[, 2SHQ906, /LQX[, 1HWZDUH) que ponen al alcance de sus usuarios avanzados servicios telemáticos. Este documento presenta en primer lugar la configuración del sistema y las decisiones de diseño tomadas en su elaboración. A continuación se presentan los servicios multimedia ofrecidos, seguido de las consideraciones técnicas que implican esos servicios multimedia y de las extensiones PXOWLFDVW que ha sido necesario añadir al proyecto $XOD9LUWXDO 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)

2 inicial. Se presentan después las estadísticas de uso del servicio durante los primeros meses, seguidas de los trabajos que están en desarrollo en la actualidad aprovechando los flujos de información que el propio servicio Aula Virtual Multimedia está generando. Las conclusiones se encargan de finalizar el artículo. &RQILJXUDFLyQ GHO VLVWHPD \ GHFLVLRQHVGHGLVHxR A continuación se presenta la topología del sistema $XOD 9LUWXDO 0XOWLPHGLD, con todos los servicios que se ofertan. En la )LJXUD se identifican cuatro grandes bloques. El EORTXH$ corresponde con una sala con 30 sistemas /LQX[/:LQGRZV conectados con el exterior a través de una estación 63$5&, que actúa de URXWHU. El EORTXH% es el que conforma el VHUYLFLRGH DFFHVR UHPRWR del $XOD 9LUWXDO 0XOWLPHGLD. El EORTXH& se encuentra conectado a los buses (WKHUQHW presentes en el campus en el que se encuentra el servicio $XOD 9LUWXDO 0XOWLPHGLD. A estos buses (WKHUQHW se encuentran conectados gran cantidad de PCs, ubicados generalmente en los despachos del personal docente. Por último, el EORTXH' representa una red de PCs con Windows 3.11, utilizado principalmente para las prácticas que no requieren de máquinas potentes. Esta red dispone de un servidor 1HWZDUH, que actúa como servidor de archivos y URXWHU,3;. Además existe un EULGJH TCP/IP que une esta red con uno de los buses (WKHUQHW del campus. Tras el diseño del servicio $XOD 9LUWXDO 0XOWLPHGLD existen una serie de decisiones que se fueron tomando dependiendo, principalmente, de dos factores: Primero, el objetivo de dotar al sistema de un carácter GLVWULEXtGR, en el sentido de intentar que el fallo de alguno de los sistemas no redundara en el fallo global de todo el servicio $XOD 9LUWXDO 0XOWLPHGLD. Segundo, un factor al que está sometido prácticamente todo proyecto: el coste, y el grado de aprovechamiento de la infraestructura ya existente, intentando reutilizar recursos informáticos, así como de reducir los costes de los equipos que fuese necesario incorporar. Bloque A ATM Lupe ( ) sendmail popd Internet Ordenador personal Norba ( ) Sande ( ) Mbone ( ) httpd msql mrouted pppd named nfsd mrouted Datos Avirtual ( ) Bloque C Avirtual2 ( ) pppd mrouted Gateway Servidor Netware Router IPX Puente TCP/IP Ethernet Modem Modem Modem Modem Modem Modem Modem Modem Bloque B )LJXUD7RSRORJtDGHOVLVWHPD$XOD9LUWXDO0XOWLPHGLD Bloque D

3 A continuación se describen brevemente los servicios básicos que se ofertan desde el $XOD9LUWXDO 0XOWLPHGLD. 6HUYLFLRGHDFFHVRUHPRWR Al diseñar el servicio de acceso remoto, se partió de la idea de disponer de un sistema compuesto por varias máquinas, de forma que el fallo de alguna de ellas no supusiera el fallo global del servicio de acceso remoto. Puesto que se va a dotar al sistema con un número de líneas de 57%, lo primero que se debe comprender es el funcionamiento de dichas líneas. Cuando en un sistema existen varias líneas de teléfono asociadas a un mismo número, el número principal se configura en lo que se denomina GLVSRVLWLYRGHVDOWR. Cuando se reciba una llamada por el número principal, el dispositivo intentará conectar con la primera línea. Si ésta estuviera ocupada, pasará a la segunda, y así hasta intentarlo con todas las líneas disponibles, según el esquema de la )LJXUD. Dispositivo primario de salto Dispositivo secundario de salto Líneas de teléfono )LJXUD'LVSRVLWLYRGHVDOWR Ahora supongamos que la máquina a la que se encuentra conectado el módem instalado en la primera línea fallara. Si esta máquina falla, el primer módem no responderá a la llamada, y puesto que la línea no está ocupada, el dispositivo de salto no actuará. Por ello, se decidió instalar dos GLVSRVLWLYRV GH VDOWR. El primero, principal, comienza por el módem 1. El número secundario comienza por el módem N/2, estando este módem controlado por una máquina diferente al módem 1. Si un usuario trata de establecer una conexión utilizando el número principal, y la línea no es descolgada, le quedará la opción de intentarlo con el número secundario. Una vez que tenemos las líneas 57%, se debe decidir el protocolo de conexión remota a utilizar. Cuando hablamos de Internet, existen dos protocolos básicos de conexión remota: SLIP [6] PPP [7] Optamos por la implantación de un servicio de acceso remoto basado en 333, ya que este protocolo permite la negociación de direcciones,3 de forma dinámica, funciones de autentificación, y un rango mayor de protocolos de compresión, que también son negociados entre los dos extremos. Sin duda es una ventaja que los nuevos sistemas operativos incorporen 333 como parte de su distribución básica, pero en algunos casos, los fabricantes modifican ligeramente el protocolo para adaptarlo a las características de su sistema operativo[8]. Por ello, se tomó la decisión de adoptar un sistema operativo que proporcionara facilidades para futuras modificaciones y extensiones del protocolo. Además, puesto que el servicio de acceso remoto también proporcionará servicios basados en PXOWLFDVWLQJ[5], un sistema 81; parecía la mejor elección. Tomando en cuenta estos dos factores, así como el costo de implantación, la decisión final se tomó a favor de Linux. De este modo, se utilizaron dos ordenadores personales a los que se instalaron controladoras serie multipuerto. Para facilitar el acceso en modo 333, se crearon una serie de 6FULSWV de conexión automática para los sistemas operativos más utilizados. De este modo, el usuario que desee conectarse mediante 333 no tendrá que seleccionar en cada ocasión la opción correspondiente del menú. La tecnología actual en 57% permite utilizar un ancho de banda de hasta 33600bps. Por ello, con el fin de optimizar el ancho de banda disponible a través de las líneas 57%, se instalaron módem de 33600bps que además soportaran compresión 9. De este modo disponemos de una compresión a nivel hardware que mejorará la velocidad de las transmisiones, bien vía 333 o bien a través de la emulación de terminal. Aun disponiendo de un esquema de compresión a nivel hardware, también se implantaron varios esquemas de compresión a nivel software, soportados directamente por el protocolo 333, con lo que no son aplicables a las sesiones en emulación de terminal. Estos esquemas son los siguientes: Compresión Van Jacobson [9] Compresión BSD [10] Compresión Deflate [11] La compresión 9DQ-DFREVRQ se aplica tan sólo a los encabezados de 7&3,3, y no globalmente al contenido de los paquetes enviados a través de la línea 333. Así, se puede usar conjuntamente con un esquema de compresión de información, bien 9, %6' o 'HIODWH. La compresión %6', del mismo modo que la compresión 9, se basa en técnicas /=:. La diferencia entre 9 y %6' es que 9 utilizará un tamaño de código de 10, 11 o 12 bits, mientras que

4 %6' puede utilizar un tamaño de hasta 15 bits, obteniendo un ratio de compresión mucho mejor. La compresión 'HIODWH, por su parte, utiliza el mismo algoritmo de compresión que J]LS, lo que le dota de mejores ratios de compresión que los esquemas anteriores. Las pruebas que se han podido hacer desde la puesta en marcha del servicio apuntan a la activación de compresión software siempre que el sistema operativo lo permita, inhabilitando la compresión hardware del módem, que generalmente resulta más lenta y ofrece menores ratios de compresión. Continuando con la optimización del servicio de acceso remoto, se pasaron a estudiar posibles técnicas para minimizar la latencia de resolución '16 [12][13]. Se implanta un servidor '16 en una de las máquinas que forman parte del servicio de acceso remoto. Esta máquina es configurada para que el servidor '16 sea un servidor secundario de la zona a la que pertenecen los sistemas de la universidad, así como un servidor caché [14]. El servicio caché consiste en el almacenamiento de las peticiones '16 que se le hacen al servidor. Cuando se hace una petición '16 al servidor, y el nombre no pertenece a la zona de la universidad, el servidor consulta sus tablas internas para comprobar si dispone de esa entrada. Si dispone de la entrada, comprueba si hubiera caducado, y si no ha caducado, devuelve la petición directamente. De este modo, no ha sido necesario emitir ni un solo paquete a través de la red Ethernet para resolver la petición. Se deternina que una entrada ha caducado a partir del registro 62$ que toda zona '16 posee. El resto de las máquinas que componen el servicio de acceso remoto tendrán, en su fichero UHVROYFRQI, el,3 correspondiente a la máquina del $XOD 9LUWXDO 0XOWLPHGLD en la que esté lanzado el servidor '16. Pero además tendrán los IP de otros servidores '16 ubicados en la universidad. De este modo, se evitará la inhabilitación del servicio de nombres en caso de que fallara el servidor '16 ubicado en el contexto del $XOD9LUWXDO0XOWLPHGLD. Inicialmente se valoró la idea de lanzar un servidor '16 en todas las máquinas que ofrecen el servicio de acceso remoto, pero se optó por instalarlo tan sólo en una máquina por varios motivos: puesto que las máquinas que forman el servicio de acceso remoto se encuentran directamente conectadas por una red Ethernet 10BaseT, el tiempo de respuesta a una petición y el impacto sobre el tráfico de red se consideró lo suficientemente bajo, y el como para no justificar la existencia de un daemon '16 en todas las máquinas. Además, la configuración del servidor en modo caché permitirá aprovechar la resolución de peticiones anteriores; si existieran distintos daemon DNS, se podrían producir peticiones idénticas sobre daemon distintos, lo que aumentaría el tiempo de resolución. 6HUYLFLRZHE Al plantear la necesidad de un sistema de información para el servicio $XOD9LUWXDO0XOWLPHGLD, inmediatamente se pensó en un sistema basado en web. Se estimó un elevado número de accesos a este sistema (en la actualidad se superan los accesos mensuales), lo que conllevaría una carga de trabajo que debería ser manejada por una máquina con una capacidad de cómputo no demasiado baja. Por ello, se pensó en un sistema 63$5& 6\VWHP, que tan sólo ejercía labores de pasarela entre distintas subredes de la universidad. De este modo, además, se conseguiría un acceso directo al sistema de información desde cualquiera de las subredes, reduciendo el tráfico de red. Para el sistema de información, se instaló un servidor +773, así como un servidor de bases de datos, para almacenar las referencias a la información almacenada [4]. En caso de fallo de este sistema, no sólo se verá afectado el sistema de información, sino que también el enrutamiento entre las distintas subredes, tanto en modo XQLFDVW[5] como en modo PXOWLFDVW[5]. La probabilidad de fallo debe ser mínima, no ya sólo por la participación del sistema en el servicio $XOD9LUWXDO 0XOWLPHGLD, sino por ser una parte importante en el sistema de comunicaciones de la universidad. &RUUHRHOHFWUyQLFR Un servidor de correo electrónico generalmente no requerirá de una máquina con una gran capacidad de cómputo. Se planteó la idea de confinar el servicio de correo electrónico en una máquina dedicada, debido a que el servicio de correo electrónico podría fallar de forma temporal, sin afectar al resto del sistema. Además, las debilidades del servicio de correo electrónico así lo aconsejaron: si algo le ocurriera al servidor de correo electrónico, se minimizaría el impacto de este fallo si la máquina tuviera una dedicación exclusiva a este servicio. Inicialmente se pensó en un sistema Linux para implantar el servicio de correo electrónico, pero ante la posibilidad de utilizar una estación de trabajo SPARC que había caído en desuso, la decisión se decantó por esta vía. Se instaló el sistema operativo SunOS 4.1.3, y la primera tarea que se realizó fue la sustitución inmediata del VHQGPDLO por la última versión disponible. Se dejaron activos los servicios de telnet y ftp para que los usuarios pudieran leer su

5 correo y transferirlo sin necesidad de un cliente POP. En cualquier caso, se compiló e instaló un GDHPRQ 323[2], que actualmente es el más utilizado por los usuarios que acceden a través de los módem del sistema. Además se prevé instalar un servidor,0$3[3], ya que este protocolo permite a los usuarios el almacenamiento de todo su correo en el servidor, incluso organizado en buzones dentro de su propio PDLOER[. De esta forma el correo puede ser consultado desde cualquier máquina, sin necesidad de transferirlo totalmente, de forma similar a como funciona el servicio de QHZV. 6HUYLFLRV PXOWLPHGLD RIUHFLGRV SRU$XOD9LUWXDO0XOWLPHGLD Llegados a este punto, el disponer de un sistema de acceso remoto y un servidor de información a través del ZHE ya justifica por sí mismo la implantación del sistema como apoyo a la actividad docente, pero partiendo de la infraestructura creada, se trató de ir más allá, y ofrecer servicios propiamente PXOWLPHGLD. Con estos servicios se pretende poner a disposición del personal docente herramientas para: Transmisión de clases teóricas y prácticas en tiempo real (audio y vídeo), para aquellos alumnos que no pudieran encontrarse físicamente en el aula. Incorporación de servicios de apoyo a las clases, como el servicio de pizarra compartida, que puede ser utilizado tanto por los usuarios remotos como en los ordenadores de las aulas en las que se impartan clases prácticas. Posibilidad de almacenamiento de dichas sesiones, para consultas posteriores. Implantación de un sistema de anuncio de sesiones, así como de referencia a material almacenado. Antes de implantar estos servicios como parte del $XOD 9LUWXDO 0XOWLPHGLD, veamos qué podría llegar a ocurrir en un ejemplo real de uso. Imaginemos que queremos transmitir una clase con audio y vídeo en tiempo real. Imaginemos un emisor (con una cámara y un micrófono para el profesor) y varios receptores (los alumnos de una clase práctica, que tienen conectados sus ordenadores para recibir el audio y el vídeo). Receptor Receptor... Receptor Ethernet Vídeo Emisor )LJXUD(VTXHPDGHWUDQVPLVLyQPXOWLPHGLDHQ WLHPSRUHDO Según la )LJXUD, el emisor deberá establecer tantas conexiones como receptores deseen sumarse a la clase. Por ello, el emisor no sólo deberá recoger la información de audio y vídeo y codificarla para enviarla por la red, sino que deberá enviar esta misma información a todos y cada uno de los receptores, de forma independiente. Siguiendo el esquema de la figura, imaginemos que la transmisión de audio y vídeo con un mínimo de calidad requiere un ancho de banda de unos 500kbps. Imaginemos que existen 20 receptores, por lo que el emisor deberá establecer 20 conexiones, cada una de las cuales consumirá, suponiendo que no exista ningún otro tipo de comunicación, un ancho de banda de 500kbps. Continuando con el ejemplo de la figura vemos que todos los receptores se encuentran conectados a un mismo bus (WKHUQHW. Como ya se ha mencionado, los buses (WKHUQHW disponibles en la universidad están basados en la tecnología 10BaseT. Haciendo un simple cálculo del ancho de banda que sería necesario para soportar el envío de la información multimedia a los 20 receptores, vemos que el ancho de banda necesario es de 20x500kbps/seg=10Mbps, superior al ancho de banda efectivo que una red 10BaseT puede proporcionar. Si intentáramos ofrecer el servicio según este esquema, inevitablemente inundaríamos la red, lo cual repercutiría no sólo en nuestro sistema, sino también en el resto de comunicaciones que estuvieran establecidas en esta red. La solución más inmediata pasaría por limitar el ancho de banda de transmisión, así como el número máximo de receptores. Sin embargo, en el siguiente punto se va a proponer un método para eliminar estas restricciones. &RQVLGHUDFLRQHVWpFQLFDV Las restricciones del apartado anterior se consideraron inaceptables. Por ello, se buscaron otras soluciones, que consistieron en cambiar el planteamiento de transmisión y recepción. El esquema anterior estaba basado en un direccionamiento en

6 modo XQLFDVW. A continuación se exponen los tipos de direccionamiento en IPv4. 'LUHFFLRQDPLHQWR IPv4 permite tres tipos de direccionamiento: 8QLFDVW 8QLGLIXVLyQ: Transmisión de un paquete a una máquina específica. Puede verse como una transmisión en modo simplex, donde un nodo envía (identificando la dirección del nodo receptor) y otro recibe. Este es el modo de emisión de paquetes más usual en Internet, ya que la mayoría de los protocolos de alto nivel de redes (Transporte ISO, TCP ó UDP) únicamente ofrecen servicio de transporte unicast, que sólo permite el envío de paquetes de un nodo a otro en un instante dado. Si se desea una comunicación punto a multipunto con un servicio de transporte unicast, la solución es el PRGR UHSOLFDGR, generando y enviando una copia de cada paquete a cada uno de los nodos receptores. %URDGFDVW 'LIXVLyQ: Envío de un datagrama a todos y cada uno de los nodos de una subred. Un nodo envía y todos los nodos de la subred a la que pertenece reciben la información. Éste es el modo típicamente utilizado en LAN como (WKHUQHW. 0XOWLFDVW 0XOWLGLIXVLyQ: Evidentemente, el modo XQLFDVW UHSOLFDGR, antes citado, no es la solución más eficiente. La mejor forma de transmitir información de un emisor a varios destinos sería usar un transporte multicast para poder realizar el envío con una única operación de llamada al servicio de transporte. El modo PXOWLFDVW se encuentra entre XQLFDVW y EURDGFDVW, y permite que los paquetes PXOWLFDVW puedan ser enviados a varios nodos que han decidido ser miembros de un grupo PXOWLFDVW, aun encontrándose en varias subredes dispersas. Sencillamente, el PXOWLFDVWLQJ es la capacidad de enviar información a a varios nodos con una sola operación atómica, es decir, a todos los nodos a la vez, y no uno por uno, lo que requeriría una operación para cada nodo destinatario. El PXOWLFDVW minimiza la carga de la red, ya que requerirá sólo la transmisión de cada paquete a una sola dirección de grupo PXOWLFDVW. Cada paquete será reenviado entonces por el árbol de distribución hasta los receptores. Los datagramas son sólo enviados a las máquinas que están a la HVFXFKD, y el resto no se ven afectadas. Además, la eficiencia relativa del PXOWLFDVW, respecto XQLFDVW y EURDGFDVW, se incrementa a medida que incrementan el número de receptores y su dispersión. Por último, otro aspecto a favor del PXOWLFDVWLQJ es que redes como (WKHUQHW tienen soporte para PXOWLFDVW y EURDGFDVW a nivel físico y de acceso al medio, lo que implica que al implementar el servicio PXOWLFDVW se consigue un apreciable aprovechamiento de las prestaciones de la red local. /RVJUXSRVPXOWLFDVW El direccionamiento PXOWLFDVW se adapta de una forma muy precisa a aquello que queremos conseguir: cada grupo PXOWLFDVW tendría su equivalencia en una clase, en la que existen al menos un emisor y al menos un receptor. Del mismo modo que en un campus se pueden impartir varias clases de forma simultánea, asimismo podrían existir varios grupos PXOWLFDVW de forma simultánea. Al igual que ocurre con una clase, un cliente puede unirse o salir de un grupo PXOWLFDVW. Estas operaciones se realizan utilizando el protocolo,*03 [15][16]. Este protocolo es utilizado por los routers PXOWLFDVW (PURXWHUV), para determinar las ramas del árbol de distribución a las que deben reenviar los paquetes PXOWLFDVW. Si en una rama no hay ningún cliente unido a ningún grupo PXOWLFDVW, no tiene sentido enviar paquetes PXOWLFDVW por esa rama. Si en una rama hay clientes que están unidos a un determinado grupo PXOWLFDVW, el PURXWHU tan sólo reenviará los paquetes PXOWLFDVW correspondiente al grupo al que pertenecen los clientes de esa rama; los paquetes PXOWLFDVW de otros grupos PXOWLFDVW no serán reenviados por esa rama, ya que no existirá ningún receptor interesado en recibirlos. 0%RQH En los apartados anteriores se ha expuesto la situación ideal de una red en la que todos los URXWHUV son PURXWHUV, pero esta situación todavía no se corresponde con la realidad. Para realizar transmisiones PXOWLFDVW sobre dos redes unidas por un URXWHU XQLFDVW, la solución inmediata es convertir este URXWHU en un PURXWHU, pero esta solución no siempre es factible. Esta dificultad es extensible si quisiéramos transmitir información PXOWLFDVW entre dos redes muy distanciadas geográficamente, donde existen gran cantidad de URXWHUVXQLFDVW. Esta misma dificultad se encuentra a la hora de interconectar redes cuya tecnología está siendo investigada, por lo que todavía no ha sido implantada de forma masiva. Es el caso de IPv6. La mayoría de Los URXWHUV instalados actualmente no poseen la capacidad de enrutar este tipo de paquetes, por lo que la única opción que queda para interconectar redes IPv6 es HQFDSVXODU los paquetes IPv6 en otro tipo de

7 paquetes que las redes intermedias sean capaces de manejar, como IPv4. Esta HQFDSVXODFLyQ se hace en cada extremo que conecta las redes IPv6 a través de IPv4. A este modo de conexión se le denomina W~QHO. Por ello, la solución para interconectar redes PXOWLFDVW a través de redes XQLFDVW pasa por crear W~QHOHV entre PURXWHUV sobre redes XQLFDVW. Precisamente en esto consiste 0%RQH; 0%RQH es una red PXOWLFDVW que se encuentra integrada dentro de la propia,qwhuqhw, utilizando W~QHOHV para conectar los PURXWHUV que no tengan visibilidad PXOWLFDVW directa. Así se consigue un esquema de transmisión PXOWLFDVW extendido a lo largo de los continentes. ([WHQVLRQHV PXOWLFDVW SDUD HO VHUYLFLR$XOD9LUWXDO0XOWLPHGLD Según hemos visto, la idea de implantar un sistema basado en comunicación en PXOWLFDVW sin duda ayudará a aminorar los efectos negativos que produce el aumento de tráfico de red debido a la transmisión de información multimedia. Disminuyendo el tráfico de red: Se reducirá el impacto sobre las comunicaciones del resto de la comunidad universitaria. Asimismo se mejorará la calidad de las transmisiones multimedia dentro del contexto del servicio $XOD 9LUWXDO 0XOWLPHGLD. (QoS [17]) Así, el primer punto es situar los PURXWHUV en la topología del sistema. 5RXWLQJPXOWLFDVW En el esquema de la )LJXUD, vemos que la mayoría de usuarios potenciales del servicio $XOD 9LUWXDO 0XOWLPHGLD se podrán encontrar bien en uno de los tres buses (WKHUQHW descritos o bien detrás de un enlace PPP a través del servicio de acceso remoto. Así, hemos centrado nuestros esfuerzos en establecer un esquema de URXWLQJ PXOWLFDVW eficiente para estas redes. Parece lógico instalar en esta máquina un router PXOWLFDVW por software (PURXWHG) en la máquina conectada a las tres redes (WKHUQHW. De este modo tendremos un enrutamiento PXOWLFDVW entre las tres redes (WKHUQHW, sin necesidad del establecimiento de ningún túnel. Resuelto el URXWLQJ PXOWLFDVW en los buses (WKHUQHW, vemos que los paquetes PXOWLFDVW no atravesarán las líneas 333, ya que las peticiones,*03 realizadas desde los usuarios del servicio de acceso remoto no alcanzarán el bus (WKHUQHW, debido a que no existe ningún esquema de URXWLQJPXOWLFDVW en las máquinas que ofrecen el servicio de acceso remoto. Solventaremos este problema lanzando un PURXWHG en cada máquina que compone el servicio de acceso remoto. Sin embargo, en este punto nos encontramos con un problema: el PURXWHG tan sólo es capaz de establecer rutas PXOWLFDVW (denominados LQWHUIDFHVYLUWXDOHV en la documentación del PURXWHG) sobre interfaces de red activos en el momento de arranque del PURXWHG. Los interfaces 333 tan sólo se encuentran activos cuando la conexión se encuentra establecida. Por ello, si intentamos lanzar el PURXWHG incluyéndolo en la cadena de arranque del sistema, éste no será lanzado, ya que tan sólo encontrará un interface de red (el interface hacia el bus (WKHUQHW), con lo que determinará que no dispone de interfaces (ramas de distribución) suficientes para realizar un URXWWLQJ de paquetes PXOWLFDVW, y terminará su ejecución. La solución es lanzar el PURXWHG cuando ya exista una conexión 333 establecida. Además, PURXWHG no soporta adición automática de interfaces de red, por lo que tendremos que enviar una VHxDO de refresco al GDHPRQ cada vez que se establezca o finalice una conexión 333. Esto se podrá realizar mediante VFULSWV que serán invocados por el GDHPRQ que controla las conexiones 333: el SSSG. /RVVHUYLFLRVPXOWLPHGLD Una vez se dispone de capacidades PXOWLFDVW, se pueden comenzar a utilizar aplicaciones de envío y recepción de audio (5HDO$XGLR, 5$7, 9$7) y vídeo (5HDO9LGHR, 9,&,,9&) en modo PXOWLFDVW. Estas herramientas se encuentran disponibles desde el sistema de información del servicio. Además se puede comenzar a utilizar Debemos resaltar que las transmisiones PXOWLFDVW tan sólo tienen sentido para transmisiones en tiempo real, ya que las transmisiones en tiempo diferido se realizan en modo XQLFDVW. La razón de esto es que, para que una transmisión en tiempo diferido se pudiera transmitir en modo PXOWLFDVW, todos los receptores deberían realizar la petición de recepción de forma simultánea. (VWDGtVWLFDVGHXVRGHOVLVWHPD La )LJXUD presenta el crecimiento experimentado por el servicio $XOD 9LUWXDO 0XOWLPHGLD desde su implantación. Hay que destacar que su puesta en explotación real se realizó en el mes de Enero de Desde entonces se ha registrado un apreciable crecimiento, tanto en el número de conexiones como en el tiempo de presencia en el sistema. Se ha decidido no realizar el alta masiva de

8 usuarios en el sistema mientras éste no esté suficientemente probado sep-97 oct-97 nov-97 dec-97 jan-98 feb-98 mar-98 apr-98 may 98 jun-98 Nº Usuarios Tiempo conexión Nº Conexiones )LJXUD(VWDGtVWLFDVGHXVR 7UDEDMRVHQFXUVR La topología general del sistema ()LJXUD ) muestra la existencia de una red local $70 que está previsto instalar en breve. Esta red nos permitirá replantear la arquitectura inicial en un intento por dotar a Aula Virtual de la 4R6 (WKURXJKSXW, GHOD\, MLWWHU) [5] que requiere la información multimedia y que aportará la tecnología $70 aunque sólo sea en determinados tramos de la red interna de nuestro centro. Podremos también estudiar los flujos de información generados por el servicio de forma que se está trabajando en la propuesta y evaluación de un nuevo protocolo pensado para tráfico,3 que sea capaz de conjugar la 4R6[17] con lo que hemos dado en denominar Garantía de Servicio (UHOLDELOLW\). Este protocolo se encargará de garantizar que la información multimedia llegue por igual a todos los destinatarios de un grupo PXOWLFDVW En cuanto a las líneas de conexión remota, se esta estudiando la migración hacia RDSI, con un doble ancho de banda que el que se proporciona en condiciones óptimas en una línea RTB. La razón por la cual no se partió directamente desde este tipo de líneas es un alto coste respecto a las líneas RTB. recibidas en tiempo diferido y emitidas en XQLFDVW. Uno de los objetivos finales del proyecto es el estudio de la información generada y la propuesta de un nuevo protocolo de comunicaciones para tráfico,3. 5HIHUHQFLDV [1] A. Plaza, C. Ramos, A. Gazo, J.L. González. 6HUYLFLRÃ $XOD 9LUWXDOÃGHÃODÃ(VFXHODÃ3ROLWpFQLFDÃGHÃ&iFHUHV. IV Jornadas de informática de Las Palmas de Gran Canaria [2] 3RVWÃ2IILFHÃ3URWRFRO. RFC 1460 [3],QWHUDFWLYHÃ0DLOÃ$FFHVVÃ3URWRFRO RFC 1203 [4]Ã KWWSZHEHSFFXQH[HVÃ Páginas de información del Servicio Aula Virtual Multimedia [5]Ã J.L. González, J. Caballero, M. Sánchez. Å0%RQHÃ \Ã ODV DSRUWDFLRQHVÃGHOÃPXOWLFDVWLQJÃDÃORVÃVHUYLFLRVÃPXOWLPHGLDÃHQ,QWHUQHWÅ, Novática nº 124, Dic pp [6] Nonstandard for transmission of IP datagrams over serial lines: SLIP. RFC 1055 [7] 7KHÃ3RLQWWR3RLQWÃ3URWRFROÃ333. RFC 1661 [8] 333Ã9HQGRUÃ([WHQVLRQV. RFC 2153 [9] &RPSUHVVLQJÃ7&3,3ÃKHDGHUVÃIRUÃORZVSHHGÃVHULDOÃOLQNV. RFC 1144 [10] 333Ã%6'Ã&RPSUHVVLRQÃ3URWRFRO. RFC 1977 [11] 333Ã'HIODWHÃ3URWRFRO. RFC 1979 [12] Domain names - implementation and specification. RFC 1035 [13] &ODULILFDWLRQVÃWRÃWKHÃ'16Ã6SHFLILFDWLRQ. RFC 2181 [14] 1HJDWLYHÃ &DFKLQJÃ RIÃ '16Ã 4XHULHVÃ '16Ã 1&$&+(. RFC 2308 [15] +RVWÃH[WHQVLRQVÃIRUÃ,3Ã0XOWLFDVWLQJ. RFC 1112 [16],QWHUQHWÃ*URXSÃ0DQDJHPHQWÃ3URWRFROÃ9HUVLRQÃ. RFC 2236 [17] Steinmetz, R.,and Wolf, L.C., Quality of Service: Where are We?,,:426, pp , (1997). &RQFOXVLRQHV Hemos presentado el servicio $XOD 9LUWXDO 0XOWLPHGLD diseñado como un sistema distribuido y de bajo coste en el que se aspira a optimizar los recursos de la red y a ofertar los más avanzados servicios multimedia en un contexto universitario que podría ser perfectamente extendido al empresarial. Las extensiones multimedia del servicio han sido las que mayores problemáticas han presentado y se han resuelto con la posibilidad de usar audioconferencia, videoconferencia o pizarras compartidas en tiempo real (0%RQH) y también con el almacenamiento de sesiones grabadas para ser