Aplicaciones Peer-to-peer Cc50h 2005. Carácterísticas No hay servidor central Cada aplicación se comporta como cliente y servidor de las demás Son exceltentes.

Presentación del tema: "Aplicaciones Peer-to-peer Cc50h 2005. Carácterísticas No hay servidor central Cada aplicación se comporta como cliente y servidor de las demás Son exceltentes."— Transcripción de la presentación:

1 Aplicaciones Peer-to-peer Cc50h 2005

2 Carácterísticas No hay servidor central Cada aplicación se comporta como cliente y servidor de las demás Son exceltentes para situaciones donde se tienen sesiones “colaborativas” donde entran y salen participantes con frecuencia Muchas veces basadas en multicast

3 Ejemplo: Un Chat basado en Multicast No hay servidor. Cada participante corre el mismo programa uniéndose al grupo multicast Los mensajes salen como datagramas “multicast” a la red, por lo cual cualquier aplicación interesada lo recibirá No hay garantía de si llegará, en cuanto rato, en qué órden ni si se duplicarán ! MulticastChat

4 Modelo de Multicast para grupos Multicast tiene cualidades que lo hacen más eficiente para transmitir un mensaje a varios miembros de un grupo Modelo: message(g,m) : operación de transmisión de un mensaje m a los miembros de un grupo g deliver(m) : operación de proceso de mensaje m sender(m) : identificación del que manda el mensaje group(m) : grupo de destino del mensaje open/closed group : el grupo puede/no puede recibir mensajes mandados por un por un miembro que no pertenece al grupo

5 Reliable Multicast Reliable multicast implica que se cumplen 3 propiedades: Integridad: el mensaje que se manda es igual al que se procesa y que ningún mensaje es procesado dos veces. Un proceso p hace la operación deliver(m) una sola vez y p  group(m) Validez : si un proceso manda un mensaje multicast, tarde o temprano él también lo procesará si pertenece al grupo Agreement : si un proceso procesa un mensaje m el resto de los miembros del grupo también lo hará

6 Reliable Multicast con IP ! Cada proceso p mantiene un número de secuencia S(p,g) para cada grupo g al que pertenece. También mantiene un registro R(q,g) que es el número de secuencia del último mensaje procesado del proceso q que mandó al grupo g. Cuando p quiere mandar un mensaje a g incluye el número S(p,g) y pares, luego incrementa S(p,g). Un proceso del grupo procesa el mensaje mandado por p sólo si el S = R(p,g) +1 Si S <= R(p,g) es un mensaje repetido y lo descarta Si S > R(p,g) + 1 significa que perdió un mensaje y manda un ack negativo para que lo mande de nuevo. Integridad se alcanza por la detección de duplicados y los checkeos de IP en los datagramas. Validez por propiedad de IP. Agreement implica que los procesos siempre guardan copias de mensajes enviados para enviarlos de nuevo para que esto funcione los proceso no deben fallar !!!!

7 Ordenando los mensajes de Multicast Se usa un cola de mensajes multicast para guardarlos antes de procesarlos. Se trata de asignar un número de secuencia para cada mensaje en el cual todos estén de acuerdo. Cada proceso q en un grupo g mantiene un número A(q,g), el más grande de la secuencia acordada que se ha observado para un grupo g y P(q,g) el mayor de la secuencia propia. Cuando p quiere mandar un mensaje: Manda en forma segura siendo m el mensaje e i un identificador único para m cada proceso q responde a p con una proposición para acordar un número de secuencia para ese mensaje P(q,g) = Max(A(q,g), P(q,g))+1. Cada proceso guarda en su cola el mensaje con el número de secuencia que propuso provisionalmente ordenado de menor a mayor número de secuencia p recolecta todos los números de secuencia propuestos y selecciona el mayor a como el que se usará definitivamente y lo transmite en un mensaje broadcast seguro cada proceso entonces ordena la cola de mensajes antes de procesarlos según los números de secuencia acordados

8 ¿Cómo se encuentran los participantes cuando está basado en Multicast? Cada participante emite una señal periódicamente digamos cada t segundos La señal consiste en un paquete donde viene registrado el identificador del participante Además puede venir el timestamp de cuando lo envió Al mismo tiempo cada participante recibe las señales de este tipo emitidas por los demás Cuando recibe una señal hace lo siguiente: –Si no había recibido una señal de ese participante hasta ahora lo agrega a su vector de participante y registra la hora en que lo recibió –Si había recibido antes una señal, actualiza la hora en que recibió el último paquete para ese participante –Paralelamente cada m*t segundos un thread recorre el vector de participantes eliminando aquellos para los cuales no se ha recibido mensaje en los últimos n*m*t segundos

9 ¿Cómo se encuentran los participantes cuando está basado en TCP/IP? El primer participante del grupo crea la sesión registrándose como único participante Cuando un participante quiere ingresar al grupo debe conocer al menos la dirección de uno de ellos A este le manda una señal de “Join-group” El que recibe este mensaje le pasa su vector de personas conectadas. El que llega puede entonces comunicarse con todos los demas avisando que está en la sesión Cuando un participante quiere salirse del grupo debe avisarle a los demás (tiene las direcciones) Problemas ?