comunicación en sistemas distribuidos (ii)
Post on 13-Jul-2022
11 Views
Preview:
TRANSCRIPT
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
sEl modelo de gruposEl modelo de grupos
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
sEl modelo de gruposEl modelo de grupos
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
sEl modelo de gruposEl modelo de grupos
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
sEl modelo de gruposEl modelo de grupos
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
sEl modelo de gruposEl modelo de grupos
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
sEl modelo de gruposEl modelo de grupos
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
sEl modelo de gruposEl modelo de grupos
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
sLa agencia de robotsLa agencia de robots
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
sLa agencia de robotsLa agencia de robots
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
sLa agencia de robotsLa agencia de robots
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
sEl modelo de gruposEl modelo de grupos
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
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
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sLa agencia de robotsLa agencia de robots
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los componentes de un grupoGestión de los componentes de un grupo
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
sGestión de los Gestión de los componentes de un componentes de un grupogrupo
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
sGestión de los Gestión de los componentes de un componentes de un grupogrupo
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
sGestión de los Gestión de los componentes de un componentes de un grupogrupo
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
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
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
sProtocolos de difusiónProtocolos de difusión
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
top related