Sistemas Distribuidos Basadosen Coordinacion

Sistemas Distribuidos
Basados en
Coordinacin
Prof. M. Curiel
Basada en lminas y libro de
Tanenbaum y Van Steem
Contenido
z
z
z
z
z
z
z
Introduccin a los modelos de Coordinacin

Arquitecturas
Procesos
Comunicacin
Asignacin de Nombres
Sincronizacin
Consistencia y Replicacin
Introduccin a los Modelos de

Coordinacin
z
Cmputo y Coordinacion:
z
Cmputo: la parte de cmputo de un SD est

formada por procesos, y cada proceso se ocupa
de efectuar una actividad computacional
especfica la cual en principio es realizada
independientemente de otros procesos.
Coordinacin: maneja la comunicacin y
cooperacin entre procesos.
Introduccin a los Modelos de

Coordinacin
z
En SD basados en Coordinacin, el
enfoque recae en cmo ocurre la
Coordinacin entre procesos.
Taxonoma de Modelos de
Coordinacin
Temporal
Coupled
Decoupled
Coupled
Referential
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Cabri y Colaboradores (2000), para agentes mviles
Taxonoma
z
Acoplamiento referencial: tiene que ver con

la forma de hacer referencia explcita en la
comunicacin. Por ejemplo, un proceso
puede comunicarse con otro slo si conoce
su nombre o identificador.
Acoplamiento temporal: se refiere a que los
procesos que se comunican deben estar
funcionando.
Taxonoma
Coupled
Coupled
Referential
Decoupled
Temporal
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Taxonoma
Coupled
Coupled
Referential
Decoupled
Temporal
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Taxonoma
Coordinacin directa:
los procesos deben
estar funcionando y se
conocen.
Coordinacin de Buzon de
Correo: no se requiere que
los procesos que se estn
comunicando funcionen al
mismo tiempo para que
funcione la comunicacin.
sta ocurre colocando los
mensajes en un buzn de
correo (posiblemente
compartido).
En la comunicacin es
necesario referirse al buzn
de correo que mantendr
los mensajes a ser
intercambiados.
Coordinacin orientada a
reunin: los procesos no se
conocen entre s. Existe un
concepto de reunin en la
cual los procesos se
agrupan temporalmente
para coordinar sus
actividades. Segn este
modelo los procesos s
deben estarse ejecutando
al mismo tiempo.
Un tipo de sistemas de
publicacin/suscripcin
caen dentro de esta
categora.
Temporal
Coupled
Decoupled
Coupled
Referential
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Taxonoma
z
En los sistemas de publicacin y suscripcin

los procesos pueden suscribirse a mensajes
que contienen informacin sobre temas
especficos, en tanto que otros procesos
producen o publican tales mensajes.
La mayora de tales sistemas requiere que
los procesos que se estn comunicando
estn activos al mismo tiempo.
Taxonoma
Coupled
Temporal
Decoupled
z
Coupled
Referential
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Comunicacin Generativa:
(Linda) un conjunto de
procesos independientes
utilizan un espacio de datos
persistente, compartido,
conformado por tuplas.
Las tuplas son registros de
datos etiquetados
compuestos por varios
campos de entrada.
Las etiquetas sirven para
distinguir entre tuplas que
representan diferentes
clases de informacin.
Taxonoma
z
Estos espacios de datos compartidos

implementan un mecanismo de bsqueda
asociativa de tuplas: cuando un proceso
desea extraer una tupla del espacio de
datos, especifca los valores de aquellos
campos en los que est interesado.
Cualquier tupla que coincida con la
especificacin se retira del espacio de
datos y se transfiere al proceso.
Taxonoma
z
Si no se encuentra ninguna
coincidencia el proceso puede elegir
bloquearse hasta que se encuentra
alguna coincidencia.
Estos espacios de comunicacin
generativa se consideran tambin con
frecuencia como sistemas de
publicacin/suscripcin.
Arquitecturas
z
Una caracterstica importante de estos

sistemas (P/S) es que la comunicacin
ocurre describiendo las caractersticas de los
elementos de datos que se van a
intercambiar. Los elementos de datos no son
identificados explcitamente por remitentes y
destinatarios.
Los elementos de datos se describen por
medio de una serie de atributos.
Arquitectura General
z
Un elemento de datos est publicado cuando

se coloca a disposicin de otros procesos para
su lectura.
Mediante una subscripcin, el subscriptor
informa al sistema las caractersticas de
aquellos elementos de datos que son de su
inters.
Tal descripcin se compone de los pares
(atributo, valor) posiblemente combinados con
pares (atributo, rango). Las descripciones a
veces pueden darse utilizando varias clases de
predicados formulados sobre los atributos.
Qu pasa cuando las suscripciones tienen
que compararse con elementos de datos y
se da la coincidencia?
1. El middleware puede remitir los datos a su

grupo de suscriptores (cuando el middleware no
ofrece almacenamiento de datos, se trata de un
sistema referencialmente desacoplado pero
temporalmente acoplado)
2. Se remite una notificacin, despus de lo
cual los suscriptores pueden realizar la
operacin read para leer el elemento de
datos. El middleware necesariamente tiene
que guardar el elemento de datos. Tambin
es posible anexar un contrato a un elemento
de datos, de forma que cuando expire dicho
elemento se elimine automticamente.
Publisher
Data item
Subscriber
Subscriber
Read/Delivery
Subscription
Notification
Publish/subscribe middleware
Match
z
Se supone que cada elemento de datos tiene un

vector asociado <(a1,v1),(a2,v2),(a3,v3)....> de
pares (atributo, valor).
En muchos sistemas basados en coordinacin lo
que se publica son eventos.
En este tipo de sistemas es importante cmo se
implemente la coincidencia de suscripciones.
Los mtodos de coordinacin proporcionan un gran
potencial para construir SD a muy gran escala
debido al fuerte desacoplamiento de los procesos.
Arquitecturas Tradicionales
Solucin ms simple: arquitectura
Cliente/Servidor centralizada: WebSphere de
IBM, implementaciones de JMS (Sun),
implementaciones de Jini y JavaSpaces.
Jini y JavaSpaces
z
Jini es un sistema distribuido que implementa

un modelo de coordinacin de comunicacin
generativa.
Est fuertemente relacionado con Java,
aunque muchos de sus principios se pueden
implementar en otros lenguajes.
Ofrece desacoplamiento temporal y
referencial de procesos mediante un sistema
de Coordinacin llamado JavaSpaces
(derivado de Linda).
Jini y JavaSpaces
z
Un JavaSpace es un espacio de datos

compartido que guarda tuplas que representan
un conjunto de referencias a objetos Java. En
un sistema Jini pueden coexistir mltiples
JavaSpaces.
Las tuplas se guardan en forma serializada (se
empaqueta la tupla y sus campos)
Una tupla se coloca en un JavaSpace por medio
de una operacin write, que empaqueta primero
la tupla antes de guardarla.
Jini y JavaSpaces
z
Cada vez que se invoca la operacin write

en relacin a una tupla, se guarda otra copia
de dicha tupla (instancia) en el JavaSpace.
Para leer una instancia de tupla, un proceso
proporciona otra tupla que utiliza como
plantilla (tambin es un conjunto de
referencias a objetos).
Slo pueden leerse desde el JavaSpace
instancias de tupla del mismo tipo que la
plantilla.
Write A
Write B
Read T
C
Insert a
copy of A
A
Tuple instance
Look for
tuple that
matches T
Insert a
copy of B
Return C
(and optionally
remove it)
A
B
A JavaSpace
class public Tupla implements Entry {

public integer id, value;
public Tupla(Integer id, Integer value){this.id=id; this.value=value}
}
La siguiente plantilla:
Tupla template = new Tupla(null, new Integer(42))
equiparar la tupla:
Tupla item = new Tupla(newInteger(64)), new Integer(42))
Dos campos coinciden si ambos tienen una copia de la misma referencia o
si el campo en la tupla plantilla es NULL. Una instancia de tupla es igual a una
tupla plantilla si sus campos concuerdan.
Jini y JavaSpaces
z
z
z
Cuando se est haciendo una operacin

read y se encuentra una coincidencia, se
devuelve una copia de la instancia de la
tupla al proceso que la est solicitando.
La operacin take retira la tupla del
JavaSpace.
Ambas operaciones bloquean al invocador
hasta que se encuentra una tupla
coincidente. Tambin existen variantes para:
especificar un tiempo mximo de bloqueo o
regresar de inmediato si no se encuentra
coincidencia.
Jini y JavaSpaces
z
Los procesos que usan JavaSpaces no

tienen que coexistir al mismo tiempo. Si el
JavaSpace se implementa mediante
almacenamiento persistente, un sistema
Jini completo puede bajarse y reiniciarse
ms tarde sin que se pierda ninguna tupla.
Un servidor centralizado permite
suscripciones bastante elaboradas y facilita
la sincronizacin.
TIB/Rendezvous
z
Una solucin al uso de servidores centrales

es diseminar de inmediato los elementos de
datos publicados a los suscriptores
apropiados mediante multitransmisin
(TIB/Rendezvous)
En este sistema un elemento de datos es un
mensaje etiquetado con una palabra clave
compuesta que describe su contenido, tal
como news.comp.os.books
TIB/Rendezvous
z
Un suscriptor proporciona (partes de) una

palabra clave o indica los mensajes que
desea recibir, tal como news.comp.*.books.
Se dice que estas palabras clave indican el
tema de un mensaje.
Para la implementacin se utiliza con
frecuencia la multitransmisin en redes de
rea local, aunque tambin puede utilizarse
comunicacin punto-punto (si se sabe donde
reside un suscriptor)
TIB/Rendezvous
z
Cada servidor ejecutar un demonio rendezvous,

que se encarga de que los mensajes sean
enviados y entregados de acuerdo con el tema.
Siempre que se publica un mensaje, se
multitransmite a cada servidor de la red que
ejecuta un demonio rendezvous.
Los procesos suscritos a un tema transfieren su
suscripcin a un demonio local. ste construye
una tabla de entradas (proceso, tema)
10
TIB/Rendezvous
z
Siempre que llega un mensaje sobre un

tema S, el demonio revisa en su tabla en
busca de suscriptores locales y remite el
mensaje a cada uno. Si no existen
suscriptores para S, el mensaje se
desecha.
Publ. on A
Subs. to A
Subj: A
Subs. to A
Publ. on B
Subs. to A
Subs. to B
Subs. to B
Subj: B
RV lib
RV lib
RV lib
RV lib
RV lib
RV
daemon
RV
daemon
RV
daemon
RV
daemon
RV
daemon
Network
Multicast message
on A to subscribers
Multicast message on B to subscribers
Arquitecturas Punto-a-Punto
z
z
Servidor central no es escalable

Model TIB/R la multitransmisin requiere
de medidas especiales para ir mas all de
una red de rea local.
11
Arquitecturas Punto a Punto

z
Son sistemas de publicacin/suscripcin en

los cuales los eventos que se publican son
re-dirigidos slo a los nodos que se han
suscrito previamente a dicho evento.
Las suscripciones pueden variar desde la
especificacin de un simple atributo o evento
hasta la especificacin de un rango de
valores
Ejemplo: Sub-2-Sub2 (Sistema de

P/S basado en Conversacin)
z
z
Voulgaris et all (2004)

Los elementos de datos pueden describirse por
medio de N atributos a1, ...aN cuyo valor puede se
un entero, flotante, enumeraciones, booleanos y
cadenas.
Una suscripcin s adopta la forma de una tupla de
pares (atributo, valor/rango) tales como:
s =< a1 3.0, a4 [0.0,0.5) >
Ejemplo: Sub-2-Sub
z
Cada suscripcin si en realidad especifica un

subconjunto Si en el espacio de N-dimensiones de
nmeros punto flotante. A tal subconjunto se le
llama tambin hiperespacio.
Los nodos regularmente intercambian
suscripciones por medio de un protocolo
epidmico. Si dos nodos i, j advierten que sus
respectivas suscripciones se entrecruzan, es decir:
ij
registrarn este hecho y mantendrn referencias entre ellos.
12
Ejemplo Sub-2-Sub
z
S ij S k 0
Si descubren un tercer
nodo k con:
ijk
los tres se conectarn entre s, de modo que un elemento de datos

de inters para los tres pueda diseminarse con eficiencia.
En esencia lo que se busca es agrupar los nodos en M grupos diferentes, de

modo que los nodos i y j pertenezcan a un mismo grupo si sus suscripciones
se
entrecruzan. Los nodos ubicados en el mismo grupo debern organizarse
en una red sobre-puesta que permitir la diseminacin eficiente de un
elemento de datos en el hiperespacio asociado con dicho grupo.
Bidirectional ring
12
10
Node IDs
8
6
4
2
5
10
15
20
25
Group of four nodes for interval [16.5, 21.0]
30
35
Attribute value
Los nodos 3,4, 7 y 10 se agrupan para representar el intervalo [16.5, 21.0].

Cualquier elemento de datos con un valor presente en ese intervalo deber
diseminarse slo a esos 4 nodos.
13
Ejemplo Sub-2-Sub
z
Los nodos no slo mantienen la informacin a los

otros nodos en su anillo.
Para descubrir nuevos nodos (que pudieran estar
interesados en los mismos datos) los autores del
sistema desarrollaron cyclon, un protocolo
epidmico mediante el cual un nodo mantiene una
lista de vecinos seleccionados aleatoriamente
(vista), y regularmente intercambia vistas con otros
pares (conversacin). Tal intercambio permitir
que un nodo aprenda sobre otros nodos del
sistema.
Ejemplo Sub-2-Sub
z
Se manejan tres tipos diferentes de enlaces:

z
Enlaces aleatorios: enlaces a pares seleccionados

aleatoriamente, se necesitan para descubrir nuevos nodos y
para mantener la red conectada.
Enlaces de intereses solapados: reflejan similitudes entre
suscripciones y se usan para enviar eventos publicados a
otros pares interesados. Se usa un protocolo epidmico
basado en proximidad (vicinity)
Enlaces de anillos: Hay un orden entre los nodos que tienen
intereses comunes. Despus de un intercambio de
informacin (nodo i, nodo j) el nodo i ordena todos los
nodos en el conjunto por sus identificadores y selecciona el
que tenga el identificador ms bajo
14
Movilidad y Coordinacin
z
Cmo combinar soluciones de publicacin

y suscripcin con la movilidad de los
nodos?
z
Cmo garantizar que los mensajes

publicados no sean entregados ms de una
vez a un suscriptor que cambia de puntos de
acceso.
Sol: que los suscriptores no pierdan de vista
los mensajes que ya recibieron y desechen
los duplicados. Soluciones ms complicadas
se basan en enrutadores o direccionadores
que no pierden de vista qu mensajes fueron
enviados a cules suscriptores.
Lime
z
En el caso de comunicacin generativa, se han

propuesto varias soluciones para operar un espacio
de datos compartido donde todos/algunos de los
nodos son mviles. Un ejemplo de estos sistemas
es Lime.
Cada proceso tiene su propio espacio de datos
asociado, pero cuando los procesos estn
prximos entre s (conectados), sus espacios de
datos se vuelven compartidos.
Conectados:
z
z
Teora: existe una ruta en una red subyacente conjunta

que permite que dos procesos intercambien datos.
Prctica: procesos en el mismo servidor o que sus
servidores pueden comunicarse mediante un enlace
inalambrico.
Lime
Transient, shared dataspace
Process
Process
Process
Local
dataspace
Local
dataspace
Local
dataspace
Wireless link
15
Lime
z
Si hay un espacio de datos compartidos de forma

transitoria los procesos pueden intercambiar tuplas
El espacio de datos compartidos, est distribuido,
pero esto es transparente para los procesos
participantes.
Lime tambin permite romper con esta
transparencia y especificar para qu proceso va el
mensaje. Las operaciones read y take pueden tener
un parmetro adicional que especifique de qu
proceso se espera una tupla.
Comunicacin en Sistemas de
Publicacin/Suscripcin
z
En la mayora de estos sistemas la

comunicacin es relativamente simple, por
ejemplo en casi todos los sistemas basados
en Java, toda la comunicacin se realiza
mediante invocaciones a mtodos remotos.
Un problema: los datos publicados deben
llegar slo a los suscriptores. Una solucin
puede ser la organizacin de los nodos
presentes en un sistema punto-punto,
despus de lo cual la diseminacin ocurre por
grupo.
Enrutamiento basado en
contenido
z
Se supone que el sistema est construido

encima de una red punto-punto en la cual
los mensajes son explcitamente
direccionados entre los nodos.
Es crucial que los enrutadores sean
capaces de tomar decisiones, utilizando el
contenido del mensaje. En otras
palabras...cada mensaje porta una
descripcin de su contenido. Esta
descripcin puede utilizarse para
interrumpir rutas que no conducen a
receptores interesados.
16
contenido
z
Carzaniga y colaboradores proponen un

esquema de enrutamiento donde los
servidores se conectan en forma de rbol.
En el dibujo, los servidores estn en los
extremos del rbol y los nodos
intermedios son los enrutadores.
1
1
3 1
R1
5
R2
3
4
contenido
z
Sol 1 (extrema) enviar cada mensaje publicado a

cada servidor y dejar que ste verifique si cualquiera
de sus clientes se haba suscrito al tema de dicho
mensaje (TIB/Rendevouz)
Sol 2 (extrema) cada servidor transmita sus
suscripciones a todos los dems servidores (y
enrutadores). Cada servidor o enrutador tiene una
lista de pares (tema, destino). Cuando el mensaje
llega a un enrutador, ste puede utilizar la lista para
decidir las rutas que el mensaje deber seguir.
17
contenido
z
Podemos afinar las capacidades de los

enrutadores para decidir a donde van los
mensajes. Cada servidor transmite su
suscripcin a travs de la red de modo que
los enrutadores puedan componer filtros de
almacenamiento.
Tabla o filtro de Enrutamiento del enrutador

R2
Interfaz
Filtro
Hacia el
a [0,3]
Nodo 3
Hacia el
a [2 ,5 ]
nodo 4
Hacia el
No
a [2,5]
enrutador especifica
r1
-do
3 1
a [0,3]
R1
5 a [0,3] [2,5] = [0,5]

R2
3
4
a [0,3]
a [2,5]
Cuando un nodo abandone el sistema , o

ya no est interesado en mensajes
especficos deber cancelar su
suscripcin y transmitir esa informacin
a todos los enrutadores.
Como producto de esta cancelacin se
pueden ajustar varios filtros de
enrutamiento.
18
z
Hasta ahora hemos trabajado bajo la

suposicin que todo dato publicado tiene un
vector asociado de N pares (atributo, valor)
y que los procesos pueden suscribirse a
elementos de datos especificando
predicados sobre estos valores de atributos.
Existen sistemas en los cuales los
elementos de datos no estn etiquetados
con valores para todos los atributos.
z
En particular veremos que un elemento de

datos tiene slo un par asociado (atributo,
valor), en cuyo caso tambin se conoce como
evento.
El soporte a suscripcin de eventos y,
especialmente, a eventos compuestos inspira
en gran medida el anlisis sobre temas de
asignacin de nombres en los sistemas de
publicacin/suscripcin.
z
Cuando se trabaja con eventos tenemos que

tomar en cuenta:
z
Cmo componer los eventos (describir las

composiciones) (Pietzuch y colaboradores 2003
propusieron una estructura general para la
composicin de eventos en SD)
Cmo recopilar eventos (primitivos) y
posteriormente equiparalos con suscripciones.
19
Descripcin de Eventos Compuestos
Evento
Descripcin
S1
Notifica cuando el cuarto R4.2 est desocupado

(simple)
S2
Notifica cuando el cuarto R4.2 est desocupado y la

puerta est abierta (compuesto)
S3
Notifica cuando el cuarto R4.2 est desocupado

durante 10 segundos y la puerta est abierta
(compuesto + requiere de tiempo)
S4
Notifica cuando la temperatura del cuarto sube ms de

un grado por cada 30 minutos (medir temperatura)
S5
Notifica cada vez que la temperatura promedio del

cuarto se mantuvo por mas de 20 grados en la ltima
hora (calcular promedio)
Descripcin de Eventos
Compuestos
z
La idea bsica es habilitar la formulacin de

suscripciones en funcin de eventos
primitivos.
Pietzuch y colaboradores, proponen un
lenguaje basado en una mquina de estado
finito ampliada. Las extensiones permiten
especificar tiempos de permanencia en
estados, as como la generacin de eventos
nuevos (compuestos)
Room unoccupied
Door is locked
t=10s
(start)
Room is occupied
Door is unlocked
(generate event)
Mquina de Estado Finito para la suscripcin S3.

Se hace una transicin al estado final si la puerta no se cierra
y el saln permanecen vacos por 10 segs.
20
Compuestos
z
Las FSM (Finite State Machines) se pueden

descomponer en otras mquinas ms
pequeas que se comunican pasndose
eventos entre s.
Ejem: se desea apagar las luces de la
habitacin R4.2 despus de 2 segundos de
estar seguros que no hay nadie en ella (y la
puerta est cerrada)
(generate event)
Room unoccupied
Door is locked
(start)
t=10s
Room is occupied
(start)
Door is unlocked
t=2s
Switch lights off
Dos mquinas de Estado Finito Acopladas
compuestos
z
Las FSM pueden implementarse como

procesos aparte en el sistema distribuido. La
segunda FSM se suscribir al evento
compuesto que se deriva de la primera.
Los eventos son mensajes enviados a travs
dela red a procesos suscritos a ellos.
21
Sincronizacin
z
Es simple cuando se utiliza un solo servidor.

Los procesos pueden simplemente
bloquearse hasta que las tuplas estn
disponibles
Todo se complica cuando el espacio de
datos compartido se replica y distribuye a
travs de mltiples servidores.
Consistencia y Replicacin:
Mtodos Estticos
z
Ejem: JavaSpace. Se desea replicar y

distribuir el conjunto de tuplas en varias
mquinas.
Consideraciones generales:
z
Cmo realizar la asociacin

(publicacin/suscripciones) sin necesidad de
realizar una bsqueda masiva?
Como distribuir instancias de tuplas entre
mquinas y localizarlas despus?
Mtodos Estticos
Dividir el espacio de tuplas en sub-espacios, cada
una de cuyas tuplas es del mismo tipo. Como las
tuplas entran por teclado es posible determinar a
tiempo de compilacin en qu subespacio opera
una invocacin a read, take o write.
z Cada sub-espacio puede organizarse mediante una
tabla de hash, utilizando uno de los campos de las
tuplas.
z Las tuplas de un mismo sub-espacio pueden
replicarse
enwrite
diferentes
mquinas.
Una invocacin
a read,
o take se ejecuta
calculando la funcin de
z
hash del i-simo campo para determinar la posicin de la tabla donde pertenece
la instancia de la tupla. Si el campo i-simo es NULL, no puede aplicar una funcin de
hash y es necesario hacer una bsqueda completa.
22
Mtodos Estticos
z
Si se dispone de una transmisin confiable

se pueden replicar todos los sub-espacios en
todas las mquinas.
Cuando se realiza una operacin write la
nueva instancia de tupla se transmite e
ingresa en el sub-espacio adecuado para
cada mquina
Read o take realiza la bsqueda en el
subespacio local. Para la consumacin
exitosa de un take, es necesario eliminar la
tupla de todas las mquinas.
Tuple broadcast
Network
Process doing
a write broadcasts
(a)
Process doing a take

examines local JavaSpace
Tuple delete
Subspaces
Network
(b)
Mtodos Estticos
z
Este diseo es simple pero no escala bien a medida

que aumenta el nmero de instancias de tupla o el
tamao de la red.
El diseo inverso es realizar los write localmente,
guardando la instancia de la tupla slo en la
mquina que la gener. Para realizar un read o take
el proceso debe transmitir la tupla-plantilla. Cada
receptor revisa para ver si tiene una tupla igual y
contesta afirmativamente si la tiene. Si la instancia
de la tupla no est presente o si no se recibe el
mensaje en la mquina que tiene la tupla, la
mquina solicitante retransmite (ad infinitum) hasta
que obtiene una respuesta satisfactoria.
23
Process doing a write

inserts tuple into local JavaSpace
Network
(a)
Process doing a read

broadcasts template
Template broadcast
Network
(b)
Mtodos Estticos
z
Los dos mtodos anteriores pueden combinarse

para producir un sistema con replicacin parcial:
z
Suponga que todas las mquinas forman una cuadrcula

rectangular.
Cuando el proceso A desea realizar una una operacin
write transmite (o enva un mensaje punto-punto) la tupla
a todas las mquinas ubicadas en su fila de la cuadrcula.
Cuando el proceso B desea leer o tomar una instancia de
la tupla, transmite la tupla plantilla a todas las mquinas de
su columna. Debido a la geometra siempre habr
exactamente una mquina que ve tanto la instancia de
tupla como la tupla plantilla (C)
A broadcasts
tuple to these
machines
B broadcasts template
to these machines
24
Mtodos Estticos
z
Todas las implementaciones presentadas tienen

problemas de escalabilidad (la mayora se basa en
multitransmisin)
Las implementaciones de espacios de tuplas en
redes de rea amplia no existen. En el mejor de los
casos pueden existir varios espacios de tuplas
diferentes, y cada espacio se implementa en un
servidor o en una red de rea local.
Replicacin Dinmica
z
z
z
Ejem: GigaSpaces
Se construy encima de JavaSpaces.
En este sistema la distribucin y replicacin
de tuplas se realizan por dos razones:
desempeo y disponibilidad. Se utilizan
estrategias diferentes en ambos casos. Por
esta razn se soportan varias polticas de
replicacin.
Replicacin Dinmica
z
Se ofrecen las llamadas read, write, take, al

igual que con JavaSpaces.
Cada una de estas llamadas es captada por
un manejador de invocaciones local que
busca la poltica a seguirse para la
invocacin especfica.
Se selecciona una poltica basada en el tipo
y contenido de la tupla que se transfiere
como parte de la invcacin.
25
Replicacin Dinmica
z
El manejador de invocacin usa plantillas para

identificar los diferentes tipos de tuplas.
Posteriormente se invoca al gestor de
distribucin, el cual implemnta la misma interfaz
pero ahora de acuerdo con una poltica de
replicacin especfica.
Ejem. Maestro-Esclavo. Todos tienen la tupla,
un read puede ser local. Un write puede requerir
que el gestor de distribucin remita el nodo al
maestro y espere un acuse de recibo antes de
realizar la operacin localmente.
Application
Dataspace
slice
Distribution
Distribution
Distribution
manager
manager
manager
Invocation
handler
Policy
table
Local OS
To network
Replicacin Dinmica
z
En GigaSpace la gestin de replicacin es

automtica, i.e. en lugar de permitir que el
desarrollador de aplicaciones decida qu poltica
es la mejor, el sistema monitorea los patrones de
acceso y comportamiento para posteriormente
adoptar las polticas que se requieran.
Con este objetivo GigaSpace continuamente
mide el ancho de banda consumido, la latencia
de la red y el uso de la memoria , coloca las
tuplas en diferentes nodos y elige la manera ms
apropiada de mantener las rplicas consistentes.
26
Resumen
z
Los sistemas distribuidos basados en

coordinacin estn enfocados en el
desacoplamiento referencial de los
procesos, i.e. stos no tienen que referirse
explcitamente entre s para habilitar la
comunicacin. Tambin es posible tener
desacoplamiento temporal, de modo que los
procesos no tienen que estar activos para
comunicarse.
Resumen
z
Un grupo importante de estos sistemas est

formado por aquellos que siguen el paradigma de
publicacin/suscripcin (TIB/Rendevouz) En este
modelo los mensajes no portan la direccin de sus
receptores sino que en cambio son direccionados
por tema.
Un poco ms complejos son aquellos sistemas
donde los suscriptores pueden formar predicados
sobre los atributos de los elementos de datos
publicados. El enrutamiento en estos sistemas se
hace basado en contenido.
Resumen
z
Otro grupo importante utiliza comunicacin

generativa, la cual ocurre por un espacio
compartido de tuplas.
Los principios de los SD se aplican a
sistemas basados en coordinacin. El
almacenamiento en cache y la replicacin
desempean un rol menos prominente en
las replicaciones actuales
27

Sistemas Distribuidos Basadosen Coordinacion

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sistemas Distribuidos Basadosen Coordinacion

Transféré par

Droits d'auteur :

Formats disponibles

Sistemas Distribuidos

Introduccin a los modelos de Coordinacin

Introduccin a los Modelos de

Cmputo: la parte de cmputo de un SD est

Introduccin a los Modelos de

Cabri y Colaboradores (2000), para agentes mviles

Acoplamiento referencial: tiene que ver con

En los sistemas de publicacin y suscripcin

Estos espacios de datos compartidos

Una caracterstica importante de estos

Un elemento de datos est publicado cuando

1. El middleware puede remitir los datos a su

Se supone que cada elemento de datos tiene un

Jini es un sistema distribuido que implementa

Un JavaSpace es un espacio de datos

Cada vez que se invoca la operacin write

class public Tupla implements Entry {

Cuando se est haciendo una operacin

Los procesos que usan JavaSpaces no

Una solucin al uso de servidores centrales

Un suscriptor proporciona (partes de) una

Cada servidor ejecutar un demonio rendezvous,

Siempre que llega un mensaje sobre un

Multicast message on B to subscribers

Servidor central no es escalable

Arquitecturas Punto a Punto

Son sistemas de publicacin/suscripcin en

Ejemplo: Sub-2-Sub2 (Sistema de

Voulgaris et all (2004)

s =< a1 3.0, a4 [0.0,0.5) >

Cada suscripcin si en realidad especifica un

registrarn este hecho y mantendrn referencias entre ellos.

los tres se conectarn entre s, de modo que un elemento de datos

En esencia lo que se busca es agrupar los nodos en M grupos diferentes, de

Group of four nodes for interval [16.5, 21.0]

Los nodos 3,4, 7 y 10 se agrupan para representar el intervalo [16.5, 21.0].

Los nodos no slo mantienen la informacin a los

Se manejan tres tipos diferentes de enlaces:

Enlaces aleatorios: enlaces a pares seleccionados

Cmo combinar soluciones de publicacin

Cmo garantizar que los mensajes

En el caso de comunicacin generativa, se han

Teora: existe una ruta en una red subyacente conjunta

Si hay un espacio de datos compartidos de forma

En la mayora de estos sistemas la

Se supone que el sistema est construido

Carzaniga y colaboradores proponen un

Sol 1 (extrema) enviar cada mensaje publicado a

Podemos afinar las capacidades de los

Tabla o filtro de Enrutamiento del enrutador

5 a [0,3] [2,5] = [0,5]

Cuando un nodo abandone el sistema , o

Hasta ahora hemos trabajado bajo la

En particular veremos que un elemento de

Cuando se trabaja con eventos tenemos que

Cmo componer los eventos (describir las

Descripcin de Eventos Compuestos

Notifica cuando el cuarto R4.2 est desocupado

Notifica cuando el cuarto R4.2 est desocupado y la

Notifica cuando el cuarto R4.2 est desocupado

Notifica cuando la temperatura del cuarto sube ms de

Notifica cada vez que la temperatura promedio del

La idea bsica es habilitar la formulacin de