Comunicación en sistemas distribuidos (ii)

DISCA / UPV Departament d’Informàtica de Sistemes i Computadors

Universitat Politècnica de València

Joan Vila

Diseño Y Aplicaciones de Sistemas Distribuidos

Comunicación en sistemasComunicación en sistemasdistribuidos (ii):distribuidos (ii):

gruposgrupos

2

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sGrupos en sistemas distribuidosGrupos en sistemas distribuidos

Indice– El modelo de grupos

– Gestión de componentes en grupos distribuidos Gestión centralizada Detección de fallos Detección distribuida de fallos

– Protocolos de difusión Interfaz Java Propiedades de los protocolos de difusión

3

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sEl modelo de gruposEl modelo de grupos

Naturaleza de los grupos– En un sistema distribuido existen grupos de procesos que colaboran en la

consecución de una tarea común o se abastecen de flujos de informacióncomunes. Su naturaleza puede ser diversa: Grupo de colegas (peer group): son grupos cerrados (estáticos) en los que los

miembros conocen a sus colegas. Toda la comunicación tiene su origen enprocesos del grupo y el destino es también el grupo.

– Ej. La RoboCup, la célula de fabricación. Grupo de subscriptores: son grupos abiertos (dinámicos) en los que los procesos

se afilian o suscriben. Los procesos del grupo reciben las mismas fuentes deinformación. Los miembros no suelen conocerse entre si.

– Ej. listas de correo Grupo servidor: son grupos de procesos que llevan a cabo un servicio, bien sea

de forma redundante o repartiéndose la carga. La comunicación normalmente esiniciada por un cliente, que no pertenece al grupo, y tiene como destino unrepresentante del grupo o todo el grupo.

– Ej. servidor de ficheros distribuidos.

– La forma de comunicación propia de los grupos es la difusión

4

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Cliente

bloqueado

p1recibir y

contestarp2

p3

p4

Gruposervidor

peticion

respuesta

respuesta

respuesta

respuesta

recibir ycontestar

recibir ycontestar

recibir ycontestar

difundir

p1p2

p3

p4

difundir

Difusor

Escuchas

manejarevento

manejarevento

manejarevento

manejarevento

difundirevento

Comunicación en grupos– Puede seguir dos patrones, ambos de ellos utilizan difusión:

Activa: sigue el patrón cliente / servidor. Se utiliza para invocar servicios con unainterfaz bien definida. Se utiliza para servicios replicados.

Reactiva: sigue el patrón difusor / escucha. Se utiliza para notificar eventos.

5

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Concepto de estado global– Estado global del grupo: es la agregación de forma “sincronizada” de los

estados individuales de cada proceso. Es una “instantánea” (snapshot) de losestados de los distintos procesos del sistema.

EstadoP1

P1

P2P3

P4

T=5

EstadoP2

T=5

EstadoP3

T=5

EstadoP4

T=5Estado global

6

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Concepto de estado global– Par obtener el estado global la composición de los estados de cada uno de los

componentes ha realizarse de “sincronizada”, sino puede haberinconsistencias.

S1

T(S1)

S2

T(S2)

S3

T(S3)

S1

T(S1)

S2

T(S2)

S3

T(S3)

Sincronizadas

7

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Ejemplos de aplicaciones con grupos de procesos– Coordinación de procesos distribuidos

Robo Cup

Agencia de robots

– Difusión de eventos, noticias, ... News, Chat

– Localización de objetos en servicios distribuidos Servicios de nombres

– Replicación de servicios (tolernacia a fallos, aumento disponibilidad) Servidores total o parcialmente redundantes

8

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Ejemplo 1: la célula de fabricación– Se tiene un conjunto de robots móviles autónomos que cooperan en

manufacturar una pieza.

– Normalmente existe un supervisor que descompone la tarea en subtareas, lasasigna a los robots y monitoriza su ejecución.

9

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

s

s

El modelo de gruposEl modelo de grupos

Grupos e Inteligencia Artificial Distribuida– Sistema humano equivalente

Agentes autónomos Supervisor: la forma tradicional de actuación inteligente suele basarse en un

supervisor cuya “inteligencia” reside en realizar la toma de decisiones basadas lavisión del estado global del sistema. Es un esquema centralizado.

10

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

s

Grupos e Inteligencia Artificial Distribuida– Inteligencia Artificial Distribuida (IAD): coordinar el comportamiento de los

agentes para conseguir un fin común. Estructura: conjunto de agentes que exhiben comportamiento con un cierto grado

de autonomía e “inteligencia”. Inteligencia: capacidad de un agente para para percibir información, razonar

sobre la misma, y actuar sobre la información en consecuencia.

– Objetivo: descentralizar la toma de decisiones, proporcionando unmecanismo que permita que los distintos procesos tengan una visión delestado global.

El modelo de gruposEl modelo de grupos

11

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Cabina A

Cabina B

Cabina C

Cabina D

Cámara deVideo

Grupos e Inteligencia Artificial Distribuida– Estado global del grupo: es una “instantánea” de los estados de los distintos

procesos del sistema obtenida de forma “sincronizada”.

12

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Ejemplo 2: la RoboCup– Dos equipos de robots cooperan para jugar un partido de futbol.

– Las decisiones se suelen basar en el estado global proporcionado por unaimagen tomada por una cámara cenital.

– En las últimas ediciones de la RoboCup se ha prohibido la cámara cenital ylos robots deben tomar sus decisiones basadas en sus propias percepciones.

13

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sLa agencia de robotsLa agencia de robots

Ejemplo 3: la persecución de robots

Lider Seguidor

Consola(s)Robot(s)CámaraRobot(s)

14

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Componentes del sistemaEsistema consta de tres componentes implementados como objetos remotos:

– Robots: cuya conducta es alcanzar un objetivo (robot o punto aleatorio)evitando los obstáculos del escenario

– Cámara cenital: tiene un doble objetivo: Difundir instantáneas del estado global (posición de todos los robots) y gestionar e

informar sobre los cambios del escenario de obstáculos.– Gestiona el canal de difusión: la dirección IP y el port para las difusiones del sistema, son

establecidos como parámetros al lanzarla a ejecución. Actuar de gestor del grupo, ocupándose de las altas y bajas de los robots y de las

consolas en el grupo así como de detectar los “fallos” de los robots.

– Consolas: su objetivo es monitorizar y servir de interfaz de usuario del sistema

15

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Componentes del sistemaAdemás existen algunos tipos de datos (objetos) que los componentes

intercambian a través de la comunicación distribuida:

– Instántanea Lista de los estados de todos los robots suscritos Los estados de los robots suscritos comprende su posición, identificador, etc...

16

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Implementación mediante simulación– La cámara es simulada: como no existe una cámar física que capte el estado

global del sistema, se recurre a la siguiente técnica: Cada robot evalúa su posición en el sistema, sabiendo su punto de partida y sus

movimientos La cámara interroga periódicamente a todos los robots sobre su posición Todos los cambios de escenario solicitados por las consolas son comunicados a la

cámara que es la que gestiona el escenario actual.

– Los robots son simulados: existe una biblioteca khepera.jar en el que seproporciona: Una interfaz similar a la de la interfaz serie del robot Khepera real para acceder los

motores y los sensores. Algoritmos de control para evitar obstáculos y encaminarse a un destino

– La consola se proporciona implementada: existe una biblioteca consola.jar quepermite al operador: Visualizar los robots y el escenario Cambiar objetivos, posición de los robots y el escenario

17

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Problemática básica– Gestión de componentes del grupo

Grupos estáticos / Grupos dinámicos Detección de fallos

– Primitivas de comunicación de grupos Protocolos de difusión selectiva (multicast)

18

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido





19

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sGestión de los componentes de un grupoGestión de los componentes de un grupo

Direccionamiento de grupos– Los grupos deben considerarse como una abstracción única, sin hacer

mención explícita de sus componentes, y ser direccionados mediante unidentificador del grupo.

– Existen diversas alternativas para identificar un grupo: Un identificador abstracto asignado por un gestor de grupos Una dirección IP de multicast Un predicado (Ej. máquinas con memoria > 4Mb)

– Problema de expansión de direcciones: consiste en obtener la lista de loscomponentes del grupo a partir del identificador.

20

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Gestión de componentes del grupo– Grupos estáticos: sus componentes son fijos, conocidos en tiempo de

desarrollo de la aplicación y no cambian. Ejemplos: Equipo de la RoboCup, Robots de la Célula de Fabricación

– Grupos dinámicos: pueden darse de alta y de baja componentes. Ejemplos: Subscriptores de grupos de noticias

21

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Gestión de componentes de un grupo– Un grupo dinámico es una abstracción que

debe proporcionar métodos para incorporary dar de baja componentes del grupo:

grupo: constructor(es) suscribir abandonar expandir difundir recibir

Gestión de grupos y tolerancia a fallos– Un proceso puede abandonar un grupo de

forma implícita cuando falla.– Detectar fallos y gestionar los componentes

de un grupo son problemas equivalentes.

difusión

Expansión

direcciones

Abandona

Falla

Suscribe

22

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Implementación de un gestor de grupos CORBA– Implementación centralizada

Gestor deGrupo A

CORBANamingService

lookup(gestorA)iorGestor

suscribirRobot(IORx)ok

Miembroy

listaSuscripcion()listaIORsobtenerEstado(

)

ok

ip

obtenerIPYPort()difundir()

obtenerEstado()ok

Miembrox

okbind(gestorA)

23

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Interfaz IDL de un gestor de grupos (i)module corba {

module robot { interface RobotInt; //util para las referencias adelantadas };

module instantanea {

struct EstadoRobotD { string nombre; unsigned long id nombre; Robot::RobotInt IORrob; //Referencia en formato binario string IORrob2; //Referencia en formato string //Para el trabajo final, más datos del robot: posición, objetivo, ... };

struct InstantaneaD{ sequence<EstadoRobotD> estadorobs; };

}

24

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Interfaz IDL de un gestor de grupos (i)

module corba {... module robot{ interface RobotInt; { void ObtenerEstado(out corba::Instantanea::EstadoRobotD est); }; };...};

25

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Interfaz IDL de un gestor de grupos

module corba {... module camara {

struct IPYPortD { string ip; unsigned long port }

struct suscripcionD{

unsigned long id;

IPYPortD iport;

};

interface CamaraInt { suscripcionD SuscribirRobot(in string IORrob);

void BajaRobot(in Robot::RobotInt refrob);

ListaSuscripcionD ObtenerLista();

IPYPortD ObtenerIPYPort(); };

};

};

26

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sIncisoInciso

Problema de los mappings de IDL a Java– El mapping establece una clase con atributos únicamente de datos (sín métodos)

– IDL struct PosicionD Java class PosicionD (sin métodos)class PosicionD class Posicion { struct PosicionD; public Posicion (PosicionD p) {...} //conversor 1 // Otros métodos útiles public PosicionD toPosiciónD() {...} //conversor 2 }

– Este mapping resulta especialmente desfavorable con la listas

– IDL sequence<EstadoRobotD> estadorobs Java EstadoRobotD[] estadorobs; Para realizar la aplicación y gestionar la lista utlizar LinkedList:

EstadoRobotD UnEstadoRobot;LinkedList listaEstados = new LinkedList();listaEstados.add(UnEstadoRobot);

Parar comunicar utilizar el conversor de LinedList a array:instantanea = new InstantaneaD((EstadoRobotD[]) listaEstados.toArray(new EstadoRobotD[0]));

Sinmétodos

Rica enmétodos

27

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Estructura de la implementación Java– Está estructurada en 6 paquetes

– Cada paquete es, además, un proyecto que genera un fichero JAR con el código

Package camara

Package comm Package khepera

Package consola

Package corba

Package robot

• Biblioteca para difusión de objetos

• Soporte CORBA generado del procesamiento de la interfaz IDL

• Simulador de la cinemática y los sensores del robot Khepera

Objetos remotos

Soportey

bibliotecas

28

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sLa agencia de robotsLa agencia de robots: la Cámara: la Cámara

Estructura de la Implementación CORBA

public class CamaraInt_impl extends CamaraIntPOA{ // CODIGO APLICACION Difusion difusion; ... public int SubscribirRobot(String IOR, String name){ // TODO: implement public void BajaRobot(corba.Robot.RobotInt refrob){ // TODO: implement }

//------------------------------------------------------------------------------// La clase anidada CamaraDifusion//------------------------------------------------------------------------------ class CamaraDifusion extends Thread{...}

public class CamaraServer{ // CODIGO CORBA ... orb = org.omg.CORBA.ORB.init(args, props); // Crear una instancia del objeto CamaraInt_impl cam = new CamaraInt_impl(rootPOA); CamaraInt camara = cam._this(orb); // Registrar el servicio en el Servicio de Nombres org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService"); NamingContext ncRef =NamingContextHelper.narrow(objRef); NameComponent nc =new NameComponent ("LaCamara", ""); NameComponent path[] ={nc}; ncRef.rebind(path,camara);...}

CamaraInt_impl.java

CamaraServer.java

Separar el código de aplicación

del código CORBA

servant: código aplicación

server: código java

29

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sLa agencia de robots: el RobotLa agencia de robots: el Robot

RobotSeguidormain(){ inicia corba Obtener orb run(orb)}run(orb){ crear robot (RobotSeguidorInt_imp) narrow de la cámara obtener y asignar IOR del robot asignar orb y camara al robot arrancar el hilo del robot pasar el control al orb (orb.run())}

Bus CORBA

RobotSeguidorInt_imp

PoaOrbCamara

RobotDifusion

MinombreMiidmiIORinstantanea

Cámara

run(){ suscribir robot en la cámara (el IOR) crear objeto difusión loop{ difusion.ReceiveObject() mostrar instantáneas}}

NameService

ObtenerEstado

Start

servant: código aplicaciónserver: código java

30

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Descentralizando el Gestor de Grupos– Problema de consenso: la operación

“censar” puede devolver diferentesrespuestas a diferentes nodos en un mismoinstante de tiempo t (las actualizaciones noson atómicas). ¿Que propiedades debe cumplir para ser útil?

– Problema de detección de fallos: ¿Cuandose puede decir que un nodo ha fallado? Basta con que sospeche un gestor, han de

sospechar todos, una mayoría...?

– Coordinación entre los mensajes deaplicación y los cambios en las visiones degrupo. Es absurdo, por ejemplo, que un nodo reciba

un mensaje después que este “haya fallado”.

Gestor 1

Gestor 2Gestor

N

Cliente1

Vision 1 del grupo

Cliente1

Vision 2 del grupo

31

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Detección de fallos:¿De que depende la posibilidad de consenso en la detección de fallos?

– Resultado: Dado un sistema con hipótesis de fallos de parada ycomunicación asíncrona es imposible el consenso. Fischer, Lynch, Patterson 1985. “Imposssibility of Consensus with one faulty

process”

– Depende del tipo de fallos soportados Fallos de parada (fail-stop): el fallo consiste en que el proceso detenga su

ejecución. Deja de interactuar con otros procesos. Es el más benigno de los tiposde fallos.

Sistemas asíncronos: no existe límite en el tiempo que tarda un proceso enejecutar un pasos en sus cómputos y el tiempo que tarda la red en entregar unmensaje

32

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sGestión de los Gestión de los componentes de un componentes de un grupogrupo

Un ejemplo de gestor descentralizado: el sistema IsisRealiza una implementación distribuida del monitor de grupo, que cumple las

siguientes propiedades:

– Acuerdo: todos los componentes pasan por la misma secuencia de visionesdel grupo. Cada nueva visión se produce cada vez que se incluye o se excluye un único

elemento. Los gestores logran consensuar una visión si no se producen sospechas de fallo un

periodo de tiempo largo (si el censo se estabiliza).

– Sincronía virtual: impone la siguiente ordenación entre los mensajes decambio y los mensajes de aplicación: Dada una visión del grupo Vi, todos los mensajes difundidos por algún proceso de

Vi deben llegar a todos los componentes de Vi mientras estos tienen la visión Vi.

33

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


V0={1,2,3}, V1={2,3}, V2={2,3,4}V0

V0

V0

V1

V1

V1 V2

V2

V2

Un ejemplo: el sistema Isis

34

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Fallos lógicos en Isis– Hay procesos que no fallan limpiamente: unos procesos “sospechan” que ha

fallado mientras que otros creen que es un proceso vivo.

– Cuando un proceso “sospecha” de otro que ha fallado, lo somete a consensoutilizando un protocolo de acuerdo.

– Fallos lógicos: Un proceso que ha fallado es, simplemente, un proceso quepor consenso es excluido del grupo (no es necesario el fallo físico).

– El fallo de un proceso debe ser el último evento en su vida: El mensaje que notifica el fallo de un proceso debe recibirse con posterioridad a los

mensajes anteriores. Si un proceso sigue emitiendo mensajes después de haber fallado, hay que instruir

el sistema de mensajes para filtrar todos los mensajes posteriores al fallo.

35

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Monitor de grupo en Isis– Ordenación de nodos: los nodos en una visión de grupo están ordenados

de manera unívoca de acuerdo con la visión en la que fueron operacionalespor primera vez con desempates por identificador de proceso.

– Gestor de visiones: es el nodo “mas viejo”. Es el responsable de iniciar elprotocolo de acuerdo cuando cuando se detecta un fallo o una recuperación.

– Elección de un nuevo gestor: si un nodo detecta que todos los nodos másviejos que él han fallado, se hace cargo de la gestión del grupo.

– Protocolo de gestión de visiones: se basa en un protocolo de compromisoen dos fases (two-phase commit).

36

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sGestión de Gestión de componentes de un componentes de un grupogrupo

Monitor de grupo en Isis: protocolo

Protocolo de gestión de visiones:

Protocolo del gestor– Difunde la PROPUESTA de nueva visión <...,Vi> y espera contestación

– SI (todas las contestaciones son positivas), entonces difunde un mensaje deCOMPROMISO.

– SI (alguna contestación es negativa) o (nuevos fallos o recuperaciones son detectados)entonces se confecciona una nueva propuesta extendida <..., Vi, Vi+1> y serecomienza el protocolo. Si el que ha fallado es el gestor, lo retoma otro gestor.

Protocolo de los nodos– Recibe una propuesta de visión.

– SI la visión es nueva (no se ha recibido una visión más actual de otro gestor) entoncesenvia un reconocimiento positivo.

– SINO, envia un reconocimiento negativo y la visión mas reciente.

37

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido





38

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido

sProtocolos de difusiónProtocolos de difusión

Difusión en redes– La difusión o envío de mensajes a un grupo de procesos puede

implementarse de dos formas: LAN’s: utilizando facilidades hardware para difusión (broadcast) que proporciona el

sistema físico. WAN’s: las difusiones en sistemas donde se atraviesan pasarelas se encuentran

restringidas (podrían originar ciclos de mensajes) y normalmente se implementancomo un conjunto de mensajes punto a punto.

– Los protocolos de difusión normalmente requieren suscribirse a un grupoantes de poder enviar / recibir del grupo.

– En TCP/IP las difusiones utilizan direcciones de tipo D Desde la 224.0.0.0 a la 239.255.255.255

28 bits

dirección multicastIPClase D 1 01 1

39

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


El interfaz de la difusión en Java– Interfaz semejante a UDP pero requiere suscribir un grupo.

– Java ofrece más posibilidades: se pueden enviar clases serializadas: La clase ByteArrayOutputStream permite realizar la serialización en memoria.

– El envio:Class X implements Serializable;X unX;

socket = new MulticastSocket(7000);InetAddress group = InetAddress.getByName ("228.5.6.7");socket.joinGroup(group);

ByteArrayOutputStream bos = new ByteArrayOutputStream();ObjectOutputStream oos = new ObjectOutputStream(bos);oos.writeObject (unX);byte[] buffer = bos.toByteArray ();

DatagramPacket packet = new DatagramPacket(buffer,buffer.length,group,7000);socket.send(packet);

40

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


El interfaz de la difusión en Java– Interfaz semejante a UDP pero requiere suscribir un grupo.

– Java ofrece más posibilidades: se pueden enviar clases serializadas: La clase ByteArrayInputStream permite realizar la de-serialización en memoria.

– La recepción:socket = new MulticastSocket(7000);InetAddress group = InetAddress.getByName ("228.5.6.7");socket.joinGroup(group);

byte[] buffer =new byte[4096];DatagramPacket packet = new DatagramPacket(buffer,buffer.length);socket.receive (packet);buffer = packet.getData ();

ByteArrayInputStream bis = new ByteArrayInputStream(buffer);ObjectInputStream ois = new ObjectInputStream(bis);X unX = (X) ois.readObject ();unX.unMetodo();

41

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Propiedades de las primitivas de difusión– Atomicidad: garantiza que, o bién todos los componentes operativos del

grupo reciben el mensaje difundido, o bién ninguno de éllos lo recibe.

– Ordenación: establece el orden relativo en que diferentes difusiones sonrecibidas en los destinos. La ordenación puede ser: Total Parcial

42

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Propiedades de ordenación– Sean:

Dos grupos G1 y G2 tal que G1∩G2 ≠ Φ. m1 un mensaje difundido a G1 y m2 un mensaje difundido a G2.

– Ordenación total: garantiza que: o bién m1 es recibido antes que m2 por todos los miembros de G1∩G2, o bién m2 es recibido antes que m1 por todos los miembros de G1∩G2.

– Ordenación parcial: garantiza que si existe una relación de orden parcialentre m1 y m2 (m1→ m2), entonces m1 es recibido antes que m2 por todoslos miembros de G1∩G2. Si la relación de orden es total, entonces se tiene ordenación total. Un ejemplo de orden parcial puede ser la ordenación causal.

43

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


No existe consistencia

causal

Consistenciacausal

Ordenación causal: un ejemplo– El boletín de noticias

44

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Propiedades de ordenación

Ordenación total yordenación causal

t: totalc :causal

45

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Cola retención

Cola entrega

Procesamiento

Llegadamensajes

Difusión ordenada: fundamentos

Se basa en los siguientes aspectos:– Cola de retención: cuando se recibe

un mensaje, no se le entregadirectamente a la aplicación, sino quese retiene en una cola hasta que seaestable.

– Mensaje estable: un mensaje se diceestable si: Orden: todos los mensajes

“anteriores” (según alguna relación deorden) han sido procesados.

Atomicidad: todos los destinos hanrecibido el mensaje.

46

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Protocolo de difusión causal (i)

Los procesos tienen un vector de timestamps VTi:– Todos los procesos pi inician VTi a cero– Cuando pi difunde un nuevo mensaje, primero incrementa VTi[i] y luego

adosa el valor vt = VTi[i] al mensaje– Cuando pk recibe un mensaje con timestamp vt, actualiza:

VTk = merge(vt, VTk)

47

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Sistema de relojes lógicos (relojes causales)

Pi

...VTi

Reloj de PiSe incrementacada vez que

Pi envía un msg

VTi[i]VTi[0] VTi[j]

Visión de Pidel reloj de Pj

Se incrementa cuando Pi ve en un msg

un valor más actual del reloj de Pj

3 5 2 ... 1 6

El mensaje 5 de PiEs causalmentedependiente de:

El 3 de P0El 2 de P1El 1 de Pj

Etc...

48

DYA

Dis

eño

Y A

plic

acio

nes

de

Sist

emas

Dis

trib

uido


Protocolo de difusión causal (ii)

Los mensajes que llegan a pk procedentes de pi (pi ≠ pk) son retenidosen una cola, hasta que pueden ser recibidos en orden causal. Los criteriospara transferir a la cola de recepción son:– El mensaje debe ser el siguiente en la secuencia que se espera de pi, es

decir,:vt[i] = VTk[i] + 1

– Todos los mensajes causalmente anteriores entregados a pi cuando ésteenvió el mensaje, deben haber sido entregados a pk , es decir:

VTk[n] ≥ vt[n] para n ≠ i

Comunicación en sistemas distribuidos (ii)

Documents

Transcript of Comunicación en sistemas distribuidos (ii)