Mecanismos de Difusión Masiva en Aplicaciones Distribuidas - dtic ...

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.
Servidor
Internet
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

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
Datos
Distribución de noticias
Juegos interactivos
Mensajería instantánea
Descarga de video
Descarga de música
Replicación de repositorios multimedia
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
confiables.
superior izquierda corresponde a aplicaciones no
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.

DHCP
TCP/IP
NIC
NIC
HTTP
Servidor
GAIA
NFS
MySQL
FS Proc
Transferencia
de archivos
Mem.
Virtual
I/O CPU MEM
I/O CPU MEM
Nivel de
Aplicación
Nivel de
Nivel de
Sistema
Operativo
Nivel
Hardware
RED
TCP/IP
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.
NFS
NIC
NIC
Cliente
GAIA
MySQL
FS Proc
Transferencia
de archivos
Mem.
Virtual
I/O CPU MEM
I/O CPU MEM

• 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.
Cliente
Regeneración
Cliente
Administració
Navegador
Web
Agente
Regeneración
Cliente ubicuo de
regeneración
(PDA, portátil,
Móvil, ...)
Fig. 5. Escenario de desarrollo del Sistema de Regeneración de Nodos
6 Conclusiones
Control de acceso
mediante tarjetas
inteligentes (Smart Card)
Internet
Agente
Regeneración
Servidor de
Autenticación
Directorio,
Perfiles y
Certificados
Router/ Proxy/ Firewall
Servidor
Web
Interfaz
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
HTML
Dir
Servidor de
Aplicaciones
Lógica de
Negocio
DB
Entorno de
Almacenamiento y
repositorio software
DB
DB
DB
Sistema de
Información

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)