Next Previous Contents

1. Introducción.

Intentaré darle la información más amplia, precisa y al día relacionada con multicast sobre redes TCP/IP que me sea posible. Cualquier «feedback» es bienvenido. Si encuentra cualquier error en este documento, tiene un comentario sobre sus contenidos, o una actualización o cosa a añadir, por favor envíemelo a la dirección que aparece al principio de este documento.

1.1 ¿Qué es Multicast?

Multicast es... una necesidad. Bueno, al menos en algunas ocasiones. Si tiene información (mucha información habitualmente) que debe ser transmitida a varios ordenadores (pero no a todos) en una Internet, entonces la respuesta es Multicast. Una situación frecuente donde se utiliza es en la distribución de audio y vídeo en tiempo real a un conjunto de ordenadores que se han unido a una conferencia distribuida.

Multicast es, en gran medida, como la televisión o la radio, es decir, sólo aquellos que han sintonizado sus receptores (al seleccionar una frecuencia particular que les interesa) reciben la información. Esto es: escucha los canales que te interesan, pero no otros.

1.2 El problema con Unicast.

Unicast es cualquier cosa que no sea broadcast o multicast. Está bien, la definición no es muy brillante... pero cuando envías un paquete y sólo hay un emisor -tú- y un receptor (aquél al que envías el paquete), entonces estás haciendo unicast. TCP es, por propia naturaleza, orientado a unicast. UDP soporta muchos otros paradigmas, pero si estás enviando paquetes UDP y sólo se supone que hay un proceso que lo recibe, es también unicast.

Durante años las transmisiones unicast demostraron ser suficientes para Internet. La primera implementación de multicast no vio la luz hasta 1993, con la versión 4.4 de BSD. Parece que nadie lo necesitaba hasta entonces. ¿Cuáles eran los nuevos problemas que trataba de arreglar multicast?

No es necesario decir que Internet ha cambiado mucho desde aquellos años. Particularmente, el nacimiento de la World Wide Web (WWW) cambió sensiblemente la situación: la gente no quería solamente conexiones a ordenadores remotos, correo electrónico y FTP. Primero querían ver las fotos de las personas, dentro de páginas personales, pero más tarde también querían verles y oírles.

Con la tecnología actual es posible afrontar el «coste» de hacer una conexión unicast con todos aquellos que desean ver su página web. Sin embargo, si quieres enviar audio y vídeo, que necesita de un gran ancho de banda comparado con aplicaciones de web, tienes (tenías, hasta que apareció multicast) dos opciones: establecer conexiones unicast por separado con cada uno de los receptores, o usar broadcast. La primera solución no era factible: si hemos dicho que cada conexión enviando audio/vídeo consume una gran cantidad de ancho de banda, imagina tener que establecer cientos, quizás miles, de estas conexiones. Tanto el ordenador emisor como su red se colapsarían.

Broadcast parece una solución, pero desde luego no es la solución. Si deseara que todos los ordenadores en su LAN atendieran la conferencia, podrías usar broadcast. Se enviarían los paquetes una sola vez y cada ordenador lo recibiría ya que fueron enviados a la dirección de broadcast. El problema es que quizás solo algunos de éstos y no todos estén interesados en estos paquetes. Más aún: quizás algunos ordenadores están realmente interesados en su conferencia, pero están fuera de su LAN, a varios routers de distancia. Y ya se sabe que el broadcast funciona bien dentro de una LAN, pero surgen problemas cuando haces broadcast de paquetes que deben ser enviados a través de diferentes LANs.

La mejor solución parece ser aquella en la que sólo se envían paquetes a ciertas direcciones especiales (una determinada frecuencia en transmisión de radio y televisión). Así, todos los ordenadores que han decidido unirse a la conferencia conocerán la dirección de destino, de forma que los recogerán cuando pasen por la red y los enviarán a la capa IP para que sean demultiplexados. Esto es similar al broadcast en el sentido de que sólo se envía un paquete de broadcast y todos los ordenadores en la red lo reconocen y lo leen; difiere, sin embargo, en que no todos los paquetes de multicast son leídos y procesados, sino solamente los que han sido registrados en el kernel como «de interés».

Estos paquetes especiales son encaminados en el nivel del kernel como cualquier paquete porque son paquetes IP. La única diferencia puede estar en el algoritmo de encaminamiento que le dice al kernel si debe o no encaminarlos.


Next Previous Contents