Mecanismos de Difusión Masiva en Aplicaciones Distribuidas

Diego Marcos Jorquera, Virgilio Gilart Iglesias, Francisco José Mora Gimeno y Francisco Maciá Pérez

En la actualidad, y motivado entre otras cosas por la llegada de los servicios integrales por Internet, muchos de los presentes procesos de transmisión de información suelen estar marcados por dos características diferenciadoras: se transfieren grandes volúmenes de información y a un elevado número de destinatarios. Con la tecnología que venimos usando hasta el momento orientada a las comunicaciones uno a uno estas trasmisiones suponen un serio problema ya que saturan los canales de comunicación y se producen altos retardos en el proceso global de comunicación. En este sentido las nuevas tecnologías de comunicaciones uno a muchos o muchos a muchos aportan una solución mucho más escalable al problema de la difusión de información masiva. En el presente documento se analiza la incorporación de procesos de comunicación multicast en aplicaciones que requieren la transmisión confiable de grandes volúmenes de información de carácter genérico a través de redes de comunicación sobre las que no se tiene ningún control, proponiendo como caso de uso la incorporación de procesos de difusión en Gaia, un sistema de regeneración de nodos.

1 Introducción

La comunicación y el uso de redes de computadores, así como su rápida y amplia expansión en la sociedad actual, han revolucionado la forma en la que nos relacionamos, trabajamos o nos divertimos. La aceptación de las nuevas tecnologías es cada vez mayor y su uso se ha

incrementado de manera espectacular en los últimos años. Por ello las tecnologías e infraestructuras que hacen posible su uso han tenido que sufrir los efectos de este escalado, adaptándose en la medida de lo posible a las nuevas necesidades.

En la actualidad muchos de los procesos de transmisión de información suelen estar marcados por dos características diferenciadoras: grandes volúmenes de información y elevado número de destinatarios. Con la tecnología que venimos usando hasta el momento estas trasmisiones suponen un serio problema ya que saturan los canales de comunicación y se producen altos retardos en el proceso global de comunicación.

Fig. 1. Esquema del proceso de difusión de información masiva a múltiples destinatarios mediante redes heterogéneas

El Grupo de Redes de la Unidad Singular de Investigación Redes de Computadores e Informática Industrial del Departamento de Tecnología Informática y Computación de la Universidad de Alicante centraliza mucha de su actividad en el estudio y realización de sistemas que faciliten la gestión y mantenimiento de las redes de computadores. En este ámbito, el grupo ha desarrollado un sistema, denominado Gaia [1], dedicado a la regeneración de nodos de red y

Internet

Servidor

que se enmarca dentro del desarrollo de grandes aplicaciones distribuidas. Este sistema debe realizar transferencias de información masiva, a través de redes de comunicaciones de área amplia, heterogéneas y sobre las que no se tiene control ni de los dispositivos de networking que la conforman, ni sobre su configuración. Esta información, tiene como destinatarios en multitud de ocasiones a más de un equipo al mismo tiempo.

En concreto, el problema que se plantea es la distribución masiva de grandes volúmenes de información a través de redes de comunicación heterogéneas, sobre las que no se tiene ningún control, y dirigida a un también heterogéneo y variable conjunto de nodos destino.

Las características que describen el problema y que se ilustran en la Fig. 1 son:

• Desde el punto de vista del usuario final, la información a difundir se almacena en forma de paquetes software de información. Cada paquete supone una unidad funcional independiente y puede ser encapsulada en un único archivo.

• Los paquetes software pueden residir en más de una ubicación (o nodo de red). Cada nodo que contiene información se denomina repositorio software. Es desde estos repositorios desde los que debe difundirse la información hacia los diferentes nodos. Estos nodos receptores de información representan los clientes del servicio de difusión.

• Cada paquete contiene información de carácter genérico, en formato compactado y codificado. En general se debe asumir que son de gran tamaño, normalmente de cientos de megabytes, potencialmente pueden ser de cualquier tamaño. En una sesión de difusión pueden verse implicados un gran volumen de paquetes software de diferentes características. Puesto que la información es de carácter totalmente general, no puede hacerse uso de su estructura o contenido para mejorar las características de la difusión o de su compresión, como ocurre en otros casos; por ejemplo, en el streaming de vídeo.

• Los clientes que demandan la información representan un conjunto heterogéneo de nodos. Esta diversidad se materializa en diversos aspectos: desde su arquitectura, sistema operativo y configuración tanto software como hardware; pasando por sus diferentes velocidades de transmisión; hasta su funcionalidad. La distancia entre el emisor y cada cliente podrá ser diferente.

• Para una determinada sesión de difusión, el conjunto de receptores puede estar constituido desde por un único cliente hasta por un elevado número de nodos (siempre manteniendo su heterogeneidad).

• La información debe trasladarse a través de redes de comunicaciones globales, compuestas por dispositivos de networking heterogéneos, sobre los que no se tiene, en general, control, ni capacidad de configuración o administración. Esta circunstancia impide que se pueda proporcionar calidad de servicio (QoS), realizar reservas de ancho de banda, utilizar canales fijos, o mantener las características de una comunicación a lo largo de todo el proceso.

o La solución deberá ser independiente de la infraestructura de red sobre la que se opere. La información podrá viajar por diferentes tipos de arquitecturas y tecnologías de red.

o La topología de la red de trabajo es variable, pudiéndose dar cualquier tipo de distribución entre las diferentes subredes que la compongan.

o La velocidad de la red podrá variar en función de la carga de la misma, pudiéndose dar casos de elevado uso e incluso de saturación.

• La distribución de la información se realizará en el ámbito del uso de protocolos de red normalizados, como puede ser TCP/IP. La solución que se ofrezca deberá estar acorde a los estándares establecidos, no requiriendo la modificación de elementos como routers o pasarelas.

• La transferencia de un paquete software debe de ser confiable, de manera que se pueda determinar tanto la correcta recepción del mismo, como que dicha recepción se realiza dentro de unos límites de tiempo establecidos.

• Cuando así se requiera, deberá poder garantizarse la privacidad de la comunicación. Puesto que la información debe viajar por medios sobre los que no se tiene control, se deben aplicar técnicas de codificación que aseguren:

o Al emisor, que la información se dirige al destinatario deseado.

o Al receptor, que dicha información proviene del emisor esperado.

o A ambos, que la comunicación es privada.

2 Antecedentes

La mayoría de los procesos y tecnologías de transferencia de información entre equipos utilizando redes de computadores han estado marcados por el uso de protocolos fundamentados, principalmente, en técnicas unicast, donde el traspaso de la información se realiza entre dos únicos nodos [2].

Otros protocolos, principalmente destinados a procesos de control de la red [3][4][5], utilizan técnicas de broadcast donde la información es enviada por un único nodo origen, siendo su destino todos los nodos de la red (normalmente en el ámbito de las redes locales). Estas tecnologías aprovechan las características que algunos medios tienen para la difusión de información, de manera que la información es enviada una sola vez, pudiendo llegar en una misma transacción a todos los componentes de la red y reduciendo así el trafico de red.

Protocolos como TCP/IP [6] basan su filosofía de trabajo en estas técnicas, proporcionando a las aplicaciones una capa de servicios mediante la cual poder establecer transferencia de información entre

nodos, con un esquema orientado a conexión (TCP) o no (UDP). Mediante estos protocolos se puede satisfacer la mayoría de los requerimientos de las aplicaciones que necesitan una comunicación bidireccional entre equipos.

Sin embargo y motivado principalmente por la aparición e incremento del uso de los recursos multimedia, que comenzó a afianzarse en los años 90, surgen una serie de nuevos requerimientos en las comunicaciones que precisan de un cambio filosófico en la manera de transmitir la información [7].

Las características de estos nuevos sistemas de transferencia son, por una parte, la gran cantidad de información a transmitir y, por otra, el elevado numero de equipos a los que va destinada dicha información, en algunos casos del orden de miles o incluso millones de receptores. Mediante una transferencia unicast clásica obtendríamos resultados desfavorables ya que habría que repetir la transferencia de la información por cada uno de los destinatarios, con lo que el resultado sería un proceso global lento y sobre todo poco escalable. Se hace necesario pues introducir nuevos modelos de trabajo que permitan aprovechar mejor el uso de la red.

Multicast es una tecnología que nos permite transferir la información desde un emisor a un conjunto determinado de destinatarios. El uso de técnicas multicast para la transmisión de archivos a más de un cliente mejora sustancialmente el rendimiento ya que el equipo origen emite la información una única vez, evitando la repetición de la información a transmitir. Estas técnicas son mucho más escalables a la hora de distribuir la información ya que el envío de los datos no es dependiente del número de destinatarios [8].

Una utilización clara del uso del multicast, y precursora en cierta manera de su desarrollo, es el streaming de audio o video. En este tipo de aplicaciones un servidor emite de manera continua un flujo de paquetes conteniendo la información multimedia que los clientes deben presentar. Los clientes, según van recibiendo estos paquetes, van reproduciendo la información en tiempo real en función de su tipo y el dispositivo final en el que se está presentando. En caso de que se

pierda uno o más paquetes de la secuencia, el cliente lo refleja mediante una pausa puntual en la reproducción o un decremento de la calidad, resolución o frecuencia del contenido. Esto es posible ya que existen codificaciones de contenidos multimedia que nos permiten realizar su reproducción en condiciones de pérdida de información. En cualquier caso el cliente normalmente no necesita comunicarse con el equipo origen para informar de la pérdida de datos, es decir, se trata de una comunicación unidireccional y no confiable. Usando este tipo de comunicación el sistema es altamente escalable ya que la transmisión se realiza de manera independiente al número de destinatarios.

Sin embargo, en otros escenarios necesitamos que el sistema sea confiable, es decir, tenemos que asegurar la total recepción de la información por parte de los destinatarios. Pongamos como ejemplo un servidor de software que necesita enviar la instalación de una aplicación a cientos o miles de clientes. Al final de la transmisión tenemos que asegurar que todos los clientes han recibido la totalidad del paquete software. En estos casos la escalabilidad del sistema está más cuestionada, ya que la simple confirmación de la recepción de la información se multiplica por el número de clientes, por lo que se pude saturar la red con los paquetes de control.

La Tabla 1 muestra una distribución de los diferentes tipos de aplicaciones que nos podemos encontrar en función del tipo de datos y el tipo de transmisión.

Tabla 1. Tipos de aplicaciones multicast.

En tiempo real Sin tiempo real Multimedia Streaming de video

Streaming de audio Videoconferencia

Descarga de video Descarga de música Replicación de repositorios multimedia

Datos Distribución de noticias Juegos interactivos Mensajería instantánea

Descarga de archivos Bases de datos replicadas Distribución de software Redes de compartición de archivos

2.1 Multicast sobre IP

En el caso del protocolo IP el soporte para multicast fue implementado por primera vez en el año 1993 mediante una ampliación de dicho protocolo.

El funcionamiento del multicast sobre IP está fundamentado en la suscripción a grupos de difusión [9]. Cada grupo de difusión esta asociado a una dirección IP que lo identifica. Para ello se reservaron un conjunto de direcciones IP denominadas de ‘clase D’ destinadas a las comunicaciones en multicast. En concreto, estas direcciones son aquéllas que empiezan con el prefijo ‘1110’, es decir, las comprendidas en el rango de 224.0.0.0 a 239.255.255.255 (ver Tabla 2). De este conjunto, las comprendidas entre la dirección 224.0.0.0 y la 224.0.0.255 están reservadas para tareas administrativas y de mantenimiento multicast.

Tabla 2. Distribución de direcciones IP

Clase Prefijo Dirección inicial Dirección final A 0 0.0.0.0 127.255.255.255 B 10 128.0.0.0 191.255.255.255 C 110 192.0.0.0 223.255.255.255 D 1110 224.0.0.0 239.255.255.255

Un equipo que desea recibir paquetes difundidos por otro equipo se suscribe a una determinada dirección IP de multicast. A partir de ese momento el protocolo de red se encargará no sólo de hacer llegar a las aplicaciones del equipo los paquetes destinados a la propia dirección IP del equipo, sino que también hará llegar los paquetes destinados a las direcciones IP multicast a las que el equipo se ha suscrito. En cualquier momento el equipo podrá darse de baja de un grupo de difusión, con lo que dejaría de recibir los paquetes enviados a la dirección IP asociada.

Por otra parte el equipo que desee enviar un paquete al grupo de difusión simplemente tendrá que enviar el paquete a la dirección IP

asociada al grupo, como si la dirección se correspondiera a un nodo más de la red.

El multicast para IP está disponible tanto para el envío de paquetes IP como para paquetes UDP. Evidentemente con TCP no se puede realizar multicast ya que se trata de un protocolo confiable orientado a la conexión entre dos nodos. Con el uso de UDP obtenemos principalmente dos ventajas respecto a usar simplemente IP: conseguimos una multiplexación por aplicación mediante el uso de los puertos de comunicaciones y podemos establecer un código de detección de errores (checksum) para los datos.

Para conseguir que los paquetes emitidos desde un nodo lleguen a todos los nodos suscritos al grupo multicast, los nodos y routers que soportan multicast se comunican mediante un protocolo denominado Internet Group Management Protocol – IGMP [6]. Mediante IGMP se actualizan las tablas de enrutamiento de los routers, de manera que durante la transmisión multicast éstos pueden tener la información necesaria para difundir la información adecuadamente. Cada vez que un nodo se incorpora o abandona un grupo informa mediante este protocolo su interés o no en recibir paquetes destinados a la dirección IP asociada.

Sin embargo en la actualidad ni todos los equipos ni todos los routers soportan el multicast ya que no es obligatorio en la especificación IPv4 (en IPv6 si es obligatorio), con lo que en un principio esto impediría el uso de esta tecnología entre algunos equipos. Para solucionarlo pude utilizarse MBONE (Multicast Backbone).

Mediante MBONE [10], cuando un paquete multicast debe traspasar un router que no soporta multicast, el paquete es encapsulado en un paquete unicast (IP dentro de IP) de manera que puede transportarse sin problemas por cualquier ruta. Posteriormente, en el router destino, el paquete será recompuesto para obtener el paquete original. Los dos extremos que convierten de multicast a unicast y de nuevo a multicast definen lo que se denomina un túnel multicast.

Los túneles enlazan lo que se podría denominar islas multicast, por lo que, en conjunto, MBONE establece una red virtual de comunicación multicast.

2.2 Confiabilidad

En comunicaciones, la confiabilidad hace referencia a las transferencias en las que la información debe llegar de manera completa al destinatario para ser útil [11]. Cuando por cualquier motivo la información no ha sido entregada completamente, debe informarse del fallo a los componentes de la comunicación (normalmente al emisor). Si en el proceso de comunicación no se puede garantizar la entrega de la información, se considera que es una transmisión no confiable. Si nos fijamos en la Tabla 1 solamente la cuadrícula superior izquierda corresponde a aplicaciones no confiables.

En una transmisión confiable clásica, para asegurar la recepción de la información, una de las técnicas más utilizadas es el uso de los paquetes de confirmación (ACK’s). En este esquema el emisor es el responsable de realizar la corrección de errores.

Mediante el uso de los ACK’s no sólo conseguimos una transmisión confiable, también conseguimos una sincronización entre el emisor y el receptor, dado que el emisor no envía un nuevo paquete hasta que no ha confirmado la recepción del anterior.

El uso de estas técnicas basadas en los paquetes de confirmación para conseguir una comunicación confiable trasladada al caso del multicast conlleva un gran problema: la falta de escalabilidad. Supongamos que un emisor envía un paquete a un conjunto de N receptores. Cuando el paquete es recibido por los receptores se generan N ACK’s informando al emisor de su correcta recepción. Esto, para un número de receptores elevado, provocaría que tanto la red como el emisor se saturasen con los paquetes de control. Es más, posiblemente, el alto número de paquetes haría que muchos de ellos se perdieran o fueran descartados por el emisor debido a dicha saturación, con lo que se

generarían más reenvíos de paquetes, empeorando aún más, si cabe, la situación.

Es necesario, pues, aplicar otro tipo de técnicas que aporten soluciones más escalables a la hora de transmitir información de forma confiable mediante multicast.

2.3 Protocolo de transporte multicast

A la hora de resolver un problema mediante el uso de técnicas multicast confiable, los diseñadores optan por realizar una de las dos siguientes estrategias: crear una capa de transporte genérica que resuelva de manera general el problema de la comunicación multicast o crear un protocolo que resuelva las necesidades particulares que requiere cada aplicación [12].

Con la primera opción se pretende conseguir un protocolo lo suficientemente abierto como para poder ser utilizado por cualquier aplicación que requiera una comunicación multicast y confiable, de igual manera que TCP proporciona análogas características en unicast. Si TCP nos ofrece una capa de transporte que realiza una corrección de errores y una ordenación de los paquetes enviados, las características que debería aportar un protocolo genérico de multicast confiable serían:

• Sincronización en la comunicación: control del ratio de envío en función de la velocidad de lectura de los receptores y la saturación de la red.

• Escalabilidad: independencia respecto del número de receptores.

• Corrección de errores: control de paquetes perdidos en la comunicación.

• Ordenación de paquetes: mantenimiento en el destino del orden secuencial de los paquetes.

• Independencia de la red: transparencia ante las diferentes topologías y arquitecturas de red.

Fig 2. Esquema de capas de un protocolo de transporte multicast y conjunto de carácterísticas

Con la segunda estrategia conseguimos un protocolo que, si bien no pude ser usado por cualquier aplicación, sí nos aporta una solución optimizada para cada problema. Se puede dar el caso de aplicaciones que, por ejemplo, no requieran una ordenación de paquetes, o que necesiten funcionar solamente para una determinada topología. En estos casos un protocolo específico podría dar mejores resultados que con una estrategia de carácter general. En otros casos se hace necesaria la utilización de protocolos específicos, ya que se dan condiciones determinantes para su uso, como podría ser el caso de comunicaciones donde no existe un canal de retorno.

2.4 Escalabilidad

Como hemos visto, la principal causa de la falta de escalabilidad en la transmisión multicast confiable es el problema con la información de vuelta, es decir, de los paquetes de control que envían los receptores al emisor. Por muy poca que sea esta información, si el número de receptores llega a ser muy alto, el emisor terminaría por saturarse, con lo que no se podría garantizar la escalabilidad de la comunicación [13].

Para evitar esta saturación en el canal de retorno, una de las técnicas que suelen aplicarse es cambiar las confirmaciones por paquetes de información de pérdidas (NACK’s) [11].

En casos de pocas pérdidas en la comunicación, esta técnica reduce drásticamente la información de control en la comunicación e incluso, en casos óptimos, podría evitarse totalmente.

Sin embargo la falta de confirmación por parte de los receptores produce una serie de inconvenientes. En el caso de que por ejemplo en todo el proceso de transmisión no se produzca la recepción por parte del emisor de ningún paquete NACK, no significa que todos los paquetes de datos hayan sido recibidos por todos los receptores; puede existir algún problema en el canal de vuelta que evite la recepción de dichos paquetes. Por lo tanto, con el simple uso de los paquetes NACK no se puede garantizar la confiabilidad de la comunicación. Una posible solución a este problema sería el envío de un único paquete de confirmación al final de toda la transmisión, de manera que el servidor tuviera la seguridad de la correcta recepción de la información. Esto implicaría una pérdida de escalabilidad por la dependencia que volveríamos a tener del número de receptores, si bien este envío sería único y localizado siempre al final de la transmisión.

2.5 Control de flujo

Otro de los problemas que se plantea con el cambio de ACK’s por NACK’s es la pérdida de la sincronización en la comunicación. Si bien mediante el uso de las confirmaciones el emisor y el receptor se encuentran siempre acompasados en el flujo de la transmisión ya que el emisor no envía el siguiente paquete hasta no tener confirmado el anterior, con el uso de NACK’s esto no puede realizarse. Mientras el emisor difunde los paquetes de datos no tiene información sobre el estado ni la cantidad de paquetes recibidos por cada receptor. El principal problema que se deriva de esta situación es una falta en el control de flujo o ratio de transmisión, es decir, el emisor podría estar

difundiendo los paquetes a una velocidad superior a la que algunos receptores podrían estar leyendo, o por el contrario, el canal podría estar desaprovechado al usar un ratio muy bajo. Este inconveniente también ocurriría si alguno de los routers intermedios sufriera un problema parecido y descartara algunos de los paquetes de datos por falta de capacidad. Las consecuencias de estas pérdidas (ya sea en el destino como en los routers intermedios) son nefastas: algunos destinatarios detectarían de manera sistemática huecos en la secuencia de recepción y saturarían al servidor con paquetes NACK. Este ciclo de continuas pérdidas y solicitudes de reenvío producirían una clara inestabilidad en la comunicación [14].

Utilizando ratios de envío muy bajos o al menos tan bajos como el ratio de recepción del destinatario más lento tampoco solucionaría el problema. Tengamos en cuenta que la red por la que viajan los paquetes es un medio variable con periodos de mucho uso o saturación y donde normalmente no se puede garantizar un determinado ancho de banda. Por lo tanto es necesario plantear técnicas que se adapten a las necesidades puntuales de la red, en las que el emisor ajuste automáticamente el ratio de envío según las circunstancias y las características de los destinatarios.

2.6 Seguridad

La seguridad en la comunicación es un aspecto que se complica aun más con el uso de las técnicas multicast. En una comunicación unicast donde los paquetes tienen un origen y un único destino, para que un tercer elemento pueda tener acceso a la información, se requiere el uso de técnicas de espionaje como pueden ser la suplantación de identidad (suplantación IP) o la escucha promiscua del medio físico (sniffer). Sin embargo, con multicast, esto mismo se puede realizar de manera mucho más sencilla ya que bastaría con incorporarse al grupo de difusión para tener acceso a los paquetes enviados por el emisor. Se trata pues de una transmisión pública donde el emisor no establece los receptores de sus paquetes, al estilo de cómo ocurre, por ejemplo,

en la transmisión de las señales de televisión. Al igual que en este último caso, si queremos tener canales privados o de pago (transmisión de información segura), necesitamos aplicar algoritmos de codificación de la señal transmitida (procesos de cifrado de los datos) [8].

Para el establecimiento de unos niveles de seguridad adecuados en la transmisión multicast se debe contemplar principalmente los siguientes aspectos:

• Cifrado: la información emitida debe de protegerse con mecanismos de cifrado que eviten su tratamiento por destinatarios no permitidos.

• Autenticidad: evitar que elementos externos o no permitidos de la comunicación puedan sustituir parte de la información emitida sin que los miembros de la transmisión lo detecten.

• Autenticación: los miembros de la comunicación tienen que ser debidamente identificados para evitar su suplantación

2.7 Tipos de distribuciones

Uno de los aspectos que más condicionan el modelo de comunicación tiene que ver con el rol con el que actúa cada uno de sus miembros. Algunas de las configuraciones que se pueden dar son:

• Un emisor y varios receptores. En estos casos el papel de emisor y de receptor está totalmente definido. Hay un único origen de datos que se centraliza en el emisor y los receptores simplemente tienen capacidad de enviar paquetes de control.

• Varios emisores y varios receptores. En este modelo son varios los elementos capaces de emitir información. Normalmente existe un emisor principal que manda inicialmente la información y un conjunto de nodos con capacidad de reemitirla para, por ejemplo, realizar labores de corrección de errores.

• Todos emiten y reciben. Se trata de redes de cooperación donde todos los miembros son capaces de actuar como emisor y receptor.

La función de corrección de errores está distribuida al conjunto total de los miembros [11].

2.8 Conocimiento de los destinatarios

Según la información que tiene el emisor sobre los receptores a los que van destinados los paquetes de datos, podríamos clasificar las comunicaciones multicast en tres grupos diferentes [12]:

• Grupo de destinatarios indeterminado. En este primer modelo el emisor no conocería ni el número ni la identidad de los destinatarios a los que va dirigida la información que está emitiendo. Un ejemplo claro de este tipo de comunicación sería la transmisión de audio o vídeo por internet, donde el emisor difundiría los paquetes de información sin tener en cuenta los destinatarios de los mismos. A su vez, los receptores, podrían incorporarse y abandonar el grupo de difusión sin tener que informar ni realizar ningún tipo de proceso de conexión con el emisor. Suele tratarse de comunicaciones donde no se requiere un canal de retorno, situaciones éstas comunes en caso de infraestructuras altamente asimétricas, como por ejemplo, la transmisión vía satélite, donde el canal de bajada tiene un ancho de banda muy superior al de subida y una latencia muy alta [15].

• Grupo de destinatarios abierto. En este tipo de comunicación el emisor dispone de información sobre los receptores a los que está dando cobertura, si bien este grupo no está determinado antes del inicio de la comunicación. Según se va desarrollando el proceso de comunicación, el emisor va actualizando la lista de receptores, bien al recibir un primer paquete de un receptor (por ejemplo un NACK), bien mediante el uso de procesos de control, como los de conexión y desconexión, que utilizarían los receptores para informar al emisor. En este último caso se pueden realizar también operaciones de validación para permitir el acceso o no al grupo. Para evitar que equipos no validados tengan acceso a la información, en el proceso de conexión el emisor podría aportar elementos como claves de

cifrado o filtros de datos, sin los cuales no sería posible procesar los datos emitidos por el servidor.

• Grupo de destinatarios cerrado. Por último, en este modelo, el emisor conoce a priori los receptores de los datos, y solamente permitiría la comunicación con estos receptores, ignorando cualquier paquete enviado por otros equipos. Durante todo el proceso de comunicación el conjunto de receptores no varía, de manera que el emisor puede utilizar esta información para prefijar algunos parámetros del proceso de transferencia en función de la cantidad o características de los destinatarios: ratio de envío, tamaño de los paquetes, etc.

2.9 Corrección preventiva

Como hemos visto, el principal problema que se plantea en la comunicación multicast es la falta de escalabilidad: cuanto mayor es el número de receptores más alto es el volumen de paquetes de control. Para conseguir que el modelo de transmisión sea escalable, la solución más evidente que se puede plantear es la reducción, idealmente la eliminación total, de los paquetes de control. Para ello se utilizan técnicas de corrección preventiva (Forward Error Correction o FEC).

La idea principal de estas técnicas es la siguiente. Supongamos que el total de la información a trasmitir se fragmenta en n paquetes de datos. En función de esos paquetes se generan r paquetes de recuperación, conteniendo información redundante de los paquetes de datos originales. El emisor manda tanto los paquetes de datos como los paquetes redundantes. Si un destinatario no recibe uno de los paquetes de datos enviados, podrá regenerarlo a partir de uno o más paquetes de recuperación, sin tener así que solicitar el reenvío del paquete perdido.

Idealmente la codificación de los paquetes de recuperación se realizaría de manera que, para regenerar un conjunto de paquetes perdidos, se necesiten la misma cantidad de paquetes correctores. Una de las codificaciones más utilizadas y que cumple esta última

característica es la de Reed-Solomon [11]. Si embargo estas codificaciones conllevan un alta complejidad temporal para su cálculo (aumenta exponencialmente con el número de paquetes), con lo que se penaliza su uso en la mayoría de los casos. Para evitarlo, la información se agrupa en bloques de paquetes de datos sobre los que se computan localmente los paquetes de recuperación. Por lo tanto los paquetes generados solamente sirven para recuperar pérdidas dentro del bloque de paquetes de datos que se utilizó para su generación. El tamaño de los bloques se decide en función de los límites que se quieran establecer, dependiendo de la capacidad de cómputo que se disponga.

En la actualidad también se están aplicando FEC’s basados en la primitiva XOR, donde los tiempos de computo de los paquetes de recuperación son bajos y de coste lineal. Por contra, con estas técnicas se requieren más paquetes de recuperación para regenerar un paquete de datos, con lo que se incrementa el volumen de información trasmitida.

Incorporando FEC a la comunicación se logra una disminución, tanto en la cantidad de retransmisión de paquetes, como en la cantidad de paquetes de control, con lo que se suele justificar el ancho de banda extra que se utiliza en la emisión de los paquetes de recuperación y, en el caso de las trasmisiones multicast, se consigue una mayor escalabilidad.

Otra de las ventajas que aporta estas técnicas es la reducción de reenvíos en el caso de pérdidas simultáneas en diversos destinos. Si por ejemplo un receptor pierde un paquete de datos p1 y otro equipo pierde un segundo paquete p2 el emisor solamente tendría que retransmitir un único paquete r1 con el que ambos destinatarios podrían recuperarse de su pérdida. En el caso de un esquema basado en XOR tendríamos que el paquete de recuperación sería r1 = p1 XOR p2, con lo que el primer receptor calcularía p1 con r1 XOR p2 y el segundo realizaría r1 XOR p1 para calcular p2.

Además del tiempo de computo necesario, el uso de FEC’s también conlleva normalmente la utilización de un buffer de trabajo sobre el que se van componiendo los paquetes redundantes.

2.10 Uso de representantes

Otra de las técnicas utilizadas para la disminución del tráfico de control y conseguir de esta manera una mayor escalabilidad es el uso de nodos representantes [16]. Un representante es un componente de la comunicación, normalmente uno de los destinatarios, que se encarga de centralizar la información de vuelta de un conjunto de receptores, agrupándola en un bloque de información compacto, normalmente un único paquete, y reduciendo así la cantidad de paquetes que recibiría el emisor.

Estas técnicas se aprovechan de la jerarquía establecida por la topología de red, de manera que la información de vuelta se va agrupando según se acerca al emisor; facilitando, de esta forma, la escalabilidad.

En algunos casos interesa que el nodo representativo pueda realizar también labores de corrección de errores, con lo que se reduciría aun más el envío de paquetes de control hacía el emisor, pudiendo incluso llegar a evitarse. En estos casos el nodo designado almacena la información recibida para poder actuar como un emisor secundario.

Si bien el nodo representante suele ser uno de los destinatarios de la información, en algunos casos se puden utilizar nodos habilitados explícitamente para esta función o bien se delega a los routers, ya que estos se sitúan en los puntos de confluencia de los paquetes de control.

2.11 Trabajos relacionados

En la actualidad existen multitud de protocolos multicast que resuelven de manera general o más o menos condicionada el problema de la difusión de información a multiples destinatarios.

Algunos de estos protocolos son: SRM [11] un protocolo orientado a la distribución compartida de información dentro de un grupo de participantes con la corrección de errores también distribuida; MTFP [12] es un protocolo de transporte multicast que centra su objetivo en conseguir una comunicación altamente escalable y con un soporte universal para todo tipo de redes, incluyendo las altamente asimétricas; Digital Fountain [17] un protocolo totalmente escalable para la distribución de información masiva a múltiples destinatarios fundamentado en un FEC orientado a XOR denominado Tornado Codes.

3 Streaming de Archivos

Como se ha descrito el problema de la difusión de información masiva a diferentes destinatarios es bastante complejo, y al respecto ya existen diferentes soluciones en menor o mayor medida.

Sin embargo en otro tipo de escenarios nos encontramos con una serie de restricciones que complican aun más si cabe el problema anteriormente descrito. Se trata de los casos en los que los destinatarios no disponen de memoria intermedia para almacenar toda la información, antes de pasar a la fase de reconstrucción del paquete de información software, por lo que ésta deberá ir reconstruyéndose a medida que se recibe. En caso de necesitar almacenamiento temporal el proceso de recepción tendrá que poder adaptarse a cantidades de memoria pequeñas (para el caso de equipos con pocas prestaciones).

Este proceso sería similar al streaming de audio o video pero en este caso considerando que la información es de carácter general y que requerimos una confiabilidad total en la comunicación.

En estos tipos de transmisiones los procesos de sincronización emisor-receptores, la reordenación de paquetes y la recuperación de paquetes perdidos se ven muy condicionadas ya que los protocolos de transporte multicast se valen precisamente de memoria intermedia para realizar u optimizar estas labores.

4 Propuesta de solución

Se propone un modelo de transmisión para la difusión masiva de información a través de redes heterogéneas, que contemple los requerimientos establecidos en el planteamiento del problema. A partir de este modelo se ha diseñado una arquitectura que plasma funcionalmente dicho modelo. Finalmente, y para validar la corrección del modelo y arquitectura propuestos, se ha implementado un protocolo de transporte de red basado en la tecnología IP multicast.

El protocolo permite distribuir una serie de paquetes software de información desde un repositorio a un conjunto de receptores, incrementando el aprovechamiento de la infraestructura de red. El protocolo es lo suficientemente genérico como para poder ser usado por diversas aplicaciones, aportando una capa de servicios para la difusión confiable de información. Como protocolo base, sobre el que residiría la capa de transporte a implementar, se utilizará IP con soporte para multicast, debido a su alta aceptación en la actualidad.

Dado que en los destinatarios no podemos contar con memoria intermedia éstos irán procesando la información según la van recibiendo, con lo que la capa de transporte multicast proporciona a los receptores un flujo de información ordenado y acompasado con el emisor.

En la Fig. 3 se muestra un esquema de los diferentes módulos que componen el emisor y el receptor del modelo multicast propuesto.

El emisor tras realizar una serialización de la información que desea transmitir, realiza un proceso de cifrado para proteger los datos. Posteriormente la información cifrada es fraccionada en paquetes de

datos. Estos paquetes son almacenados en un buffer (B1) para que queden disponibles en el momento en que sea necesaria su retransmisión.

Fig 3. Diagrama de bloques del proceso de difusión de información

A los paquetes de datos se les aplica un FEC para reducir los problemas de escalabilidad, reduciendo la solicitud de paquetes perdidos. Dada la heterogeneidad de los destinatarios se propone el uso de FEC’s con bajo coste computacional, como los basados en XOR,

para evitar grandes retardos en la recepción en clientes lentos o saturados.

En la retransmisión de los paquetes solicitados por los destinatarios, también se incorpora el uso de FEC’s que reduzcan la cantidad de información retransmitida. Los buffers de trabajo de los FEC (B2 y B4), especialmente el del destinatario, serán de tamaño limitado, debido a las condiciones impuestas en el problema.

El receptor irá obteniendo un conjunto de paquetes de datos desordenados, bien sea por recepción directa del emisor, por una retransmisión o por una recuperación realizada por el FEC. Para suministrar una secuencia ordenada de los datos a las capas superiores el receptor usará un buffer de paquetes (B3), que también tendrá una capacidad limitada y reducida. Por ello el proceso de solicitud y entrega de paquetes perdidos deberá ser lo más eficiente posible, de manera que la recepción en cada destinatario esté lo más acompasada posible con el emisor.

5 Un caso práctico

El entorno de pruebas en el que se va ha poner en marcha inicialmente el sistema de transferencia masiva que se propone es Gaia, un sistema de regeneración de equipos que permite restaurar completamente la información contenida en los equipos que componen una red. El objetivo principal de Gaia es automatizar muchas de las tareas de mantenimiento de las redes de computadores, para conseguir una gestión desatendida de dicha red.

El proceso de regeneración se gestiona mediante un sistema que opera en el equipo de manera independiente al hardware y software instalado, y que de manera automatizada y desatendida realiza básicamente los siguientes procesos:

• Analizar el hardware del equipo, examinando principalmente los diferentes discos y particiones con los que cuenta

• Obtener la configuración establecida para ese equipo, la cual reside en un sistema de inventario que gestiona el administrador. En él se indica las particiones que debe tener el equipo tras la reinstalación, los sistemas de archivos que debe contener, así como los sistemas operativos, aplicaciones y otros datos que deben residir en estos sistemas de archivos.

• Preparar el equipo física y lógicamente para recibir loa información a instalar.

• Obtener y almacenar los datos que deben residir en el equipo desde un repositorio previamente configurado por el administrador. La información se ofrece en forma de paquetes software de instalación, como podrían ser de sistemas operativos, de aplicaciones, de datos, etc. La información almacenada en los paquetes esta comprimida para optimizar el espacio de almacenamiento y agilizar su transmisión por la red.

Por lo tanto con este sistema para mantener una red de computadores simplemente hay que indicar la secuencia ordenada de paquetes que hay que instalar por cada equipo, agilizando de esta manera las costosas tareas de instalación y configuración del software.

En algunos casos, cuando la información que hay que instalar en un equipo no pueda fraccionarse en diversos paquetes, existirá un único paquete que describe la totalidad del contenido del equipo, es decir el paquete es una copia exacta del contenido físico de las unidades de dicho equipo. Este modo de trabajo se utiliza cuando el sistema de reinstalación no entiende la estructura interna del sistema de archivos del equipo.

Mediante el uso de un sistema de transferencia tradicional de información, cuando un paquete va dirigido a más de un equipo, la transmisión se realiza de manera individual entre el repositorio y los equipos, repitiéndose esta operación tantas veces como destinatarios diferentes tenga el paquete.

Fig 4. Arquitectura del sistema de regeneración GAIA

Por norma general, el mantenimiento de los equipos se puede agrupar en grupos que comparten una misma configuración. Estos grupos estarían formados por equipos de características similares que comparten un mismo perfil software, como suele ocurrir en aulas o laboratorios informáticos. Mediante el uso de un sistema de transferencia tradicional de información, cuando un paquete va dirigido a más de un equipo, la transmisión se realiza de manera individual entre el repositorio y los equipos, repitiéndose esta operación tantas veces como destinatarios diferentes tenga el paquete. Esto produce una disminución en el rendimiento global del proceso, ya que se satura tanto el repositorio con solicitudes repetidas de paquetes, como la red con la transferencia de dichos paquetes.

Por todo esto, se propone sustituir el sistema de transferencia de archivos actual (ver Fig.4 y Fig. 5) por el sistema de transmisión propuesto, de forma que la distribución de los paquetes software se realice de manera mucho más eficiente. Con ello se pretende conseguir mejorar la transferencia en los siguientes aspectos:

• Conseguir una independencia del número de clientes que se regeneren simultáneamente con la mismo paquete software.

Nivel de Aplicación

Nivel de Sistema

Operativo

Nivel Hardware

Nivel de

TCP/IP

NIC

Servidor GAIA

DHCP

I/O CPU MEM

FS Proc Mem. Virtual

I/O CPU MEMNIC

Transferenciade archivos MySQL NFS HTTP

TCP/IP

NIC

ClienteGAIA

I/O CPU MEM

FS Proc Mem. Virtual

I/O CPU MEM NIC

Transferencia de archivos MySQLNFS

RED

• Mejorar la transmisión incluso cuando los clientes se encuentran a largas distancias, asegurando su finalización en tiempos acotados.

• Favorecer la transmisión de información masiva al reducir el trafico de control, de manera que incluso sea factible el uso de comunicaciones asimétricas como podría ser una conexión ADSL o una transmisión vía satélite.

Fig. 5. Escenario de desarrollo del Sistema de Regeneración de Nodos

6 Conclusiones

El problema de la difusión masiva de información genérica es en la actualidad un problema abierto y objeto de numerosas investigaciones. La escalabilidad es el principal factor a tener en cuenta en el desarrollo de un protocolo de transferencia multicast confiable.

No existe un protocolo general de transporte multicast que de solución a todos los problemas de difusión, principalmente en el caso del streaming de archivos. En este documento se aporta una solución al problema, estableciendo un marco formal sobre el que ir desarrollando un modelo y una arquitectura para la difusión de información masiva.

Como proyectos futuros estamos trabajando en la incorporación de mecanismos de corrección de errores de forma local mediante una

Router/ Proxy/ Firewall

Internet

Cliente Regeneración

Agente Regeneración

Cliente ubicuo de regeneración

(PDA, portátil, Móvil, ...)

Servidor de Autenticación

Dir Directorio, Perfiles y

Certificados

Entorno de Almacenamiento y repositorio software

DB

DB DB

DB

Sistema de Información

Servidor de Aplicaciones

Lógica de Negocio

Servidor Web HTML

Interfaz

Control de acceso mediante tarjetas inteligentes (Smart Card)

Navegador Web

Agente Regeneración

Cliente Administració

estructuración jerárquica de los componentes de la comunicación en forma de grafos, especialmente en forma de árboles. En este sentido se está trabajando en heurísticas de vecindad entre los diferentes destinatarios que nos permitan optimizar los canales de vuelta en los procesos de corrección de errores.

También se están realizando estudios que permitan incorporar mecanismos de seguridad en la difusión de la información a transmitir.

7 Referencias

1. Marcos Jorquera, D.; Maciá Pérez, F.; Monllor Pérez, J.C: Sistema de regeneración de nodos de red. GAIA. Desarrollo De Grandes Aplicaciones Distribuidas Sobre Internet. Servicio de Publicaciones de la Universidad de Alicante, Cap. 10, pp. 275-298. (2004)

2. Tanenbaum, A. S.:. Redes de computadoras. Tercera edición. Prentice Hall. (1997)

3. Forouzan, B. A.: Transmisión de datos y redes de comunicaciones. Segunda edición. McGraw-Hill. (2002)

4. Halsall, F.: Comunicación de datos, redes de computadores y sistemas abiertos. Cuarta edición. Addison Wesley Longman. (1998)

5. García Tomas, J.: Sistemas y redes teleinformáticas. Sociedad para Estudios Pedagógicos Argentinos (SEPA). (1989)

6. Comer D. E.: Redes globales de información con internet y TCP/IP. Principios básicos, protocolos y arquitectura. Tercera Edición. Prentice-Hall Hispanoamericana. (1996)

7. Mack, s.: Streaming Media Bible. Hungry Minds. (2002)

8. Stallings, W.: Comunicaciones y redes de computadores. Sexta edición. Prentice Hall. (2000)

9. Deering. S. E.: Host Extensions for IP Multicasting. Request for Comments (RFC) 988. (1986)

10. Handley, M.:. An Examination of Mbone Performance. Technical Report RR-97-450, USC/ISI. (1997)

11. Floyd, S., Jacobson, V., Liu, C., McCanne , S. y Zhang, L.: A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. IEEE/ACM Transactions on Networking. (1996)

12. Miller, K., Robertson, K., Tweedly, A. y White M.: StarBusrt Multicast File Transfer Protocol (MFTP) Specification”. Internet Draft. (1997)

13. Bolot, J., Turletti, T. y Wakeman., I.: Scalable Feedback Control for Multicast video Distribution in the Internet. ACM SIGCOMM Computer Communication Review. Vol 24, pp. 58-67. (1994)

14. Mankin, A., Romanow, A., Bradner, S. y Paxson., V.: IETF Criteria For Evaluating Reliable Multicast Transport and Application Protocols. Request for Comments 2357 (RFC 2357). (1998)

15. Tunpan, A. y Corson, M. S.: Bulk Data Multicast Rate Scheduling For Hybrid Het-erogeneous Satellite-Terrestrial Networks. Proceedings of the Fifth IEEE Symposium on Computers and Communications (ISCC 2000). pp. 238. (2000)

16. DeLucia, D. y Obraczka, K.: Multicast Feedback Suppression Using Representatives. Proceedings of the IEEE INFOCOM 1997. pp. 463-470. (1997)

17. Byers, J. W. y Luby M.: A Digital Fountain Approach to Reliable Distribution of Bulk Data. Proceedings of ACM SIGCOMM’98. pp. 56–67. (1998)