Llamadas a Procedimientos Remotos (RPC) Basado en el libro Internetworking with TCP/IP. Vol III. D. E Comer y D. Stevens Algunas Ilustraciones se tomaron de Practical Unix Programming. K. Robbins y Robbins 1 Comer & Stevens M. Curiel Conceptos 2 Comer & Stevens M. Curiel Modelos de Programación 3 Llamada a procedimientos remotos: permite a los programas cliente llamar a procedimientos que se encuentran en programas servidores. Modelo de programación basado en objetos: objetos manipulados por diferentes procesos, se comunican utilizando RMI Comer & Stevens M. Curiel 1 Modelos de Programación Modelo de Programación basado en eventos: permite a los objetos recibir notificaciones de eventos que ocurren en otros objetos; se reciben notificaciones de los eventos en los que se ha manifestado interés. 4 Comer & Stevens M. Curiel Programadores de Sistema Diseño orientado a comunicaciones Se comienza con el protocolo Se diseña el formato de los mensajes y cómo el cliente y el servidor reaccionan y responden a los mensajes Diseño orientado a la aplicación 5 Se diseña una aplicación para resolver el problema. Se hacen pruebas en una sola máquina Se divide el programa en varias piezas que se ejecutarán en distintos computadores y se añade el protocolo. Comer & Stevens M. Curiel Modelo Conceptual Subrutinas Espacio Usuario main func() proc1 proc2 func(void ){ proc3 } proc5 proc6 Thread de ejecución 6 Comer & Stevens M. Curiel 2 Espacio usuario Llamadas al Sistema Programa usuario retorno llamada Espacio Usuario Función de librería Espacio del Kernel sys_func(void ){ sys_func() trap Retorno del trap } System call Thread de ejecución Espacio del kernel Thread bloqueado Trap-return 7 Comer & Stevens Programa Distribuido Computador1 main Computador2 M. Curiel Comp. local Comp. remoto Cliente Funciones del Servidor func() func(void ){ } proc1 proc2 proc4 proc3 proc5 Thread de ejecución Thread bloqueado Llamada a proc. remota 8 Comer & Stevens M. Curiel RPC (Remote Procedure Call) 9 Es una técnica poderosa para el desarrollo de aplicaciones distribuidas, basadas en el paradigma cliente/servidor. Extiende la noción de llamadas a procedimientos locales, de forma tal que el procedimiento llamado no tiene que estar en la misma máquina donde reside el llamador. Comer & Stevens M. Curiel 3 RPC y Procedimientos Locales 10 En RPC se transfiere el control al procedimiento llamado. El llamador se suspende. La respuesta del servidor es análoga al return(). El flujo de control vuelve al llamador y el llamado deja de ejecutarse. Existen llamadas anidadas: un procedimiento remoto puede llamar a otro. El Servidor se convierte en cliente de otro servicio. Comer & Stevens M. Curiel RPC y Procedimientos Locales (cont.) 11 RPCs pueden ser varios ordenes de magnitud más lentas que una llamada local. Se pueden pasar apuntadores como argumentos de procedimientos locales. Un procedimiento remoto opera en un espacio de direcciones distinto. No se pueden pasar apuntadores. Comer & Stevens M. Curiel RPC y Procedimientos Locales (cont.) 12 El procedimiento remoto no comparte el ambiente del llamador. No tiene acceso directo a los descriptores de archivo o a las funciones del SOP. Comer & Stevens M. Curiel 4 Proceso en el Servidor Proceso en el Cliente Cliente llamada Remota Funciones del Serv. retorno Llamada y retorno lógico Req. Marshaled Retorno Marshaled Servicios de red Req. Marshaled Red kernel del cliente 13 retorno llamada Stub del Servidor Stub del Cliente Retorno Marshaled Servicios de red Kernel del servidor Comer & Stevens M. Curiel Implementación 14 El Cliente se compila con un Stub (resguardo). El Stub es la envoltura: modifica los argumentos (marshaling) y los ensambla en un mensaje que es apropiado para la transmisión en la red. El formato estándar para este lenguaje independiente de la máquina se llama XDR (eXternal Data representation) Comer & Stevens M. Curiel Implementación 15 El stub hace un trap al sistema operativo invocando las operaciones de red y se queda esperando la respuesta del servidor. Las funciones a ser ejecutadas remotamente también se compilan con un código adicional: El stub del servidor. Comer & Stevens M. Curiel 5 Implementación El stub del servidor hace unmarshaling (desenpaquetamiento) de los datos y llama al procedimiento “verdadero” del lado del servidor. Hace marshaling del valor de retorno en un paquete o mensaje apropiado y hace una llamada al sistema para enviar el mensaje. En SunRPC existe el rpcgen que genera a partir de las especificaciones del usuario los resguardos o stubs. 16 Comer & Stevens Proceso en el Servidor Proceso en el Cliente Cliente llamada Remota Funciones del Serv. retorno Llamada y retorno lógico Retorno Marshaled Servicios de red Req. Marshaled Red kernel del cliente 17 retorno llamada Stub del Servidor Stub del Cliente Req. Marshaled M. Curiel Retorno Marshaled Servicios de red Kernel del servidor Comer & Stevens M. Curiel Marshaling Para transferir los argumentos entre computadoras éstos deben representarse con un formato externo. Las listas, por ejemplo, deben colocarse en una representación compacta. Los siguientes términos se usan para denotar la tarea de codificar argumentos: marshal, linearize, serialize 18 Comer & Stevens M. Curiel 6 Representación Externa y Empaquetado 19 La información en los programas se almacena en estructuras de datos, mientras que la información se transporta en secuencias de bytes. Las estructuras de datos deben ser aplanadas (convertidas en secuencias de bytes) antes de su transmisión. Posteriormente se reconstruyen en el destino. Comer & Stevens M. Curiel Representación Externa y Empaquetado 20 Los tipos de datos primitivos,tales como los enteros, se almacenan en distintos orden en los computadores: bigendian y little-endian. Comer & Stevens M. Curiel Representación Externa y Empaquetado 21 También puede ser diferente la representación de números en coma flotante. Algunos computadores utilizan la codificación ascii (un byte por caracter), mientras que otros utilizan el estándar Unicode: permite representar textos en la mayoría de los lenguajes y utiliza dos bytes por carácter. Comer & Stevens M. Curiel 7 Representación Externa y Empaquetado Para hacer posible que dos computadores puedan intercambiar datos se pueden utilizar dos métodos: Los valores se convierten en un formato externo acordado antes de la transmisión y se revierten al formato local en la recepción. Los valores se transmiten según el formato del emisor, junto con una indicación del formato utilizado, y el receptor los convierte si es necesario. 22 Comer & Stevens M. Curiel Representación Externa y Empaquetado Al estándar acordado para la representación de estructuras de datos y valores primitivos se le denomina XDR (external data representation). El empaquetado (marshalling) consiste en tomar una colección de ítems de datos y ensamblarlos de un modo adecuado (representación externa) para la transmisión de un mensaje. 23 Comer & Stevens M. Curiel Representación Externa y Empaquetado El desempaquetado (unmarshalling): es el proceso de desensamblado en el destino para producir una colección equivalente de datos. Ejemplos de representación externa de datos: 24 La representación común de datos de CORBA. Puede ser usada por una gran variedad de lenguajes de programacion. La serialización de objetos en JAVA (aplanado de objetos o jerarquias de objetos). Es de uso exclusivo de Java. Comer & Stevens M. Curiel 8 Representación Externa y Empaquetado El desempaquetado y desempaquetado se llevan a cabo en el middleware sin participación del programador. Los datos primitivos se pueden empaquetar en forma binaria o en ascii (el mensaje es más grande). 25 Comer & Stevens M. Curiel SUN RPC: Definición Se creo en 1995 para la comunicación Cliente/Servidor en el Sistema de Archivos de Red: NFS. Proporciona un lenguaje de interfaz llamado XDR y un compilador de interfaz llamado rpcgen. 26 Comer & Stevens M. Curiel Comer & Stevens M. Curiel XDR 27 9 SUN RPC: Definición Permite al programador usar TCP (confiable) o UDP (eficiente, pero las solicitudes se pueden perder) 28 Comer & Stevens M. Curiel Programas remotos Un programa remoto es la unidad básica de software que se ejecuta en un computador remoto. Equivale al servidor. Se compone de un conjunto de procedimientos y datos globales proc1 proc2 proc3 Datos Globales Compartidos 29 Comer & Stevens M. Curiel Programas remotos 30 Argumentos: Sólo se permite un parámetro de entrada. De modo que los procedimientos que requieran varios parámetros deben incluirlos como componentes de una estructura (struct de C). Comer & Stevens M. Curiel 10 Programas remotos Identificación: A cada programa se le asigna un identificador de 32 bits A cada procedimiento se le asigna un número entero: 1,2,..N. También se incluye un número de versión. (prog,vers, proc) La firma del procedimiento incluye: tipo de resultado, tipo de parámetros de entrada y nombre del procedimiento. 31 Comer & Stevens M. Curiel /* rand.x */ Struct randpack { double pseudo; unsigned short xi[3]; } Program RAND_PROG { version RAND_VERS { randpack INITIALIZE_RANDOM(long) = 1; randpack GET_NEXT-RANDOM (randpack) = 2; } = 2; } = 0x31111111 32 Comer & Stevens M. Curiel Programas remotos Exclusión Mutua: 33 Como máximo se puede invocar un procedimiento en un programa remoto (exclusión mutua entre procedimientos) Comer & Stevens M. Curiel 11 Programas remotos Al menos una vez Si una llamada a procedimiento remota retorna, el llamador puede concluir que el procedimiento se invocó al menos una vez. Cero o más veces: Si una llamada a proc. remota no retorna, éste pudo haber sido invocado cero o más veces. Cada llamada a procedimiento debe ser idempotente. 34 Comer & Stevens M. Curiel Programas remotos Retransmisiones: Existe una estrategia de retransmisión sencilla basada en timeouts. Los timeouts no se adaptan a las condiciones de la red. El software en la máquina del llamador puede, después de varios intentos, declarar que el procedimiento remoto no se pudo ejecutar. Esto no garantiza que nunca se ejecutó. 35 Comer & Stevens M. Curiel ¨Mapping¨ entre un programa remoto y un puerto 36 Para hacer posible la comunicación, a cada servicio se le asigna un número de puerto que conocen todos los clientes. Programas RPC (32 bits), puertos (16 bits). Los programas remotos obtienen puertos dinámicamente. Las asignaciones son temporales. El servidor, cuando inicia su ejecución, pregunta al sistema por un puerto. El sistema puede elegir cada vez un número de puerto diferente. Comer & Stevens M. Curiel 12 ¨Mapping¨ entre un programa remoto y un puerto Al no conocer el puerto, el cliente no puede contactar al servidor directamente. El cliente sólo conoce el host y el número de programa. Debe ser capaz de obtener el puerto asignado al servidor. El ¨mapping¨ o asociación se debe hacer de forma dinámica. 37 Comer & Stevens M. Curiel ¨Mapping¨ entre un programa remoto y un puerto Cada máquina que ofrece un programa RPC con un mecanismo que permite al cliente obtener el número de puerto del servidor: port mapper. Server: Programa RPC Server registra (programa, puerto) Puerto que Usa el servidor remoto 38 Port Mapper Puerto bien conocido Comer & Stevens M. Curiel ¨Mapping¨ entre un programa remoto y un puerto Cuando un servidor RPC comienza a ejecutarse, solicita un puerto del sistema que usa para sus comunicaciones El servidor contacta al port mapper para añadir la siguiente información a la BD: (Nro. Programa, puerto) Ahora los ¨llamadores¨ pueden saber el puerto del servidor enviando un mensaje al port mapper al puerto 111. Al saber el puerto el cliente puede contactar 39 directamente al servidor. Comer & Stevens M. Curiel 13 Problemas Los clientes o servidores pueden fallar (No hay garantías especialmente si se usa UDP). No es posible saber si la falta de una respuesta es debido a la red o a una falla en el servidor. Posibilidades cuando no se recibe una respuesta: La petición se perdió en la red. El servidor recibe la petición y la sirve, pero la respuesta se pierde. El servidor está down 40 Comer & Stevens M. Curiel Problemas 41 Si se pierde la petición inicial el cliente puede re-enviarla sin efectos adversos. Si el servidor hizo el requerimiento pero se perdió la respuesta. Cada vez que se repita el requerimiento se pueden generar resultados incorrectos. Comer & Stevens M. Curiel La siguiente rutina write_file escribe nbytes en buf al archivo Cuyo file descriptor es fd. La función retorna el número de bytes Escritos en la operación. El offset se mantiene en el server. int write_file (int fd, char *buf, int nbytes) { return put_block(fd, nbytes,buf) } 42 Comer & Stevens M. Curiel 14 Solución 1 Versión idempotente int put_block(int file, int offset, int count, char *data) { int returncode = 0; if (lseek(file, Offset, SEEK_SET) == -1) returncode = -1 else returncode = write(file, data, count) return returncode } No soluciona el problema si se cae el servidor 43 Comer & Stevens M. Curiel Por otro lado, si se cae el Cliente los archivos abiertos en el servidor no se cierran automáticamente. El servidor no deberá tener estado: stateless int put_block(char *fname, int offset, int count, char *data) { int returncode = 0; int file; if ((file = open(fname, O_WRONLY|O_CREAT, 0600) == -1) returncode = -1 if (lseek(file, Offset, SEEK_SET) == -1) returncode = -1 else returncode = write(file, data, count) close(file) return returncode } 44 Comer & Stevens M. Curiel Generación de Programas Distribuidos: RPCGEN 45 Comer & Stevens M. Curiel 15 Mecanismos de programación Sun RPC ofrece: Rutinas para convertir datos simples y complejos al formato XDR Rutinas de librería para llamar un procedimiento remoto, registrar un servicio con el port_mapper, conducir una llamada al procedimiento adecuado dentro del prog. remoto. Una herramienta que produce programas fuentes en C. 46 Comer & Stevens M. Curiel XDR (Interface Description Language) Similar a declaraciones en C, pero… son lenguajes diferentes Se ofrecen los tipos básicos: int, short,char long. Números de doble precisión (float, double). El tipo void. Se da el soporte para tipos definidos por el usuario: typedef, structs, unions, arrays, tipos enumerados Se definen tipos extra: bool, string 47 Comer & Stevens M. Curiel XDR Enum Priority { PRIO_LOW = 1; PRIO_MED = 1; PRIO_HIGH = 1; }; Struct alarm { Priority prio; string text<>; /* string de tamaño variable */ } Unions Enum ReturnType { RESULT_NAME = 1; RESULT_CODE = 2; }; Union Result switch(Return type){ case RESULT_NAME: string name<>; case RESULT_CODE: int code; default: void; }; rpcgen –h –N test.x > test.h 48 Comer & Stevens M. Curiel 16 XDR Listas Especificación de los programas struct List { List* next; string data<>; }; typedef List* ListPtr; Program PROG { version PROG1 { void PROG_PROC1(int a) void PROG_PROC2(string } = 1; version PROG2 { Program RPCDEMO { void PROG_PROC1(int a, version RPCDEMO_VERS_ORIG { void PROG_PROC2(string void RPCDEMO_PRINT(ListaPtr lp) } = 2; = 1; } = 1; } = 600000; } = 600000; 49 = 1; str<>) = 2; int b) = 1; str<>) = 2; Comer & Stevens M. Curiel Rutinas de Librería Enviar un mensaje a un servidor: clientrpc(host,prog, progver, procnum, inproc, in , outproc, out) inproc: progrma que hace el marshaling de los argumentos a enviar. in: dirección de los argumentos outproc: procedimiento local para hacer unmarshaling de los resultados. out:dirección en memoria donde se quedan los resultados. 50 Comer & Stevens M. Curiel Rutinas de Librería Handle = cln_create (host,prog, ver, proto) Crea un identificador que puede usarse para enviar mensajes RPC. host, prog y ver: host, programa y versión. proto: protocolo 51 Comer & Stevens M. Curiel 17 RPCGEN Genera código para el cliente y el servidor útil para: Empaquetar los argumentos (marshaling) Enviar un mensaje RPC Conducir (dispatch) una solicitud del cliente al procedimiento adecuado. Enviar un reply Desempaquetar los argumentos 52 Comer & Stevens M. Curiel Programación Distribuida Los argumentos deben coincidir con los parámetros formales. Hay que añadir código: los procedimientos adicionales se llaman Stubs. En el cliente, el stub reemplaza al procedimiento llamado. En el servidor, reemplaza al llamador. 53 Comer & Stevens M. Curiel Proc. B Proc. A Llamada remota Stub del Cliente Proc. A1 Proc. A2 Stub C. B2 Llamada remota Stub C. B1 54 Stub del Servidor Proc. B1 Proc. B2 Stub S. B1 Stub S. B2 Dispatcher Comer & Stevens M. Curiel 18 Proceso en el Servidor Proceso en el Cliente Funciones del Serv. Cliente retorno llamada Remota Infaz. servidor Stub del Cliente Comm. servidor Comm. Cliente Req. Marshaled Retorno Marshaled Req. Marshaled RPC Retorno Marshaled Servicios de red Servicios de red Kernel del servidor kernel del cliente 55 retorno llamada Infaz. cliente Comer & Stevens M. Curiel rdict.c Archivos rdict_cif.c Aplic. Cliente Cliente Iface rdict Comp. C rdict_clnt.c Cliente rdict.h rdict.x Especificación del programa rpcgen rdict_xdr.h rdictd Comp. C rdict_svc.h Proc. remotos rdict_srp.c 56 Comer & Stevens Server Iface Servidor Rdict_sif.c M. Curiel Archivos de Salida rdict.h = declaraciones de constantes y tipos rdict_xdr.h = rutinas XDR para codificar los argumentos rdict_clnt.c = Stub de comunicaciones del lado del cliente rdict_svc.c = Stub de comunicaciones del lado del servidor 57 Comer & Stevens M. Curiel 19 Pasos para el desarrollo de una aplicación distribuida Desarrolle y pruebe una aplicación convencional Elija un conjunto de procedimientos para colocarlos en una máquina remota. Colóquelos en un archivo separado. Escriba la especificación para rpcgen y ejecute rpcgen Escriba las interfaces para cliente y servidor Genere el ejecutable del cliente: aplicación, stubs, rutinas XDR Genere el ejecutable del servidor: stubs, procedimientos, rutinas XDR. Ejecute el servidor en una máquina remota. Ejecute el cliente. 58 Comer & Stevens M. Curiel main nextin insertw lookupw initw deletew Programa remoto en Comp2 Cliente en Comp1 initw main insertw deletew nextin Estructura de datos del diccionario lookupw 59 Comer & Stevens M. Curiel Comunicación en Grupo 60 Involucra múltiples procesos. Un Grupo es una colección de procesos que trabajan juntos. Cuando un mensaje se envía al grupo, lo deben recibir todos sus miembros. Es un tipo de comunicación uno-a-muchos en contraste con la comunicación puntopunto. Comer & Stevens M. Curiel 20 Comunicación en Grupo r r s r r s r r r Punto-punto Uno-a-muchos 61 Comer & Stevens M. Curiel Comunicación en Grupo 62 Los grupos son dinámicos: se pueden crear y destruir. Un proceso se puede unir a un grupo o puede dejar un grupo. Un proceso puede ser miembro de varios grupos a la vez. Se necesitan mecanismos para manejar grupos y la membresía a los grupos. Comer & Stevens M. Curiel Comunicación en Grupo 63 El propósito de los grupos es manejar una colección de procesos como una abstracción. Un proceso puede enviar un mensaje a un grupo de servidores sin conocer cuántos son o dónde están. Comer & Stevens M. Curiel 21 Comunicación en Grupo Multicast: se crea una dirección especial de red en la cual pueden escuchar múltiples máquinas. Cuando un paquete se envía a esta dirección, se entrega a todas las máquinas escuchando por la misma. Broadcast: los paquetes que contienen cierta dirección especial se envían a todas las máquinas. El software debe chequear si se está o no interesado en el mensaje. 64 Comer & Stevens M. Curiel Comunicación en Grupo Unicast: El emisor transmite paquetes separados a cada uno de los miembros del grupo. 65 Comer & Stevens M. Curiel Comunicación en Grupo Grupos abiertos y cerrados Los servidores están en el grupo y los Clientes no. Grupo Abierto No es miembro del grupo Grupo Cerrado 66 Se usan en procesamiento paralelo Comer & Stevens Está permitido M. Curiel 22 Comunicación en Grupo Grupos de pares vs grupos jerárquicos Grupo Jerárquico Grupo de pares 67 Comer & Stevens M. Curiel Comunicación en Grupo Grupos de Pares: Simétrico La toma de decisiones es compleja No hay un único punto de falla Grupos Jerárquicos Asimétrico La toma de decisiones es sencilla Hay un único punto de fallos: El Coordinador 68 Comer & Stevens M. Curiel Comunicación en Grupo Membresía al Grupo Se necesitan métodos para crear y eliminar grupos, y para que los procesos se incorporen o salgan de un grupo. Soluciones: 69 Un servidor de grupo: enfoque centralizado Enfoque distribuido: En un grupo abierto, alguien que desee entrar le envía un mensaje a todos anunciando su presencia. Un grupo cerrado debe ser abierto para permitir un nuevo miembro. Para dejar un grupo, un miembro envía un mensaje de despedida a todos los integrantes. Comer & Stevens M. Curiel 23 Comunicación en Grupo Membresía al Grupo Enfoque distribuido: si un miembro deja de funcionar no hay forma de comunicar este abandono. Debe descubrirse experimentalmente. Qué hacer con los miembros si muchas máquinas se caen y el grupo no puede funcionar. Se requiere un protocolo para reconstruir el grupo. Quién toma la iniciativa?? El protocolo debe poder resolver esto. 70 Comer & Stevens M. Curiel Comunicación en Grupo Direccionamiento Multicast: la dirección del grupo puede ser la misma dirección de multicast. El mensaje se envía sólo a aquellas máquinas que esperan recibirlo y no a otras. Broadcast: El kernel tiene que interpretar la dirección y si ningún proceso en la máquina es miembro del grupo, el mensaje se borra. 0 0 1 2 3 4 1 2 3 4 x 71 Comer & Stevens M. Curiel Comunicación en Grupo Direccionamiento Unicast: el kernel de la máquina emisora deberá tener la lista de máquinas que tienen procesos receptores del mensaje. 0 1 2 3 4 Otro método de direccionamiento es que el emisor provea En la llamada la lista de direcciones IP destino. 72 Comer & Stevens M. Curiel 24 Comunicación en Grupo Primitivas: send, receive, group-send, groupreceive, broadcast, multicast, gather, scatter, etc. Atomicidad: se envía un mensaje a los miembros del grupo y lo reciben todos o no lo recibe ninguno. 73 Comer & Stevens M. Curiel Comunicación en Grupo - Algoritmo simple: El emisor envía un mensaje a todos los miembros. Se inicializan timers para hacer retransmisiones. Cuando un proceso recibe un mensaje, si no lo ha visto, lo retransmite al resto del grupo; si ya lo ha visto, lo ignora. 74 Comer & Stevens M. Curiel Comunicación en Grupo M1: x= 4 M2= x=x+1 Orden: p1 m1 m2 p1 p2 p2 p3 p3 m1 m2 - Global time ordering: entregar todos los mensajes en el mismo orden en el que fueron emitidos - Consistent time order: Si dos mensajes A y B, fueron emitidos en instantes muy cercanos en el tiempo, el sistema elige uno de ellos Como primero y lo entrega a todo el grupo, seguido del otro mensaje. Todos los miembros del grupo reciban el mensaje en el mismo orden aunque no sea el orden real en el que se enviaron. 75 Comer & Stevens M. Curiel 25 Comunicación en Grupo Multidifusión IP: una implementación de la comunicación en grupo. Se construye sobre el protocolo IP. Permite que el emisor transmita un único paquete IP a un conjunto de computadoras que forman un grupo de multidifusión. El emisor no tiene que estar al tanto de las entidades de los receptores individuales o del tamaño del grupo. 76 Comer & Stevens M. Curiel Comunicación en Grupo Multidifusión IP: una implementación de la comunicación en grupo. Los grupos de multidifusión se especifican utilizando las direcciones de internet de la clase D: una dirección donde los primeros 4 bits son 1110. La pertenencia a los grupos de multidifusión es dinámica: los computadores se pueden añadir y borrar a un número arbitrario de grupos en cualquier instante. Son grupos abiertos. 77 Comer & Stevens M. Curiel Comunicación en Grupo Multidifusión IP: una implementación de la comunicación en grupo. La multidifusión sólo es accesible a través de UDP. Un computador pertenece a un grupo de multidifusión cuando uno o más de sus procesos tienen conectores que pertenecen al grupo. Cuando llega el mensaje de multidifusión el computador los reparte a los procesos adecuados. 78 Comer & Stevens M. Curiel 26 Comunicación en Grupo Multidifusión IP: una implementación de la comunicación en grupo. Los paquetes IP pueden multidifundirse tanto en la red local como en toda Internet. La multidifusión dirigida a internet hace uso de las posibilidades de multidifusión de los routers. Las direcciones de multidifusión se pueden reservar en forma temporal o permanente. Existen grupos permanentes incluso cuando no tienen ningún miembro. 79 Comer & Stevens M. Curiel Comunicación en Grupo Los mensajes de multidifusión proporcionan una infraestructura para construir SD con las siguientes características: Tolerancia a fallos basada en servicios replicados. Búsqueda de servidores. Mejores prestaciones basada en datos replicados. Propagación de notificaciones de los eventos. 80 Comer & Stevens M. Curiel Comunicación en Grupo Multidifusión IP: Fiabilidad y orden Cualquiera de los receptores destinatiorios del datagrama puede perderlo (buffer lleno) También se puede perder un datagrama de un router de multidifusión a otro. Una sub-red completa perdería el mensaje. 81 Comer & Stevens M. Curiel 27 Comunicación en Grupo Multidifusión IP: Fiabilidad y orden Si falla un router de multidifusión, los miembros del otro lado del router no recibirán el mensaje. Los paquetes enviados no llegan necesariamente en el orden que fueron enviados. 82 Comer & Stevens M. Curiel import java.net.* Import java.io.* Public class participanteMultidifusion { public static void main(String arg[]){ try { InetAddress grupo = InetAddress. getByName(args[1]); MulticastSocket s = new MulticastSocket(6789); s.joinGrupo(grupo); byte [] m = args[0].getBytes(); DatagramPacket mensajeSalida = new DatagramPacket(m, m.length, grupo, 67899); s.send(MensajeSalida); byte [] buffer = new byte [1000]; 83 Comer & Stevens M. Curiel for (int i = 0; i < 3; i++) { DatagramPacket mensajeEntrada = new DatagramPacket(buffer, buffer.length); s.receive(mensajeEntrada); System.out.printl(“Recibido:” + new String(mensajeEntrada.getData)); } s.leaveGroup(grupo); } catch(SocketException e) {System.out.printl(…)} } catch(IOException e) {…} } } 84 Comer & Stevens M. Curiel 28