Comunicación de grupo



Descargar 125.54 Kb.
Fecha de conversión13.03.2017
Tamaño125.54 Kb.


  1. Comunicación de grupo

En los capítulos previos, se ha presentado la comunicación entre procesos (IPC, Interprocess Communication) como el intercambio de información entre dos procesos. En este capítulo, se examinará la IPC entre un grupo de procesos, o comunicación de grupo.

6.1Unidifusión frente a multidifusión


En la IPC que se ha presentado hasta ahora, los datos se mandan desde un proceso de origen, el emisor, a un proceso de destino, el receptor. Esta forma de IPC se denomina unidifusión, el envío de información a un único receptor, en contraste con multidifusión, el envío de información a múltiples receptores. La unidifusión proporciona una IPC de uno-a-uno, mientras que la multidifusión provee una IPC de uno-a-muchos. Véase la Figura 6.1.



Figura 6.1 IPC de unidifusión y de multidifusión.

Mientras que la mayoría de servicios y aplicaciones de red utilizan unidifusión para IPC, la multidifusión es útil para aplicaciones tales como mensajes inmediatos, groupware, conferencias en línea y aprendizaje interactivo, y puede utilizarse para aplicaciones tales como subastas en línea en tiempo real. La multidifusión es también útil para la replicación de servicios con el propósito de obtener tolerancia a fallos.

En aplicaciones o servicios de red que hacen uso de multidifusión, un conjunto de procesos forma un grupo, llamado grupo de multidifusión. Cada proceso en un grupo puede mandar y recibir mensajes. Un mensaje enviado por cualquier proceso del grupo puede recibirlo cada proceso que forma parte del grupo. Un proceso puede también decidir abandonar un grupo de multidifusión.

En una aplicación como puede ser una conferencia en línea, un grupo de procesos interaccionan utilizando multidifusión para intercambiar audio, vídeo y/o datos de texto.

Como en ocasiones anteriores, la discusión se centrará en el nivel de servicio, específicamente en el mecanismo de IPC, de la aplicación.

6.2Una API de multidifusión arquetípica


Una interfaz de programación de aplicaciones que provea multidifusión debe proporcionar las siguientes operaciones primitivas:

  • Incorporación. Esta operación permite a un proceso unirse a un grupo de multidifusión específico. Un proceso que se ha unido a un grupo de multidifusión es un miembro del grupo, lo que le da derecho a recibir todos los mensajes dirigidos al grupo. Un proceso puede ser miembro de uno o más grupos de multidifusión en un momento dado. Nótese que para esta y otras operaciones de multidifusión se necesita un esquema de denominación que permita identificar de forma única un grupo de multidifusión.

  • Abandono. Esta operación permite que un proceso deje de formar parte de un grupo de multidifusión. Un proceso que ha dejado un grupo de multidifusión ya no es miembro del mismo y, por tanto, no tiene derecho a recibir ninguna multidifusión dirigida al grupo, aunque el proceso pueda seguir siendo miembro de otros grupos de multidifusión.

  • Envío. Esta operación permite que un proceso mande un mensaje a todos los procesos que actualmente forman parte de un grupo de multidifusión.

  • Recepción. Esta operación permite que un proceso miembro reciba mensajes enviados a un grupo de multidifusión.

En la sección 6.5 se examinarán el API de multidifusión de Java y algunos programas de ejemplo que usan esta API. En ese momento se verá cómo se proporcionan estas operaciones primitivas utilizando la sintaxis de Java. Antes de esto, sin embargo, se explorarán algunas de las cuestiones interesantes específicas de la multidifusión, que surgen de la naturaleza uno-a-muchos de la multidifusión.

6.3Multidifusión sin conexión frente a orientada a conexión


El mecanismo de multidifusión básico es sin conexión. La razón es obvia si se considera la naturaleza uno-a-muchos de la multidifusión. En un grupo de n procesos, si se establece una conexión entre el emisor y cada uno de los otros procesos del grupo, se necesitará un total de n-1 conexiones. Además, cada uno de los n procesos puede ser potencialmente un emisor, de manera que cada proceso debe mantener una conexión con cada uno de los otros procesos, dando lugar a un total de n *(n-1) o, redondeando, n2 conexiones. Si n-1 es grande, el número total de conexiones será prohibitivamente elevado.

Además, la IPC sin conexión es apropiada para un tipo común de aplicaciones de multidifusión: aplicaciones donde se transmiten datos de audio y vídeo entre procesos en tiempo real. (Que los datos se transmiten en tiempo real, significa que la latencia entre el emisor y el receptor debería ser cercana a cero). Cuando se transmiten los datos de audio o vídeo, la reducción en la latencia proporcionada por la comunicación sin conexión prevalece sobre las ventajas ofrecidas por la comunicación orientada a conexión. Cuando se envían datos para una animación, por ejemplo, es más aceptable que el receptor experimente una distorsión ocasional en la imagen de un fotograma (un acontecimiento probable con una comunicación sin conexión) que un retraso frecuente perceptible entre fotogramas consecutivos (un acontecimiento probable con una comunicación orientada a conexión).


6.4Multidifusión fiable frente a no fiable


Cuando un proceso envía un mensaje de multidifusión, el soporte en tiempo de ejecución del mecanismo de multidifusión es responsable de entregar los mensajes a cada proceso que pertenezca actualmente al grupo de multidifusión. Dado que cada proceso implicado puede residir en una máquina diferente, la entrega de los mensajes requiere la cooperación de mecanismos que están ejecutando independientemente en esos sistemas. Debido a factores como fallos en enlaces de la red, defectos en las máquinas de la red, demoras en el encaminamiento y diferencias en el software y hardware, el tiempo desde que se manda un mensaje de multidifusión hasta que se recibe puede variar en los distintos procesos receptores. Mientras que las diferencias en la entrega del mensaje entre distintas máquinas puede ser insignificante si las máquinas están ubicadas geográficamente próximas, puede no ser así si las máquinas están distribuidas en una red de área amplia.

Asimismo, puede ocurrir que uno o más procesos no reciban un mensaje, debido a errores y/o fallos en la red, en las máquinas o en el soporte en tiempo de ejecución.

Mientras que algunas aplicaciones, tales como conferencias de vídeo, pueden tolerar un fallo ocasional o el desorden en los mensajes recibidos, hay aplicaciones —como las aplicaciones de base de datos— en las que tales anomalías no son aceptables.

Por tanto, cuando se emplea un mecanismo de multidifusión para una aplicación, es importante que se elija uno con las características apropiadas para dicha aplicación. En caso contrario, se necesitarán proporcionar medidas en la lógica de aplicación para manejar las anomalías que pueden ocurrir en la entrega de los mensajes. Por esta razón, es útil clasificar los mecanismos de multidifusión en términos de sus características de entrega de mensajes.


Multidifusión no fiable


Básicamente, el sistema de multidifusión hará un intento bienintencionado de entregar los mensajes a cada proceso que forma parte del grupo, pero no se garantiza la entrega del mensaje en su forma correcta a cada proceso. De esta manera, cualquier mensaje enviado por un proceso puede ser recibido por cero o más procesos. En el mejor de los casos, todos los procesos reciben el mensaje en su forma correcta. En el peor de los casos, ningún proceso recibe correctamente el mensaje. En otros casos, algunos procesos pueden recibir el mensaje, pero otros procesos no, o algunos procesos pueden recibir el mensaje corrupto, o más de una vez. Se dice que un sistema de este tipo proporciona multidifusión no fiable.

Multidifusión fiable


Un sistema de multidifusión que garantice que finalmente se entrega correctamente cada mensaje a cada proceso del grupo se dice que proporciona multidifusión fiable. En este sistema, se puede asumir que cada mensaje que envía un proceso va a ser finalmente entregado sin estar corrupto a todos los procesos del grupo.

La definición de multidifusión fiable requiere que cada proceso participante reciba exactamente una copia de cada mensaje enviado. Sin embargo, la definición no establece ninguna restricción sobre el orden en que se entregan los mensajes a cada proceso individual: Cada proceso puede recibir los mensajes en una secuencia que corresponde con cualquier permutación del orden en que fueran mandados. En aplicaciones donde el orden de entrega del mensaje es significativo, es útil clasificar a su vez a los sistemas de multidifusión fiable como se describe a continuación.


Sin orden


Un sistema de multidifusión fiable sin orden garantiza la entrega segura de cada mensaje, pero no proporciona ninguna garantía sobre el orden de entrega de los mensajes.

Por ejemplo, considere que tres procesos P1, P2 y P3 han formado un grupo de multidifusión. Además, supóngase que se envían tres mensajes, m1, m2 y m3, al grupo. En ese caso, un sistema de multidifusión fiable sin orden puede entregar los mensajes a cada uno de los tres procesos en cualquiera de las 3! (factorial de 3)= 6 permutaciones (m1-m2-m3, m1-m3-m2, m2-m1-m3, m2-m3-m1, m3-m1-m2 o m3-m2-m1).

Nótese que es posible que cada participante reciba los mensajes en un orden diferente al de entrega de los mensajes a otros participantes. En el ejemplo, es posible que a P1 se le entreguen los mensajes en el orden m1-m2-m3, mientras que que a P2 se le entreguen en el orden m2-m1-m3, y a P3 en el orden m1-m3-m2. Por supuesto, es también posible que los mensajes se entreguen a P1, P2 y P3 en el mismo orden, m1-m2-m3, pero no se puede hacer esta suposición en una aplicación si se emplea un mecanismo de multidifusión sin orden.

Multidifusión FIFO


Un sistema que garantice que la entrega de los mensajes se adhiere a la siguiente condición se dice que proporciona una multidifusión FIFO (primero en entrar-primero en salir, first in-first out), o en orden-de-envío:

Si el proceso P manda los mensajes mi y mj, en ese orden, a un grupo de multidifusión, entonces a cada proceso en el grupo de multidifusión se le entregarán los mensajes en ese orden.

Para ilustrar esta definición, se examinará un ejemplo. Supóngase que P1 manda los mensajes m1, m2, y m3, en este orden, a un grupo de multidifusión G. En este caso, con una multidifusión FIFO, se garantiza que a cada proceso de G se le entregarán los mensajes en ese mismo orden: m1, m2 y, a continuación, m3. Nótese que esta definición no establece ninguna restricción en el orden de entrega de los mensajes mandados por procesos diferentes. Para ilustrar este punto, se utilizará un ejemplo simplificado de un grupo de multidifusión de dos procesos: P1 y P2. Supóngase que P1 envía los mensajes m11 y después m12 , mientras que P2 manda los mensaje m21 y, a continuación, m22. En este caso, un sistema de multidifusión FIFO puede entregar los mensajes a cada uno de los procesos en cualquiera de los siguientes órdenes:

m11-m12-m21-m22, m11-m21-m12-m22, m11-m21-m22-m12,

m21-m11-m12-m22, m21-m11-m22-m12, m21-m22-m11-m12.

Nótese que mientras que los mensajes que manda P1 se entregan a cada proceso en el orden de secuencia m11-m12, y los enviados por P2 se entregan en el orden de secuencia m21-m22, las dos secuencias pueden intercalarse de cualquier manera.

Multidifusión en orden causal


Un sistema de multidifusión se dice que proporciona una multidifusión causal si la entrega de mensajes satisface el siguiente criterio:

Si un mensaje mi causa (tiene como consecuencia) la existencia del mensaje mj, entonces mi se entregará a cada proceso antes que mj. Los mensajes mi y mj tiene una relación llamada relación sucede-antes o causal, denotada como mi→mj.

La relación sucede-antes es transitiva: si mi→mj y mj→mk, entonces mi→mj→mk. En este caso, un sistema de multidifusión en orden causal garantiza que estos tres mensajes se entreguen a cada proceso en el orden de mi, mj y, a continuación, mk.

Como una ilustración, supóngase que tres procesos –P1, P2 y P3– están en un grupo de multidifusión. P1 manda un mensaje m1, al que P2 responde con un mensaje m2. Dado que m2 es desencadenado por m1, comparten una relación causal de m1→m2. Supóngase que la recepción de m2 causa a su vez que P3 envíe un mensaje de multidifusión m3, es decir, m2→m3. Los tres mensajes, por tanto, comparten la relación causal de m1→m2→m3. Un sistema de mensajes de multidifusión en orden causal garantiza que estos tres mensajes se entregan a cada uno de los tres procesos en el orden m1-m2-m3. Nótese que en este caso no habría ninguna restricción en el orden de entrega de los mensajes si el sistema de multidifusión fuera FIFO en lugar de causal.

Haciendo una variación del ejemplo anterior, supóngase que P1 multidifunde un mensaje m1, al que P2 responde con un mensaje de multidifusión m2 y, de forma independiente, P3 contesta a m1 con un mensaje de multidifusión m3. Los tres mensajes comparten ahora la relación causal: m1→m2 y m1→m3. Un sistema de multidifusión en orden causal puede entregar estos mensajes a los procesos participantes en cualquiera de las dos siguientes órdenes:

m1-m2-m3

m1-m3-m2

En este ejemplo, no es posible que se entreguen los mensajes a cualquiera de los procesos en cualquier otra permutación de los tres mensajes, tales como m2-m1-m3 o m3-m1-m2. La primera de estas permutaciones viola la relación causal m1→m2, mientras que la segunda lo hace con la relación causal m1→ m3.

Multidifusión en orden atómico


En un sistema de multidifusión en orden atómico, se garantiza que todos los mensajes son entregados a cada participante exactamente en el mismo orden. Nótese que el orden de entrega no tiene porque ser FIFO o causal, pero debe ser el mismo para todo proceso.

Ejemplo:



P1 manda m1, P2 manda m2, y P3 manda m3.
Un sistema atómico garantizará que los mensajes se entregarán a cada proceso en sólo uno de los seis siguientes órdenes: m1-m2-m3, m1-m3-m2, m2-m1-m3, m2-m3-m1, m3-m1-m2, m3-m2-m1.

Ejemplo:


P1 manda m1 y, a continuación, m2.

P2 responde a m1 mandando m3.

P3 responde a m3 enviando m4.


Aunque la multidifusión atómica no impone ningún orden en estos mensajes, la secuencia de eventos dicta que P1 debe entregar m1 antes de enviar m2. De manera similar, P2 debe recibir m1 y, a continuación, m3, mientras que P3 debe recibir m3 antes de m4. Por ello, cualquier orden de entrega atómica debe preservar el orden m1-m3-m4. El mensaje restante m2 puede, sin embargo, intercalarse con estos mensajes de cualquier manera. Por tanto, una multidifusión atómica dará como resultado que los mensajes se entreguen a cada uno de los procesos en uno de los siguientes órdenes: m1-m2-m3-m4, m1-m3-m2-m4 o m1-m3-m4-m2. Por ejemplo, los mensajes pueden entregarse a cada proceso en este orden: m1-m3-m2-m4.

6.5El API de multidifusión básica de Java


En el nivel de transporte, la multidifusión básica soportada por Java es una extensión del Protocolo Datagrama de Usuario (UDP, User Datagram Protocol). que, como se recordará, es sin conexión y no fiable. En el nivel de red de la arquitectura de red, los paquetes de multidifusión se transmiten a través de la red utilizando el encaminamiento de multidifusión de Internet [cisco.com, 5] proporcionado por encaminadores (conocidos como mrouters) capaces de encaminar la multidifusión además de la unidifusión. La multidifusión en una red local (una interconectada sin un encaminador) se lleva a cabo utilizando la multidifusión proporcionada por el protocolo de red de área local (como la multidifusión de Ethernet). El encaminamiento y entrega de mensajes de multidifusión son temas fuera del ámbito de este libro. Afortunadamente, tales asuntos son transparentes a un programador de aplicaciones que utiliza una API de multidifusión.

El API de multidifusión básica de Java proporciona un conjunto de clases que están estrechamente relacionadas con las clases del API de sockets de datagrama que se examinó en el Capítulo 4. Hay tres clases principales en el API, las dos primeras ya se han visto en el contexto de los sockets datagrama.



  1. InetAddress. En el API de sockets datagrama, esta clase representa la dirección IP del emisor o del receptor. En la multidifusión, esta clase puede utilizarse para identificar un grupo de multidifusión (como se explicará en la próxima sección “Direcciones IP de multidifusión”).

  2. DatagramPacket. Como en el caso de los sockets datagrama, un objeto de esta clase representa un datagrama real; en multidifusión, un objeto de DatagramPacket representa un paquete de datos enviado a todos los participantes o recibidos por cada participante de un grupo de multidifusión.

  3. MulticastSocket. La clase MulticastSocket se deriva de la clase DatagramSocket, con capacidades adicionales para incorporarse o abandonar un grupo de multidifusión. Un objeto de las clase socket datagrama de multidifusión puede utilizarse para mandar y recibir paquetes IP de multidifusión.

Direcciones IP de multidifusión


Recuérdese que en el API de socket de unidifusión de Java, un emisor identifica a un receptor especificando el nombre de la máquina del proceso receptor, así como el puerto del protocolo al que está ligado dicho proceso.

Considérese por un momento a quién necesita dirigirse un emisor de multidifusión. En lugar de a un único proceso, un datagrama de multidifusión está destinado a ser recibido por todos los procesos que son miembros actuales de un grupo de multidifusión específico. Por tanto, cada datagrama necesita dirigirse a un grupo de multidifusión en vez de a un proceso individual. El API de multidifusión de Java utiliza las direcciones de multidifusión del Protocolo de Internet (IP, Internet Protocol) para identificar los grupos de multidifusión.

En IPv4, un grupo de multidifusión se especifica mediante (1) una dirección IP de la clase D combinada con (2) un número de puerto estándar de UDP. (Nótese que en IPv6 el direccionamiento de multidifusión es significativamente diferente; véase [faqs.org, 4] para más detalles). Recuerde del Capítulo 1 que las direcciones IP de la clase D son aquellas que comienzan con la cadena de bits 1110, y, por tanto, estas direcciones están en el rango desde el 224.0.0.0 al 239.255.255.255, inclusive. Excluyendo los cuatro bits del prefijo, hay 32-4 = 28 bits restantes, lo que da lugar a un tamaño del espacio de direcciones de 228, es decir, están disponibles, aproximadamente, 268 millones de direcciones de clase D, aunque se reserva la dirección 224.0.0.0 y no debería utilizarse por ninguna aplicación. Las direcciones de multidifusión IPv4 las gestiona y asigna la Autoridad de Números Asignados de Internet (IANA, Assigned Numbers Authority) [rfc-editor.org, 3].

Una aplicación que utiliza el API de multidifusión de Java debe especificar al menos una dirección de multidifusión para la aplicación. A la hora de seleccionar una dirección de multidifusión para una aplicación, se presentan las siguientes opciones:



  1. Obtener una dirección de multidifusión estática permanentemente asignada de IANA. Las direcciones permanentes están limitadas a aplicaciones de Internet globales y bien conocidas y su asignación está muy restringida. En IANA [iana.org, 2], se puede encontrar la lista de direcciones actualmente asignadas. A continuación, se presenta una muestra de algunas de las direcciones asignadas más interesantes:

224.0.0.1 Todos los sistemas en esta subred

224.0.0.11 Agentes móviles

224.0.1.16 MUSIC-SERVICE

224.0.1.17 SEANET-TELEMETRY

224.0.1.18 SEANET-IMAGE

224.0.1.41 gatekeeper

224.0.1.84 jini-announcement

224.0.1.85 jini-request

224.0.1.115 Multidifusión simple

224.0.6.0-224.0.6.127 Proyecto ISIS de Cornell

224.0.7.0-224.0.7.255 Where-Are-You

224.0.8.0-224.0.8.255 INTV

224.0.9.0-224.0.9.255 Invisible Worlds

224.0.11.0-224.0.11.255 NCC.NET Audio

224.0.12.0-224.0.12.063 Microsoft y MSNBC

224.0.17.0-224.0.17.031 Mercantile & Commodity Exchange

224.0.17.064-224.0.17.127 ODN-DTV

224.0.18.0-224.0.18.255 Dow Jones

224.0.19.0-224.0.19.063 Walt Disney Company

224.0.22.0-224.0.22.255 WORLD MCAST

224.2.0.0-224.2.127.253 Llamadas de conferencias multimedia




  1. Elegir una dirección arbitraria, suponiendo que la combinación de la dirección y el número de puerto elegidos de manera aleatoria no estará probablemente en uso.

  2. Obtener una dirección de multidifusión transitoria en tiempo de ejecución; esta dirección puede recibirla una aplicación mediante el Protocolo de Anuncio de Sesión (Session Announcement Protocol) [fads.org, 6].

La tercera opción queda fuera del ámbito de este capítulo. En los ejercicios y ejemplos se utilizará a menudo la dirección estática 224.0.0.1, con un nombre de dominio de ALL-SYSTEMS.MCAST.NET, para procesos que ejecutan en todas las máquinas de la red de área local, como las que tendrá el lector en su laboratorio. Alternativamente, se puede utilizar una dirección arbitraria que presumiblemente no haya sido asignada, como, por ejemplo, un número en el rango de 239.*.*.* (por ejemplo, 239.1.2.3).

En el API de Java, un objeto MulticastSocket se asocia a una dirección de puerto como, por ejemplo, 3456, y los métodos del objeto permiten unirse a una dirección de multidifusión como, por ejemplo, 239.1.2.3 y dejarla.

Incorporación a un grupo de multidifusión


Para incorporarse a un grupo de multidifusión en una dirección IP m y un puerto UDP p, se debe instanciar un objeto MulticastSocket con p y, a continuación, se puede invocar el método joinGroup, especificando la dirección m:
// incorporación a un grupo de multidifusión en la dirección IP 224.0.0.1 y

// en el puerto 3456

InetAddress grupo = InetAddress.getByName("224.0.0.1 ");

MulticastSocket s = new MulticastSocket(3456);

s.joinGroup(grupo);

Envío a un grupo de multidifusión


Se puede mandar un mensaje de multidifusión utilizando una sintaxis similar a la del API de sockets datagrama. Concretamente, se debe crear un paquete datagrama con la especificación de una referencia a un vector de octetos que contenga los datos, la longitud del vector, la dirección de multidifusión y el número de puerto. A continuación, se puede invocar el método send del objeto MulticastSocket (heredado de la clase DatagramSocket) para mandar los datos.

No es necesario que un proceso se una a un grupo de multidifusión para mandar mensajes al mismo, aunque debe hacerlo para poder recibir los mensajes. Cuando se manda un mensaje a un grupo de multidifusión, todos los procesos que se han unido al grupo de multidifusión, que puede incluir al emisor, deberían recibir el mensaje, aunque no se garantiza.

El siguiente segmento de código ilustra la sintaxis requerida para enviar un mensaje a un grupo de multidifusión:
String msj = "Este es un mensaje de multidifusión.";

InetAddress grupo = InetAddress.getByName("239.1.2.3");

MulticastSocket s = new MulticastSocket(3456);

s.joinGroup(grupo); // opcional

DatagramPacket hola = new DatagramPacket(msj.getBytes( ),

msj.length( ), grupo, 3456);

s.send(hola);


Recepción de mensajes mandados a un grupo de multidifusión


Un proceso que se ha unido a un grupo de multidifusión puede recibir mensajes enviados al grupo utilizando una sintaxis similar a la usada para recibir datos mediante una API de sockets datagrama. El siguiente segmento de código ilustra la sintaxis usada para recibir mensajes enviados a un grupo de multidifusión.
byte[] almacen = new byte[1000];

InetAddress grupo = InetAddress.getByName("239.1.2.3");

MulticastSocket s = new MulticastSocket(3456);

s.joinGroup(grupo);

DatagramPacket recibido = new DatagramPacket(almacen, almacen.length);

s.receive(recibido);



Abandono de un grupo de multidifusión


Un proceso puede dejar un grupo de multidifusión invocando el método leaveGroup de un objeto MulticastSocket, especificando la dirección de multidifusión del grupo:
s.leaveGroup(grupo);

Ajuste del “tiempo-de-vida”


El soporte en tiempo de ejecución de una API de multidifusión a menudo emplea una técnica conocida como propagación de mensajes, en la que se propaga un paquete desde una máquina a una máquina vecina usando un algoritmo que, cuando se ejecuta apropiadamente, entregará finalmente el mensaje a todos los participantes. Sin embargo, ante alguna circunstancia anómala, es posible que el algoritmo que controla la propagación de mensajes no termine apropiadamente, dando como resultado que un paquete circule por la red indefinidamente. Este fenómeno no es deseable, ya que causa una sobrecarga innecesaria en los sistemas y en la red. Para evitar que esto ocurra, se recomienda que se fije un parámetro “tiempo-de-vida” en cada datagrama de multidifusión. El parámetro de tiempo de vida (ttl, time-to-live), cuando se fija, limita el número de enlaces de red, o saltos, a través de los que se retransmitirá el paquete en la red.

En el API de Java, este parámetro se puede fijar invocando el método setTimeToLive del MulticastSocket del emisor de la siguiente manera:


String msj = "¡Hola a todos!";

InetAddress grupo = InetAddress.getByName("224.0.0.1");

MulticastSocket s = new MulticastSocket(3456);

s.setTimeToLive(1); // ajusta time-to-live a 1 salto – un valor apropiado

// para multidifusión en máquinas locales

DatagramPacket hola = new DatagramPacket(msj.getBytes( ),

msj.length( ),grupo, 3456);

s.send(hola);


El valor especificado para el ttl debe estar en el rango 0 ≤ ttl ≤ 255; en caso contrario, se activará una IllegalArgumentException.

Las valores de ttl recomendados [Harold, 12] son:



  • 0 si la multidifusión está restringida a procesos en la misma máquina

  • 1 si la multidifusión está restringida a procesos en la misma subred

  • 32 si la multidifusión está restringida a procesos en la misma zona

  • 64 si la multidifusión está restringida a procesos en la misma región

  • 128 si la multidifusión está restringida a procesos en el mismo continente

  • 255 si la multidifusión no está restringida

Ejemplo 1 Las Figuras 6.2 y 6.3 ilustran el código de un ejemplo simple de aplicación de multidifusión, que se presenta aquí básicamente para ilustrar la sintaxis del API. Cuando se ejecuta, cada proceso receptor (Figura 6.3) se subscribe al grupo de multidifusión 239.1.2.3 en el puerto 1234 y espera la llegada de un mensaje. El proceso emisor (Figura 6.2), por otro lado, no es un miembro del grupo de multidifusión (aunque podría serlo); dicho proceso manda un único mensaje al grupo de multidifusión 239.1.2.3 en el puerto 1234 antes de cerrar su socket de multidifusión.
Figura 6.2. Ejemplo1Emisor.java.

1 import java.io.*;

2 import java.net.*;

3

4 /**



5 * Este ejemplo ilustra la sintaxis de la multidifusión básica.

6 * @author M. L. Liu

7 */

8 public class Ejemplo1Emisor {



9

10 // Una aplicación que usa un socket de multidifusión para enviar

11 // un único mensaje a un grupo de multidifusión.

12 // El mensaje se especifica como un argumento de línea de mandato.

13

14 public static void main(String[ ] args) {



15 MulticastSocket s;

16 InetAddress grupo;

17 if (args.length != 1)

18 System.out.println

19 ("Este programa requiere un argumento de línea de mandato");

20 else {

21 try {

22 // crea el socket de multidifusión

23 grupo = InetAddress.getByName("239.1.2.3");

24 s = new MulticastSocket(3456);

25 s.setTimeToLive(32); // restringe multidifusión a procesos que

26 // ejecutan en máquinas en la misma zona.

27 String msj = args[0];

28 DatagramPacket paquete =

29 new DatagramPacket(msj.getBytes(), msj.length(),

30 grupo, 3456);

31 s.send(paquete);

32 s.close( );

33 }

34 catch (Exception ex) { // llega aquí si ocurre un error



35 ex.printStackTrace( );

36 } // fin de catch

37 } //fin de else

38 } // fin de main

39 } // fin de class
Figura 6.3 Ejemplo1Receptor.java.

1 import java.io.*;

2 import java.net.*;

3

4



5 /**

6 * Este ejemplo ilustra la sintaxis de la multidifusión básica.

7 * @author M. L. Liu

8 */


9 public class Ejemplo1Receptor {

10

11 // Una aplicación que se une a un grupo de multidifusión y



12 // recibe el único mensaje enviado al grupo.

13 public static void main(String[ ] args) {

14 MulticastSocket s;

15 InetAddress grupo;

16 try {

17 // se une a un grupo de multidifusión y espera recibir un mensaje

18 grupo = InetAddress.getByName("239.1.2.3");

19 s = new MulticastSocket(3456);

20 s.joinGroup(grupo);

21 byte[] almacen = new byte[100];

22 DatagramPacket recibido = new DatagramPacket(almacen, almacen.length);

23 s.receive(recibido);

24 System.out.println(new String(almacen));

25 s.close( );

26 }

27 catch (Exception ex) { // llega aquí si ocurre un error



28 ex.printStackTrace( );

29 } // fin de catch

30 } // fin de main

31 } // fin de class


Ejemplo 2 Como otra ilustración del API de multidifusión de Java, se presenta un ejemplo donde cada proceso de un grupo de multidifusión manda un mensaje, y, de forma independiente, cada proceso también visualiza todos los mensajes que recibe como miembro del grupo de multidifusión.

Ejemplo2EmisorReceptor.java (Figura 6.4) es el código del ejemplo. En el método main se crea un hilo para recibir y visualizar los mensajes (véase la línea 39). Para asegurarse de que cada proceso está listo para recibir, se realiza una pausa (véase las líneas desde la 40 a la 43) antes de que el proceso envíe su mensaje.

Figura 6.4 Ejemplo2EmisorReceptor.java

1 // Este programa ilustra el envío y recepción usando multidifusión

2

3 import java.io.*;



4 import java.net.*;

5 /**


6 * Este ejemplo ilustra el uso de múltiples hilos para enviar y

7 * recibir multidifusión en un proceso.

8 * @author M. L. Liu

9 */


10 public class Ejemplo2EmisorReceptor{

11

12 // Una aplicación que usa un socket de multidifusión para enviar



13 // un único mensaje a un grupo de multidifusión, y utiliza un hilo

14 // independiente que usa otro socket de multidifusión para recibir

15 // mensajes enviados al mismo grupo.

16 // Se requieren tres argumentos de línea de mandato:

17 // ,
,

18

19 public static void main(String[ ] args) {



20

21 InetAddress grupo = null;

22 int puerto = 0;

23 MulticastSocket socket = null;

24 String caracteres;

25 byte[] datos = null;

26

27 if (args.length !=3)



28 System.out.println("Se requieren 3 argumentos de línea de mandato");

29 else {

30 try {

31 grupo = InetAddress.getByName(args[0]);

32 puerto = Integer.parseInt(args[1]);

33 caracteres = args[2];

34 datos = caracteres.getBytes();

35 DatagramPacket paquete =

36 new DatagramPacket(datos, datos.length, grupo, puerto);

37 Thread elHilo =

38 new Thread(new HiloLector(grupo, puerto));

39 elHilo.start();

40 System.out.println("Pulse Intro cuando esté listo para enviar:");

41 InputStreamReader is = new InputStreamReader(System.in);

42 BufferedReader br = new BufferedReader(is);

43 br.readLine();

44 socket = new MulticastSocket(puerto);

45 socket.setTimeToLive(1);

46 socket.send(paquete);

47 socket.close( );

48 }

49 catch (Exception se) {



50 se.printStackTrace( );

51 } // fin de catch

52 } // fin de else

53 } // fin de main

54

55 } // fin de class



Figura 6.5 HiloLector.java.

1 import java.net.*;

2 import java.io.*;

3 /**


4 * Esta clase es utilizada por Ejemplo2EmisorReceptor para

5 * leer mensajes de multidifusión mientras el hilo principal envía

6 * un mensaje de multidifusión. Hace eco en la pantalla de cada

7 * mensaje leído.

8 * @author M. L. Liu

9 */


10 class HiloLector implements Runnable {

11

12 static final int MAX_LON = 30;



13 private InetAddress grupo;

14 private int puerto;

15

16 public HiloLector(InetAddress grupo, int puerto) {



17 this.grupo = grupo ;

18 this.puerto = puerto;

19 }

20

21 public void run( ) {



22

23 try {


24

25 MulticastSocket socket = new MulticastSocket(puerto);

26 socket.joinGroup(grupo);

27 while (true) {

28 byte[ ] datos = new byte[MAX_LON];

29 DatagramPacket paquete =

30 new DatagramPacket(datos, datos.length, grupo, puerto);

31 socket.receive(paquete);

32 String s = new String(paquete.getData());

33 System.out.println(s);

34 } // fin de while

35 } // fin de try

36 catch (Exception exception) {

37 exception.printStackTrace( );

38 } // fin de catch

39 } // fin de run

40

41 } //fin de class


El API de multidifusión de Java y mecanismos similares pueden emplearse para dar soporte a la lógica de servicio de una aplicación. Nótese que una aplicación puede utilizar una combinación de unidifusión y multidifusión para su IPC.

Una aplicación que hace uso de la multidifusión a veces se denomina aplicación consciente de la multidifusión (multicast-aware).

Para los interesados en una sala de chat implementada utilizando multidifusión, consúltese la referencia [Hughes, 7].

6.6El API de multidifusión fiable


El API de multidifusión de Java que se ha explorado en este capítulo es una extensión del API de sockets datagrama. Por ello, comparte una característica fundamental de los datagramas: la entrega no fiable. En particular, no se garantiza que se entreguen los mensajes a los procesos receptores. Por tanto, esta API proporciona una multidifusión no fiable. Sin embargo, el lector debe tener en cuenta a la hora de realizar los ejercicios que, si se ejecutan los procesos en una máquina o en máquinas de una subred, no se observará ninguna pérdida de mensajes o perturbación en el orden de entrega de los mismos. Estas anomalías son más probables cuando las máquinas involucradas están conectadas de forma remota, debido a los fallos en la red o a los retrasos en el encaminamiento.

Como se mencionó previamente, hay aplicaciones para las que la multidifusión no fiable es inaceptable. Para tales aplicaciones, hay un número de paquetes disponibles que proporcionan una API de multidifusión fiable, entre los que se incluyen:



  • El servicio de Multidifusión Fiable de Java (Servicio JRM, Java Reliable Multicast Service) [Rosenzweig, Kandansky y Hanna, 8; Bischof, 9] es un paquete que mejora el API de multidifusión básica de Java proporcionándole la capacidad de que un receptor pueda reparar los datos de multidifusión que se hayan perdido o dañado, así como medidas de seguridad para proteger la privacidad de los datos.

  • El sistema Totem [alpha.ece.ucsb.edu, 10], desarrollado por la universidad de California, en Santa Bárbara, “proporciona una entrega de mensajes fiable y totalmente ordenada para procesos incluidos en grupos de procesos sobre una red de área local, o sobre múltiples redes de área local interconectadas por pasarelas”.

  • El Entorno de Multidifusión Fiable (RMF, Reliable Multicast Framework) de TASC [tascnets.com, 11] proporciona multidifusión fiable y en orden de envío (FIFO).

El uso de estos paquetes queda fuera del ámbito de este libro. Se anima a los lectores interesados a que consulten las referencias para detalles adicionales.

Resumen


Este capítulo proporciona una introducción al uso de la comunicación de grupo en la computación distribuida.

  • La multidifusión difiere de la unidifusión: La unidifusión es una comunicación uno-a-uno, mientras que la multidifusión es una comunicación uno-a-muchos.

  • Una API de multidifusión arquetípica debe proporcionar operaciones para incorporarse a un grupo de multidifusión, abandonar un grupo de multidifusión, enviar a un grupo y recibir los mensajes de multidifusión enviados al grupo.

  • La multidifusión básica es sin conexión y no fiable: en un sistema de multidifusión no fiable, no está garantizado que los mensajes se entreguen sin contratiempos a cada participante.

  • Un sistema de multidifusión fiable asegura que cada mensaje mandado a un grupo de multidifusión se entregue correctamente a cada participante. La multidifusión fiable puede clasificarse a su vez por el orden de entrega de mensajes que proporciona distinguiéndose las siguientes categorías:

    • Multidifusión sin orden, que puede entregar los mensajes a cada participante en cualquier orden.

    • Multidifusión FIFO, que mantiene el orden de los mensajes mandados por cada emisor.

    • Multidifusión causal, que preserva las relaciones causales entre los mensajes.

    • Multidifusión atómica, que entrega los mensajes a cada participante en el mismo orden.

  • La dirección de multidifusión utiliza una combinación de una dirección de clase D y un número de puerto de UDP. Las direcciones IP de clase D las gestiona y asigna IANA. Una aplicación de multidifusión puede utilizar una dirección de clase D estática, una dirección transitoria obtenida en tiempo de ejecución o una dirección arbitraria que no esté asignada.

  • El API de multidifusión básica de Java proporciona una multidifusión no fiable. Se crea un MulticastSocket con la especificación de un número de puerto. Los métodos joinGroup y leaveGroup de la clase MulticastSocket se pueden invocar para unirse o abandonar un grupo de multidifusión específico. Los métodos send y receive se pueden invocar para mandar y recibir un datagrama de multidifusión. Se necesita también la clase DatagramPacket para crear los datagramas.

  • Existen paquetes que proporcionan multidifusión fiable, incluyendo el servicio de Multidifusión Fiable de Java (JRM, Java Reliable Multicast).

Ejercicios


  1. Supóngase que un grupo de multidifusión actualmente tiene dos procesos, P1, y P2, que forman parte del mismo. Suponga que P1 multidifunde m11 y, a continuación, m12; P2 multidifunde m21, y luego m22. Además, suponga que no se pierde ningún mensaje en la entrega.

    1. Teóricamente, ¿en cuántas diferentes ordenaciones pueden entregarse los cuatro mensajes a cada proceso si los mensajes no están relacionados?

    2. Teóricamente, ¿en cuántas diferentes ordenaciones pueden entregarse los cuatro mensajes a cada proceso si los mensajes están relacionados de forma causal de la siguiente manera m11→m12→m21→m22?

    3. ¿Cuáles son los posibles órdenes de entrega de los mensajes a cada proceso si los mensajes no están relacionados y la multidifusión es FIFO, causal y atómica?

    4. ¿Cuáles son los posibles órdenes de entrega de los mensajes a cada proceso si los mensajes están relacionados de forma causal de la siguiente manera m11→m21→m12→m22 y la multidifusión es FIFO, causal y atómica?

  2. Supóngase que tienen lugar los siguientes eventos en orden cronológico en un grupo de multidifusión del que forman parte tres procesos P1, P2, y P3:

P1 multidifunde m1.

P2 responde a m1 mediante la multidifusión de m2.

P3 multidifunde m3 espontáneamente.

P1 responde a m3 mediante la multidifusión de m4.

P3 responde a m2 mediante la multidifusión de m5.

P2 multidifunde m6 espontáneamente.


Para cada una de las siguientes situaciones, especifique en la entrada correspondiente de la tabla que aparece más adelante si el modo de multidifusión permite o no esa situación:

    1. A todos los procesos se les entrega m1, m2, m3, m4, m5, m6, en ese orden.

    2. A P1 y P2 se les entrega m1, m2, m3, m4, m5, m6.

A P3 se le entrega m2, m3, m1, m4, m5, m6.

    1. A P1 se le entrega m1, m2, m5, m3, m4, m6.

A P2 se le entrega m1, m3, m5, m4, m2, m6.

A P3 se le entrega m3, m1, m4, m2, m5, m6.



    1. A P1 se le entrega m1, m2, m3, m4, m5, m6.

A P2 se le entrega m1, m4, m2, m3, m6, m5.

A P3 se le entrega m1, m3, m6, m4, m2, m5.



    1. A P1 se le entrega m1, m2, m3, m4, m5, m6.

A P2 se le entrega m1, m3, m2, m5, m4, m6.

A P3 se le entrega m1, m2, m6, m5, m3, m4.



    1. A P1 se le entrega m2, m1, m6.

A P2 se le entrega m1, m2, m6.

A P3 se le entrega m6, m2, m1.




Situación

Multidifusión fiable

Multidifusión FIFO

Multidifusión causal

Multidifusión atómica

a













b













c













d













e













f













g















  1. Este ejercicio se basa en Ejemplo1 presentado en este capítulo.

    1. Compile los programas Ejemplo1*.java. A continuación, ejecútelos en cada una de las siguientes secuencias. Describa y explique cada una de las salidas resultantes:

      1. Arranque primero dos o más procesos receptores, después un proceso emisor con el mensaje que se desee.

      2. Arranque primero un proceso emisor con el mensaje que se desee, después dos o más procesos receptores.

    2. Basado en el Ejemplo1Receptor.java, cree un programa, Ejemplo1Receptora.java, que se una a un grupo de multidifusión con una dirección IP diferente (por ejemplo, 239.1.2.4) pero con el mismo puerto. Compile Ejemplo1aReceptor.java. Arranque primero dos o más procesos Ejemplo1Receptor, a continuación, un proceso Ejemplo1aReceptor y, por último, un proceso emisor con el mensaje que se desee. ¿Recibe el proceso Ejemplo1aReceptor el mensaje? Describa y explique la salida.

    3. Basado en el Ejemplo1Receptor.java, cree un programa, Ejemplo1bReceptor.java, que se una a un grupo de multidifusión con la misma dirección IP pero con un puerto diferente. Compile Ejemplo1bReceptor.java. Arranque primero dos o más procesos Ejemplo1Receptor, luego, un proceso Ejemplo1bReceptor y, por último, un proceso emisor con el mensaje que se desee. ¿Recibe el proceso Ejemplo1bReceptor el mensaje? Describa y explique la salida.

    4. Basado en el Ejemplo1Emisor.java, cree un programa, EmisorEjemplo1Receptor.java, que se una al grupo de multidifusión, mande un mensaje, y después espere (reciba) un mensaje de multidifusión antes de cerrar el socket de multidifusión y terminar. Compile el programa y, a continuación, arranque dos o más programas receptores antes de comenzar el proceso EmisorReceptor. Describa la salida. Entregue el listado de EmisorReceptor.java.

    5. Basado en Ejemplo1Emisor.java, cree un programa, Ejemplo1bEmisor.java, que mande un mensaje a la dirección de multidifusión del programa Ejemplo1bReceptor.java. Compile el programa, y luego arranque un proceso Ejemplo1Receptor, un proceso Ejemplo1bReceptor, un proceso Ejemplo1Emisor y, por último, un proceso Ejemplo1bEmisor. Describa y explique el mensaje o los mensajes recibidos por cada proceso.

    6. Basado en Ejemplo1Receptor.java y Ejemplo1bReceptor.java, cree un programa, Ejemplo1cReceptor.java, que utilice dos hilos (incluyendo el hilo principal). Cada hilo se debe unir a uno de los dos grupos de multidifusión y recibir, y después visualizar, un mensaje antes de abandonar el grupo. Puede resultar útil el ejemplo HiloLector.java.

Compile y ejecute Ejemplo1cReceptor.java, y después arranque un proceso Ejemplo1bEmisor. ¿El proceso receptor visualiza ambos mensajes? Entregue el listado del programa Ejemplo1cReceptor.java y su clase que define el hilo de ejecución.


  1. Este ejercicio se basa en Ejemplo2 presentado en este capítulo.

    1. Compile Ejemplo2EmisorReceptor.java, y luego arranque dos o más procesos del programa, especificando para cada uno un mensaje diferente. Un ejemplo de los mandatos necesarios para ello es:

java Ejemplo2EmisorReceptor 239.1.2.3 1234 msj1

java Ejemplo2EmisorReceptor 239.1.2.3 1234 msj2

java Ejemplo2EmisorReceptor 239.1.2.3 1234 msj3


En este ejemplo, cada uno de los tres procesos visualizaría en la pantalla los mensajes msj1, msj2 y msj3. Asegúrese de arrancar todos los procesos antes de permitir que cada uno mande su mensaje. Describa las salidas resultantes.

    1. Modifique Ejemplo2EmisorReceptor.java de manera que cada proceso mande su mensaje diez veces. Compile y ejecute. Describa las salidas resultantes y entregue los listados de programas.

  1. Escriba su propia aplicación de multidifusión. Desarrolle una aplicación de manera que múltiples procesos utilicen comunicación de grupo para llevar a cabo una elección. Hay dos candidatos: Sánchez y Pérez. Cada proceso mutidifunde su voto en un mensaje que le identifica a sí mismo y su voto. Cada proceso lleva la cuenta de cuántos votos tiene cada candidato, incluyendo el propio. Al final de la elección (cuando todo el mundo en el grupo ha votado), cada proceso hace el recuento de votos de forma independiente y visualiza la salida en su pantalla (por ejemplo, Sánchez 10, Pérez 5). Entregue el listado de la aplicación y responda a estas preguntas:

    1. ¿De qué manera su diseño permite a los participantes unirse a un grupo de multidifusión?

    2. ¿Cómo se sincroniza en su diseño el principio de la elección de manera que cada proceso esté listo para recibir cualquier difusión de voto por parte de un miembro del grupo?

    3. Al ejecutar la aplicación, ¿han coincidido los recuentos de votos en todas las máquinas? ¿Puede asumir que los recuentos siempre coincidirán en todas las máquinas? Explíquelo.

Referencias


  1. Java 2 Platform SE v1.3.1: Clase MulticastSocket, http://java.sun.com/j2se/1.3/docs/api/java/net/MulticastSocket.html

  2. Direcciones de multidifusión de IANA, http://www.iana.org/assignments/multicast-addresses

  3. RFC 3171, IANA Guidelines for IPv4 Multicast Address Allocation, http://www.rfc-editor.org/rfc/rfc3171.txt

  4. RFC 2375-IPv6 Multicast Address Assignments, http://www.faqs.org/rfcs/rfc2375.html

  5. Cisco-Multicast Routing, http://www.cisco.com/warp/public/614/17.html

  6. RFC 2974-Session Announcement Protocol, http://www.faqs.org/rfcs/rfc2974.html

  7. Merlin Hughes, Multicast the Chatwaves - JavaWorld, Octubre 1999, http://www.javaworld.com/javaworld/jw-10-1999/jw-10-step_p.html

  8. Phil Rosenzweig, Miriam Kadansky y Steve Hanna, The Java Reliable Multicast Service: A Reliable Multicast Library, http://www.sun.com/research/techrep/1998/smli_tr-98-68.pdf

  9. Hans-Peter Bischof, JRMS Tutorial, Department of Computer Science, Rochester Institute of Technology, http://www.cs.rit.edu/~hpb/JRMS/Tutorial/

  10. Robust Distributed Systems for Real-Time Applications, http://alpha.ece.ucsb.edu/project_totem.html

  11. Reliable Multicast Framework (RMF), http://www.tascnets.com/newtascnets/Software/RMF/, Litton TASC.

  12. Elliotte Rusty Harold, Java Network Programming, Sebastopol, CA: O'Reilly Press, 2000.

Corresponde con el texto lateral en la página 184. Va anclado al primer párrafo.


La replicación de un servicio consiste en mantener duplicados de ese servicio. Una técnica común para mejorar la disponibilidad de un servicio ante la presencia de fallos es duplicar los datos y los sistemas que proporcionan ese servicio.
Corresponde con el texto lateral en la página 184. Va anclado al primer párrafo.
La tolerancia de fallos se refiere a la capacidad que tiene una aplicación para tolerar fallos hasta cierto punto.
Corresponde con el texto lateral en la página 185. Va anclado al segundo párrafo.
La latencia se refiere al retraso o demora en la transmisión de datos.



La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal