PROPUESTA DE ARQUITECTURA COOPERATIVA DE SERVICIO

PROPUESTA DE ARQUITECTURA COOPERATIVA DESTINADA
A LA DISTRIBUCION DE UN SERVICIO DE
TRANSMISIÓN DE RADIO POR INTERNET.
GABRIEL TOLOSA, FERNANDO BORDIGNON , CARLOS RODRIGUEZ
Universidad Nacional de Luján
Luján, Argentina
E-mail: {tolosoft, bordi, crodriguez}@unlu.edu.ar
Resumen
Nuestro trabajo define una propuesta de arquitectura de red a nivel aplicación que sirva de base a
un servicio de retransmisión de un flujo de radio por Internet. Se implementa una red de
propagación de mensajes y respuestas, conformada por todos aquellos usuarios que son afines a
escuchar flujos de audio.
En el presente documento se desarrollan los lineamentos básicos del servicio en cuestión como una
extensión al protocolo gnutella. Se especifica la arquitectura del sistema, definiendo
principalmente la forma de operación de la red de distribución de flujos de audio. Nuestro caso se
focaliza en la problemática de anunciar y solicitar el servicio a través de un modelo compañero a
compañero, dejando la retransmisión multimedial en aplicaciones libres como Shoutcast.
Palabras claves: Redes compañero a compañero, transmisión de radio
Introducción
El desafío actual es construir infraestructuras de comunicaciones y herramientas de aplicación
capaces de soportar el transporte de información multimedia a través de redes de área amplia, en
especial, a través de Internet. Los inconvenientes a solucionar están directamente ligados a la
naturaleza de la información multimedial, y a las necesidades de entrega en tiempo real y a cierta
frecuencia constante. Estas condiciones requieren de mayor ancho de banda disponible y de
mecanismos que permitan manejar los tiempos de retardo y la congestión en las redes. En la
actualidad, las redes de datos son compartidas por gran cantidad de usuarios, los cuales tienen
ancho de banda limitado, sensible retardo y disponibilidad impredecible (la red opera haciendo su
mejor esfuerzo, sin brindar calidad de servicio).
La cantidad de servicios ofrecidos a través de Internet crece constantemente. Además, teniendo en
cuenta su expansión, resulta especialmente atractiva la idea de utilizarla como transporte de
información multimedia. Debido a que Internet es una red de conmutación de paquetes, altamente
heterogénea, no es naturalmente adecuada para el tráfico en tiempo real. Los problemas principales
que se encuentran son:
a) Necesidad de ancho de banda: la información multimedia es extremadamente “pesada” (en
comparación con información textual), por lo que se requiere mayor disponibilidad de
canales con gran ancho de banda.
b) Distribución: La entrega de información multimedia debiera realizarce mediante técnicas de
multicast para llegar solamente a los receptores, sin duplicar los mensajes, reduciendo así el
tráfico sobre la red.
c) Disponibilidad de recursos: la red debiera tener disponibilidad de recursos para asegurar
ancho de banda y tiempos de retardo “aceptables” para aplicaciones multimedia. Internet es
una red de datagramas que hace su “mejor esfuerzo” para la entrega, donde los paquetes son
ruteados independientemente por diferentes caminos y pueden sufrir distintos
inconvenientes en cada uno. Dada esta característica, no se puede asegurar que los datos
alcanzarán el destino.
Los protocolos para el transporte de multimedia sobre Internet deben contemplar estas
características y asegurar que un video o un flujo de audio sea reproducido constantemente, con la
frecuencia y sincronización adecuado.
Protocolos de transporte de flujo multimedial
Las soluciones propuestas para transportar multimedia sobre Internet están relacionadas con la
clasificación del tráfico, de manera que se puedan determinar prioridades. Se desarrollaron
protocolos con este fin, tales como RTP, RTCP, RSVP y RTSP.
RTP – Realtime Transport Protocol
RTP es un protocolo basado en IP que provee soporte para el transporte de datos en tiempo real
como flujos de audio y video. Entre los servicios que provee se encuentran reconstrucción de
tiempos, detección de pérdidas, seguridad e identificación de contenido.
Está diseñado para trabajar en conjunto con el protocolo auxiliar RTCP para obtener información
sobre calidad de la transmisión y participantes de la sesión.
RTP provee transporte entre sistemas finales para datos en tiempo real sobre una red de datagramas.
Generalmente opera sobre UDP por varios motivos. Aprovecha las funciones de control de error y
de multiplexación, y además – por ser un protocolo de transporte no orientado a la conexión – no
ofrece confiabilidad, por lo que no generará retransmisiones que puedan congestionar la red (para
datos en tiempo real, la confiabilidad no es tan importante como la entrega rápida).
Las características principales de RTP son: a) Timestamping, el emisor setea el timestamp de
acuerdo al instante en que el primer octeto del paquete fue muestreado. El timestamp aumenta
mientras se completa un paquete. Por otro lado, el receptor usa estas marcas para reconstruir el
timing original para reproducir la secuencia a la frecuencia correcta. b) Secuenciación: Debido a la
necesidad de entregar los paquetes en orden (UDP no provee esta característica) RTP incorpora un
número de secuencia que – además – sirve para la detección de paquetes perdidos. c) Source
identification: permite conocer al receptor de la información de dónde provienen los datos. y d)
Payload type identificator: especifica el formato de datos de la carga de RTP (definidos en el RFC
1890, por ejemplo MPEG1, JPEG, PCM), referente al formato de codificación, de manera que la
aplicación receptora pueda saber como reproducirlo.
En la practica RTP se implementa en la aplicación. Para establecer una sesión RTP, la aplicación
define una dirección de red y un par de puertos para RTP y RTCP. En una sesión multimedia, cada
medio es transportado por sesiones RTP separadas, con paquetes de RTCP propios de reporte de
calidad de recepción.
RTCP – Real Time Control Protocol
RTCP está diseñado para trabajar en conjunto con RTP (RFC 1889/1890). En una sesión RTP, los
participantes periódicamente envían paquetes RTCP para proveer información sobre la calidad de la
entrega de datos. El RFC define 5 tipos de mensajes de control:
RR (receive report): Es enviado por los receptores y contiene información sobre la calidad
de la entrega de datos, incluyendo último número de paquete recibido, número de paquetes
perdidos y timestamps para calcular el retardo entre el emisor y el receptor.
SR (sender report): es enviado por el emisor y además de contener información similar a los
mensajes RR, incorpora datos sobre sincronización, paquietes acumulados y número de
bytes enviados.
SDES (source description items): contiene información que describe al emisor.
BYE: indica la finalización de la participación en una sesión.
APP (application specific functions):
aplicaciones futuras.
RSVP – Resource ReSerVation Protocol
Por ahora es experimental. Está reservado para
RSVP es un protocolo de control desarrollado por el Xerox PARC, el MIT y el Information
Sciences Institute de la Universidad de California. Permite brindar al receptor calidad de servicio
para un flujo de datos. Las aplicaciones de tiempo real pueden utilizar este protocolo para reservar
recursos en los ruteadores que se encuentran en una determinada ruta (entre emisor y receptor) a los
efectos de asegurar un ancho de banda disponible para una transmisión.
Cuando una aplicación en un nodo receptor requiere determinada calidad de servicio, solicita a los
ruteadores en el camino una reserva de recursos utilizando el protocolo RSVP. No es necesario
realizar la reserva en todo el camino hasta el emisor, sino que se hace hasta encontrar en un ruteador
una solicitud de reserva para la misma fuente de datos, y unirse a ésta.
Los nodos con capacidad de reservar recursos deben implementar controles para determinar si el
usuario posee permisos para realizar reservas (Policy Control) y además determinar si se puede
satisfacer la calidad de servicio solicitada (Admission Control). Cuando un paquete ingresa al nodo,
se lo clasifica de acuerdo a los requerimientos solicitados para el mismo (Packet Classifier), y luego
se ordena su transmisión (Packet Scheduler) para alcanzar la calidad de servicio comprometida para
éste. Las reservas realizadas se almacenan como “estados ligeros” (soft states). Esto significa que
deben enviarse mensajes de refresco para mantener una reserva, de lo contrario se pierde.
La determinación de los parámetros de conexión para alcanzar una determinada calidad de servicio
es tarea de los dispositivos de control correspondientes, RSVP solamente facilita la distribución de
los mismos.
RTSP – Real Time Streaming Protocol
RTSP es un protocolo cliente-servidor desarrollado por la empresa RealNetworks, Netscape
Communications y la Universidad de Columbia. Permite el control de un flujo multimedia
entregado sobre una red IP. Provee funciones tales como pausa, avance, retroceso y
posicionamiento absoluto. Es un protocolo de aplicación diseñado para trabajar con RTP y RSVP
para proveer un servicio de “streaming” sobre Internet. Además, incorpora mecanismos para
seleccionar canales de entrega (UDP, UDP multicast y TCP) y mecanismos de entrega basados en
RTP. Trabaja en modo multicast ó unicast.
RTSP establece y controla un flujo continuo de audio y video entre un servidor multimedia y un
cliente. Un servidor multimedia provee servicios de reproducción y grabación, mientras que un
cliente es quien solicita el servicio. Cada presentación o flujo multimedia se identifica mediante una
URL. Las propiedades de la presentación se definen en un “archivo de descripción de
presentación”, que puede incluir la codificación, idioma, RTSP URL, dirección destino, puerto y
otros parámetros. Este archivo puede ser obtenido por el cliente mediante HTTP, email u otro
medio.
Las solicitudes RTSP generalmente se envían por un canal independiente al de datos. Pueden
transmitirse en conexiones persistentes, una conexión por transacción ó en modo sin conexión.
Arquitectura Propuesta
Se define una arquitectura para un servicio de distribución de flujos de radio en Internet, basado en
una red de aplicación, que opera bajo el modelo cooperativo compañero a compañero. La presente
propuesta tiene por finalidad que los nodos participantes de la red puedan retransmitir un flujo de
radio a un conjunto de receptores, pudiendo éstos operar de la misma manera. Este modelo permite
que nodos generadores de una señal de radio, con recursos limitados en ancho de banda, puedan
hacer llegar su señal a un gran número de receptores (situación no factible si se operara de acuerdo
al modelo normal de trabajo). Esta arquitectura es una alternativa válida al uso de técnicas de
multicast, dado que permite optimizar los recursos en base a la cooperación de los nodos
participantes de la red.
Cada participante de la red se va a comportar como un nodo gnutella [DSS, BOR] a los efectos de
integrar la red de propagación de mensajes, y como retransmisor de flujos de audio. A tal efecto
debe ejecutar dos módulos de software a saber:
a) Servent gnutella con extensiones para anuncio y solicitud de flujos
b) Aplicación de retransmisión de audio (relay audio server).
Si bien existe software de retransmisión de audio (por ejemplo Shoutcast de la empresa Nullsoft)
[http://www.nullsoft.com] la problemática para los usuarios radica en saber quién o quiénes
disponen del servicio en cuestión en un determinado momento. La red de aplicación gnutella, con el
agregado de extensiones al protocolo, permitiría la distribución de mensajes de anuncio del servicio
por parte de los nodos proveedores y de mensajes de consulta por parte de nodos consumidores.
Nodo 6
Emisor de
Radio B
Nodo 1
Emisor de
Radio A
Nodo 7
Nodo 2
Nodo 10
Nodo 5
Nodo 3
Nodo 9
Nodo 4
Nodo 8
Gráfico de la arquitectura
El gráfico anterior muestra una red de aplicación (─ ─) en la cual existen dos nodos generadores
de señales de radio (Nodo 1 y Nodo 6). Cada uno de éstos provee su flujo a otros nodos, los cuales
– a su vez – tienen la posibilidad de retransmitir la señal. En el ejemplo, el nodo 1 es una estación
de radio que transmite su señal (─ ─ ) a los nodos 2 y 3, siendo este último un retransmisor de la
misma. Por otro lado, el nodo 6 transmite su señal (─ ─ ) a los nodos 5 y 10. Cada nodo puede
decidir si es capaz de retransmitir un flujo de audio en función de sus recursos disponibles. Por
ejemplo, el nodo 8 recibe la señal desde el nodo 3 y es capaz de retransmitirla a otros tres nodos
(5,9 y 10).
La retransmisión de la señal se realiza de manera independiente de la red de aplicación, operando de
manera punto a punto entre proveedor y consumidor, y utilizando los protocolos existentes para la
transmisión de flujos de audio sobre Internet.
Características de gnutella
Gnutella define una red a nivel aplicación, bajo la modalidad compañero a compañero (peer to
peer), donde todo nodo realiza al mismo tiempo funciones de cliente y servidor. Conceptualmente,
es un sistema distribuido para almacenamiento y búsqueda de información. Es importante destacar
dos características fundamentales: su carácter descentralizado y su espíritu cooperativo.
En su modalidad de operación, un nodo X ofrece abiertamente los archivos que desee compartir con
otros usuarios, mientras que a la vez el usuario dueño del nodo Y puede estar recuperando, como
cliente, archivos del nodo X. La red gnutella se compone de numerosos nodos distribuidos a lo
largo del mundo. Su topología no indica jerarquía alguna, dado que cada nodo es igual a los demás
en funcionalidad. Cada nodo sólo sabe acerca de los nodos con los cuales se conecta directamente.
De forma resumida, la red gnutella opera bajo el modelo conocido “propagación por inundación”.
Un cliente envía un mensaje a un nodo, y este lo reenvía a todos los nodos a los cuales esté
conectado; de esta forma, con solo conocer la dirección de red de un nodo ya se puede ingresar a la
misma.
El modelo compañero a compañero implementado en gnutella, requiere que los nodos tengan la
capacidad de propagar los mensajes recibidos a través de sus conexiones establecidas. A los efectos
de hacer eficiente la operación de la red (teniendo en cuenta su topología, la no jerarquía y la
existencia de loops) deben implementarse en cada nodo, una serie de reglas de propagación [DSS].
Una vez que un nodo recibe un resultado a una consulta previamente realizada, puede optar por
seleccionar un archivo para su descarga desde el nodo remoto. Los archivos se recuperan
directamente, sin intervención de nodos intermedios y por lo tanto tampoco de la red gnutella,
mediante el uso del protocolo HTTP.
Extensiones al protocolo gnutella
A los efectos de la implementación del servicio se preveen tres tipos de nuevos mensajes a anexar a
la especificación de gnutella, los mismos son:
a) PROVEO_FLUJO. Cada nodo en caso de poseer recursos de retransmisión disponibles,
periódicamente generará este mensaje.
b) QUIEN_TIENE_FLUJO_CONSULTA
y QUIEN_TIENE_FLUJO_RESPUESTA.
Mensaje utilizados para preguntar y responder acerca de proveedores de señales de radio
disponibles.
c) CIERRO_FLUJO. Mensaje que anuncia cierre de una retransmisión.
a) Función PROVEO_FLUJO
Se recomienda que periodicamente –en forma inicial se podría determinar que cada 5 minutostodos los nodos que provean servicio de retransmisión y tengan recursos disponibles (ancho de
banda y flujo) deben publicitar en la red tales servicios.
Para realizar tal tarea, los nodos, se valdrán de la función PROVEO_FLUJO y propagarán esta
extensión de igual forma que un mensaje PING. En su estructura de datos deberá contener la
dirección de red (IP) del nodo y una lista donde cada elemento será un flujo determinado a proveer.
El mensaje finaliza con dos caracteres null consecutivos. Un elemento de la lista –un flujo- se lo
denota con los siguientes atributos: PUERTO CODIGO_FLUJO IDIOMA NOMBRE_FLUJO;
PUERTO (dos bytes) indica el número de puerto TCP donde un posible receptor del flujo debe
conectarse para recibirlo,. CODIGO_FLUJO (dos bytes) es determinado por una tabla donde se
codifican las distintas categoría de flujo existentes. IDIOMA (un byte) es un código que hace
referencia al lenguaje del flujo. Por último una descripción, de longitud variable, del flujo. El
delimitador final de un elemento es el carácter punto y coma.
Ejemplo de tabla de Códigos de Flujos
EN
EC
CD
CT
Estación de radio de noticias
Estación de radio de música country
Flujo de audio educativo
Canal indicador del tiempo
Ejemplo de tabla de Idiomas
S
E
Español
Inglés
Identif icador de nodo
16 by tes
Función
1 by te
TTL
1 by te
Hops
1 by te
Largo de la carga
4 by tes
Función Prove o_Flujo (0x60)
Dirección IP
4 by tes
Lista de señales
n by tes
Terminador
2 by tes
b) Función QUIEN_TIENE_FLUJO_CONSULTA y QUIEN_TIENE_FLUJO_RESPUESTA
Cuando un nodo desea saber quien tiene capacidad disponible de retransmisión de un determinado
flujo deberá revisar en su cache por los últimos mensajes PROVEO_FLUJO recibidos. En caso de
no hallar alguno deberá enviar por la red un mensaje QUIEN_TIENE_FLUJO_CONSULTA. El
cual llevará los siguientes campos: TIPO_SEÑAL IDIOMA AB y DESCRIPTOR. Donde en los
campos TIPO SEÑAL e IDIOMA se instancian los códigos según tabla, y en caso de no requerirse
tales coincidencias se completan con espacios. AB es el ancho de banda mínimo requerido para
obtener el flujo y DESCRIPTOR es un campo que se lo tratará como una subcadena de búsqueda.
Identif icador de nodo
16 by tes
Función
1 by te
TTL
1 by te
Hops
1 by te
Largo de la carga
4 by tes
Función Quién_Tiene_Flujo_Consulta
(0x61)
Tipo señal
2 by tes
Idioma
1 by te
AB
2 by tes
Función Quién_Tiene_Flujo_Respuesta
(0x62)
Dirección IP
4 by tes
Lista
n by tes
Terminador
2 by tes
Descriptor
n by tes
El mensaje se propaga de la misma forma que un QUERY en gnutella. Cada nodo que lo reciba,
además de propagarlo según reglas, verificará que haga match con algún flujo disponible. En caso
de existir tal flujo y recursos disponibles (ancho de banda y capacidad de retransmisión) contestará
algo peticionante mediante una mensaje QUIEN_TIENE_FLUJO_RESPUESTA, se propagará de
igual forma que un QUERY_HIT del protocolo gnutella. La estructura de datos será igual a la
descripta en la extensión PROVEO_FLUJO.
Función CIERRO FLUJO
Cuando un nodo, que está retransmitiendo un flujo determinado, decide dejar la red de aplicación
debe informar de tal decisión a aquellos otros nodos que están recibiendo flujos de él. Para tal fin se
utiliza el mensaje denominado CIERRO_FLUJO, donde generará un mensaje por cada
retransmisión que realize. El mensaje lleva en su carga los siguientes campos
ID_NODO_DESTINO es la identificación gnutella del nodo que está recibiendo actualmente el
flujo, PUERTO_ACTUAL puerto TCP de retransmisión del mencionado flujo.
NUEVA_DIRECCION_IP y NUEVO_PUERTO son campos que indican de donde el nodo
actualmente está tomado el flujo, estos campos sirven para que el nodo que va a perder el audio,
pueda tomarlo nuevamente de otro nodo. El mensaje debe propagarse de la misma forma que al
función PING.
Identif icador de nodo
16 by tes
Función
1 by te
TTL
1 by te
Hops
1 by te
Largo de la carga
4 by tes
Función Cierro_Flujo (0x63)
ID Nodo Destino Puerto actual
16 by tes
2 by tes
Nuev a
Nuev o Puerto
Dirección IP
2 by tes
4 by tes
Consideraciones
Esta arquitectura puede ser una alternativa válida al problema de retransmisión de flujos de audio en
aquellos casos en que la fuente no dispone de recursos en demasía para soportar una importante
cantidad de usuarios. Mediante el esquema presentado, cada usuario puede cooperar ofreciendo
servicios de retransmisión.
La red de transporte de consultas, por basarse en el protocolo gnutella, posee ciertas características
deseables, como ser: a) robustez, b) transparencia ante cambio de direcciones ó equipos, c)
concurrencia de la operación de consulta y d) alta disponibilidad entre un nodo y la red.
Bibliografía
DSS
DSS. “The Gnutella Protocol Specification v0.4. Distributed Search Services”.
http://dss.clip2.com. 2000.
BOR
F. Bordignon y G. Tolosa. “Gnutella: Distributed System for Information Storage
and Searching. Model Description". JIT- Journal of Internet Technology. Taipei
(Taiwan) Vol. 2, No. 5. 2001
TOL
G. Tolosa y F. Bordignon “Propuesta de Arquitectura Cooperativa Destinada a un
Servicio de Búsqueda Distribuida en el Espacio Web. Una Alternativa a los Motores
de Búsqueda Tradicionales ”. Poster. Jornadas de la Ciencia y Tecnología.
Universidad Nacional de Luján. 2001