CCT320 - 4 - Comunicação em SD

CCT320 Sistemas Distribudos
4
Rafael de Magalhes Dias Frinhani
frinhani@unifei.edu.br
2014
UNIVERSIDADE FEDERAL DE ITAJUB
2
OBJETIVOS
Apresentar os conceitos de comunicao em sistemas
distribudos, taxonomia da comunicao em SDs, paradigmas
de comunicao (Interprocess Communication, Remote
Invocation, Indirect Communication)
AGENDA
Contextualizao

Framework e camadas de servios de Sistemas Distribudos

Taxonomia da comunicao em Sistemas Distribudos

Interprocess Communication

Remote Invocation

Indirect Communication
Sistemas Distribudos precisam fornecer aos usurios a sensao
de estarem acessando diretamente recursos dispersos o que exige
uma comunicao rpida entre os comunicantes.
4. Comunicao em Sistemas Distribudos
3
A velocidade de comunicao entre processos remotos tem que
ser prxima dos processos locais. QUESTO: Como construir um
recurso de comunicao em um SD para alcanar alto
desempenho de comunicao.
4
Fatores que influenciam o desempenho da comunicao:

Velocidade da rede de comunicao;

Protocolos de comunicao, especialmente orientados a
conexo (TCP);

Paradigma da comunicao (o modelo de comunicao que
apoia a cooperao entre os pares e sistema operacional).
A velocidade de comunicao entre processos remotos tem que
ser prxima dos processos locais. QUESTO: Como construir um
recurso de comunicao em um SD para alcanar alto
desempenho de comunicao.
5
4. Comunicao em SDs - Introduo
Framework para compreenso dos Sistemas Distribudos
1. Quais so as entidades que esto se comunicando?
Processos (threads)? Ns? Objetos? Componentes? Servios web?

2. Como as entidades se comunicam, ou mais especificamente,
qual o paradigma de comunicao utilizado?
6
Framework para compreenso dos Sistemas Distribudos
1. Quais so as entidades que esto se comunicando?
Processos (threads)? Ns? Objetos? Componentes? Servios web?

2. Como as entidades se comunicam, ou mais especificamente,
qual o paradigma de comunicao utilizado?

3. Que papis e responsabilidades as entidades possuem na
arquitetura global?
Cliente ou Servidor? Peers?

4. Como as entidades so mapeadas na infraestrutura fsica
distribuda?

Particionamento? Replicao? Cache? Mobilidade cdigo?
7
Camadas de servios de Software e Hardware em
Sistemas Distribudos
8
Plataforma: Camadas de hardware e software de baixo-nvel implementadas
de forma independente em cada computador. Fornece interface de
programao do sistema at um nvel que facilite a comunicao e
coordenao entre os processos. Ex. Intel x86/Windows, Intel x86/Solaris, Intel
x86/Mac OS X, Intel x86/Linux e ARM/Symbian.
9
Composto por um conjunto de processos (ou objetos), em um grupo
de computadores que interagem para implementar comunicao e
oferecer suporte para compartilhamento de recursos a aplicativos
distribudos.
Middleware visa mascarar a heterogeneidade e fornecer
um modelo de programao conveniente ao programador
10
Middleware fornece blocos de construo para montagem
de componentes de software com objetivo de simplificar as
atividades de comunicao de programas aplicativos por meio
abstraes como:
11
Taxonomia da
comunicao em Sistemas
Distribudos
12
Taxonomia da
Distribudos
13
4. Comunicao em SDs Inter-process Communication
Inter-Process
Communication
14
Processo

Um processo, um programa em execuo. mais do que o
cdigo do programa j que este apresenta caractersticas
passivas e o processo possui caractersticas ativas.
15
Processo

Um processo, um programa em execuo. mais do que o
cdigo do programa j que este apresenta caractersticas
passivas e o processo possui caractersticas ativas.

Inclui a atividade corrente com um contador de programa
especificando a prxima instruo a ser executada e um
conjunto de recursos associados.

Geralmente inclui a pilha de processo, que contm dados
temporrios (ex. parmetros de mtodos, endereos de
retorno e variveis locais) e uma seo de dados, que contm
variveis globais.
16
Processo (cont.)
Processos concorrentes podem ser independentes ou
cooperativos.

Processo Independente: No pode afetar ou ser afetado por outros
processos executados no sistema.

Processo Cooperativo: Tem a capacidade de afetar ou ser afetado por
outro processo. Qualquer processo que compartilhe dados com outros
processos um processo cooperativo. Propsitos:
17
Processo (cont.)
Processos concorrentes podem ser independentes ou
cooperativos.

Processo Independente: No pode afetar ou ser afetado por outros
processos executados no sistema.

Processo Cooperativo: Tem a capacidade de afetar ou ser afetado por
outro processo. Qualquer processo que compartilhe dados com outros
processos um processo cooperativo. Propsitos:

Compartilhamento: Possibilita que vrios usurios tenham acesso
concorrente a informaes e demais recursos.

Velocidade de Computao: Quebrar uma tarefa em subtarefas possibilita
que sejam executadas em paralelo.

Modularidade: Construo de sistemas modularizados com funes
divididas em processos separados.
18
Sistemas operacionais implementam mecanismos que
asseguram a independncia entre processos:

Processos executam em capsulas autnomas onde a
execuo de um no afeta os outros.

Hardware oferece proteo de memria onde um processo
no acessa o espao de endereamento do outro.
Processo (cont.)
19
Processos precisam interagir e cooperar na execuo de
tarefas.

Precisam trocar informao de forma controlada para dividir
tarefas e com isso atender requisies simultneas.

O SO fornece mecanismos que permitem que os processos
comuniquem-se uns com os outros.
Processo (cont.)
20
Inter-Process Communication
um conjunto de mecanismos de troca de informao entre
mltiplas threads e/ou processos. Ao fornecer mecanismos de
IPC, o SO implementa canais de comunicao (implcitos ou
explcitos) entre processos.
21
Compartilhamento de Informaes entre Processos
(a) Compartilhamento de informao que reside em um arquivo do sistema de arquivos.
Necessrio sincronizao quando na atualizao do arquivo para proteger mltiplos escritores
e leitores.

(b) Dividem informaes contidas no kernel. Cada operao para acessar informao
compartilhada envolve uma system call no Kernel.

(c) A memria compartilhada entre os processos que a atualiza sem envolver o kernel.
(a) (b) (c)
22
Persistncia de objetos IPC
Pode-se definir a persistncia de qualquer tipo de IPC como o
quanto que um objeto de um determinado tipo permanece existente.
23
O contedo de uma
mensagem determinado
pelo processo de envio.

Informaes do cabealho
podem ser fornecidos pelo
sistema para permitir que a
mensagem chegue ao seu
destino.
Message Passing
Uma mensagem uma coleo de objetos de dados que
consistem em um cabealho de tamanho fixo e um corpo de
comprimento varivel ou constante, gerenciado por um
processo.
Formato genrico de uma
mensagem
24
Message Passing (cont.)
Para que dois computadores possam trocar dados preciso
mapear estruturas e itens de dados em mensagens.

A estrutura de dados deve ser serializada antes da
transmisso e reconstruda na chegada.

A serializao de dados estruturados em uma sequncia
bsica de dados usada para a transmisso dos dados.

Ao executar uma primitiva IPC, o pr-processador gera um
cdigo para fazer o marshalling (empacotamento para envio)
ou unmarshalling (desempacotamento ao receber) com base
na descrio do tipo dos dados estruturados.
25
Diagrama de tempo de execuo das primitivas message-passing
A passagem de mensagens entre um par de processos
obtida atravs das primitivas send e receive. Um processo
envia uma sequencia de bytes para outro, que o recebe.
26
Operaes Bloqueantes e No-Bloqueantes: Uma fila
associada a cada destino de mensagem onde processos
rementes adicionam mensagens em filas remotas e processos
destino as removem de suas filas locais.

As primitivas de bloqueio podem ocorrer de duas formas:
Caractersticas da Comunicao via Mensagens
1. Sistema Operacional

2. Linguagem de Programao
27
Caractersticas da Comunicao via Mensagens (cont.)

Send Bloqueante

Send bloqueado, a instruo seguinte no executada
enquanto a mensagem no chegar totalmente ao destino.

Send No-Bloqueante

Send bloqueado o tempo necessrio para copiar a
mensagem para o buffer do kernel.

A instruo seguinte ao send pode ser executada mesmo
antes da mensagem ter chegado ao destino.
1. Sistema Operacional
28
Primitivas send (a) bloqueante (b) no bloqueante
29

Reflete a cooperao cliente/servidor e a abordagem da
linguagem de programao para lidar com a comunicao da
mensagem.

Neste caso, o cliente bloqueado at que o servidor
(receptor) aceite a mensagem de solicitao e o resultado ou
confirmao de recebimento for recebida pelo cliente.
30

Primitivas send e receive na abordagem de bloqueio definida pela linguagem
31
Destinos de Mensagem: Nos protocolos Internet as
mensagens so enviadas para destinos especificados pelo par
(IP + Porta local).

Um servidor com IP fixo, deve sempre executar o servio no
mesmo computador. Para transparncia de localizao:

Clientes podem se referir a um servio pelo nome
atravs de um servidor de nomes ou de associao
(binder).

Alguns mecanismos de IPC tm a capacidade de enviar
mensagens para grupos de destinos (portas ou processos).

32
Confiabilidade: A comunicao confivel quando atende as
propriedades:

Validade: Um servio de mensagem ponto a ponto
confivel se houver garantia que as mensagem foram
entregues - independente das perdas) e no confivel se
no houver garantia de que as mensagens sejam entregues.

Integridade: As mensagens devem chegar ntegras (no
corrompidas e sem duplicao).

Ordenamento: Algumas aplicaes exigem que as mensagens
sejam entregues na ordem que foram transmitidas pelo remetente,
sendo considerada uma falha quando entregues fora da ordem.

33
um sistema de transmisso de mensagens padronizado e portvel
para funcionar em uma grande variedade de computadores
paralelos. A norma define a sintaxe e a semntica de um ncleo de
biblioteca de rotinas (primitivas) teis para uma ampla gama de
usurios que escrevem programas de transmisso de mensagens
portveis.

Caractersticas da MPI:

adaptada para a comunicao transitria;
Faz uso direto de rede subjacente;
Assume a comunicao ocorre dentro de um grupo de processos
conhecidos;
Tem um sistema de execuo esttica;

Message Passing Interface (MPI)
34
um refinamento do modelo Message Passing tradicional ao
oferecer mais opes de controle e efetivamente separar a
semntica sncrona/assncrona e bloqueio/no bloqueio da
passagem de mensagens. Uma biblioteca (MPI runtime) inserida
para apoiar a execuo de programas.

Message Passing Interface (MPI) (cont.)
MPI runtime fornece
novas primitivas send e
receive numa camada
de abstrao que
esconde a complexidade
ou variaes nos
servios oferecidos pelo
SO para tarefas
rotineiras.
35
Socket
O modelo ISO/OSI no define precisamente as interfaces entre as
camadas, mas apenas os servios a serem prestados por cada uma. A
interface entre a camada de Aplicao e a de Transporte foi definida, de
forma independente, pela Universidade da Califrnia, que projetou a
interface chamada Sockets e pela AT&T, que definiu o padro TLI
(Transport Layer Interface). A indstria adotou Sockets como padro.
36
37
Socket
O modelo ISO/OSI no define precisamente as interfaces entre as
camadas, mas apenas os servios a serem prestados por cada uma. A
interface entre a camada de Aplicao e a de Transporte foi definida, de
forma independente, pela Universidade da Califrnia, que projetou a
interface chamada Sockets e pela AT&T, que definiu o padro TLI
(Transport Layer Interface). A indstria adotou Sockets como padro.

Definio: Um socket um ponto de conexo entre a camada
de Aplicao e a de Transporte (UDP ou TCP). Constitui um
mecanismo de entrega de pacotes de dados de entrada para
o processo de aplicao adequado, com base na combinao
de endereos IP (locais e remotos) e nmeros de porta. Cada
socket mapeado pelo sistema operacional a um processo de
comunicao de aplicao.
38
Socket (cont.)
Socket caracterizado por uma nica combinao de:

Um protocolo de transferncia (UDP, TCP);

O endereo de socket local e o nmero da porta;

O endereo de soquete remoto e o nmero da porta;
39
Socket (cont.)
Comunicao no-orientada a conexo (UDP): Mtodo de
transmisso de dados onde cada pacote de dados transporta
a informao num registo de cabealho que contm um
endereo de destino suficiente para permitir a entrega
independente do pacote para o seu destino atravs da rede.
40
Socket (cont.)
Um datagrama enviado entre processo remetente e destino sem a
existncia de confirmaes ou novas tentativas de envio (falha =
mensagem perdida);

Transmitido entre processos quando um efetua um send e outro um
receive;

Primeiro um processo precisa criar uma associao entre um socket
com um IP e com uma porta do host local;

Um servidor associar seu socket a uma porta de servio e a torna
conhecida dos clientes. Um cliente vincula seu socket a qualquer porta
local livre;

Mtodo receive retorna alm da mensagem, o IP e a porta remetente,
permitindo que o destinatrio envie uma resposta a ele;
Caractersticas socket via UDP:
41
Socket (cont.)
Utilizao do UDP:
Para algumas aplicaes aceitvel usar um servio que
esteja exposto a possveis falhas por omisso (ex. DNS e
VoIP).

Datagramas UDP so escolhas atraentes pois no sofrem as
sobrecargas necessrias na entrega de mensagens com
garantia como:

1. A necessidade de armazenar informaes de estado na
origem e no destino;

2. A transmisso de mensagens extras;

3. A latncia do remetente
42
Socket (cont.)
Comunicao Orientada a Conexo (TCP): Mtodo de
comunicao de dados onde os dispositivos nos pontos finais
usam um protocolo para estabelecer uma conexo lgica ou
fsica fim-a-fim antes de iniciar a transmisso dos dados.
43
Socket (cont.)
Tamanho das mensagens: A implementao TCP decide o volume de
dados a coletar, antes de transmiti-los como um ou mais pacotes IP.

Mensagens perdidas: O protocolo TCP usa um esquema de
confirmao. Ex. Remetente mantm registro dos pacotes enviado e os
reenvia caso no receba confirmao de chegada. Sliding Window .

Controle de Fluxo: TCP tenta combinar a velocidade dos processos de
leitura e escrita num stream, bloqueando processos caso necessrio.

Duplicao e ordenamento: Mensagens so identificadas o que
permite eliminar duplicaes e realizar ordenao.

Destinos de mensagem: Uma vez estabelecida a conexo os
processos lem ou escrevem no fluxo sem necessidade de usar
endereos IP e portas.
Caractersticas socket via TCP:
44
Socket (cont.)
Utilizao do TCP:
Muitos servios so executados em conexes TCP com
nmero de porta reservados:

HTTP (80): O protocolo de transferncia de hipertexto usado para
comunicao entre navegadores e servidores web;

FTP (22): O protocolo de transferncia de arquivos permite a navegao
em diretrios em um computador remoto, e que arquivos sejam
transferidos de um computador para outro por meio de uma conexo;

Telnet: O servio telnet d acesso a um computador remoto por meio de
uma sesso de terminal;

SMTP: O protocolo de transferncia de correio eletrnico usado para
enviar correspondncia entre computadores.
45
Socket (cont.)
Resumo das caractersticas do Socket via UDP e TCP
Primitivas Socket
46
Socket (cont.)
Funes socket TCP
Funes socket UDP
47
Representao Externa de Dados e Empacotamento
Informaes armazenadas nos programas em execuo so
representadas como estruturas de dados, informaes presentes
nas mensagens so sequncias puras de bytes (serializao).

Independente da forma de comunicao usada, as estruturas de
dados devem ser convertidas em uma sequncia de bytes antes da
transmisso e reconstrudas na sua chegada.
48
Representao Externa de Dados e Empacotamento
Informaes armazenadas nos programas em execuo so
representadas como estruturas de dados, informaes presentes
nas mensagens so sequncias puras de bytes (serializao).

Independente da forma de comunicao usada, as estruturas de
dados devem ser convertidas em uma sequncia de bytes antes da
transmisso e reconstrudas na sua chegada.

Alguns problemas:

Dados transmitidos nas mensagens podem corresponder a
valores de tipos de dados primitivos diferentes (representao
big-endian e little-endian).

Codificao utilizada pode no ser a mesma (ASCII, Unicode,
etc).
49
Representao Externa de Dados e Empacotamento (cont.)
Mtodos usados para permitir que dois computadores
troquem dados binrios:

Valores so transmitidos no formato do remetente, junto
com uma indicao do formato usado, e o destinatrio
converte os valores se necessrio.
50
Mtodos usados para permitir que dois computadores
troquem dados binrios:

Valores so transmitidos no formato do remetente, junto
com uma indicao do formato usado, e o destinatrio
converte os valores se necessrio.

Os valores so convertidos para um formato externo
acordado antes da transmisso e convertidos para a
forma local na recepo.

OBS: A converso no ser necessria caso se saiba
que os pares comunicantes so do mesmo tipo.
51
Representao Externa de Dados: um padro utilizado
para a representao de estruturas de dados e valores
primitivos. Baseado nos seguintes procedimentos:

Marshalling: Procedimento realizado no remetente que
obtm um conjunto de itens de dados e os monta em um
formato conveniente (representao externa) para
transmisso em uma mensagem.

Unmarshalling: Procedimento inverso, realizado no
destinatrio, os bytes so desmontados na chegada e
estruturados para produzir um conjunto de itens de
dados equivalente no destino.
52
Estratgias para representao externa de dados:
Representao de dados atravs de CORBA, onde tipos
estruturados e primitivos de dados sofrem representao externa e
podem ser repassados como argumentos ou resultados da
invocao de mtodos remotos;
53

Serializao de objetos em Java, est relacionada a simplificao e
representao externa de dados de um objeto, ou de uma rvore
de objetos, que precise ser transmitida em uma mensagem ou
armazenada em disco;
54

Serializao de objetos em Java, est relacionada a simplificao e
representao externa de dados de um objeto, ou de uma rvore
de objetos, que precise ser transmitida em uma mensagem ou
armazenada em disco;

XML, define uma formato textual para representar dados
estruturados. Destina-se originalmente a documentos contendo
dados estruturados textuais autodescritivos (ex. documento web),
mas tambm pode ser usada para representar dados enviados em
mensagens trocadas por clientes e servidores em servios web.
55
Empacotamento no ocorre por procedimentos manuais pois
so muitos detalhes passveis de erro (mesmo para
mensagens em XML).

Em CORBA e Serializao Java tipos primitivos de dados so
empacotados de forma binria. Em XML o empacotamento
textual (geralmente maior). HTML outro exemplo de
estratgia textual.
56
Empacotamento no ocorre por procedimentos manuais pois
so muitos detalhes passveis de erro (mesmo para
mensagens em XML).

Em CORBA e Serializao Java tipos primitivos de dados so
empacotados de forma binria. Em XML o empacotamento
textual (geralmente maior). HTML outro exemplo de
estratgia textual.

Questes de projeto do empacotamento: Armazenar ou no
informaes relativas ao tipo do contedo empacotado?

CORBA inclui apenas valores dos objetos transmitidos;
Java (informaes serializadas) e XML (namespaces);
57
CORBA (Common Object Request Broker Architecture)
CDR (Common Data Representation) a representao externa de dados
mais utilizada e definida no CORBA 2.0. Outros formatos so XDR e NDR.
Exemplo de mensagem CDR
As operaes podem ser geradas automaticamente a partir da
especificao de tipos dos itens de dados a serem transmitidos em uma
mensagem. Os tipos das estruturas de dados e os tipos dos itens de dados
so descritos por uma IDL (Interface Definition Language).
Cdigo IDL correspondente
58
CORBA (Common Object Request Broker Architecture)
59
Serializao Java
Em Java o termo serializao refere-se a atividade de simplificar um objeto,
ou conjunto de objetos conectados, em uma forma sequencial conveniente
para armazenamento em disco ou transmitida em uma mensagem.
Informaes sobre a classe de cada objeto includa na forma serializada.
Exemplo de mensagem serializada Java para o objeto:
Person p = new Person("Smith", "London", 1984);
60
XML (eXtensible Markup Language)
Empresas usam Internet para criar novos sistemas que integram
seus dados visando aumentar a eficincia e reduzir custos.

O e-commerce possibilita que organizaes comercializem com
milhes de usurios. A maioria das transaes e-commerce ocorrem
entre empresas (B2B).

A XML facilita a troca de documentos estruturados pela Web ao
permitir definies das tags no suportadas pelo HTML:

Canse sensitive;
Precisa ser bem formada e devidamente aninhada;
Comentrios so indicados por <- e ->;
Prefixos XML e xml so reservados apenas para tags XML.
61
XML
XML autodescritiva e extensvel (usurios podem definir suas prprias
tags). Caso seja usada por mais de um aplicativo os nomes das tags
precisam ser combinados (SOAP - publicao de tags para uso em web
services).
Definio em XML da Estrutura Person
62
XML autodescritiva e extensvel (usurios podem definir suas prprias
tags). Caso seja usada por mais de um aplicativo os nomes das tags
precisam ser combinados (SOAP - publicao de tags para uso em web
services). XML Schema define caractersticas como visibilidade de
atributos, aninhamento ordem e nmero de elementos, tipo e valor.

Exemplo de XML Schema para estrutura Person
XML
63
XML Schemas
Linguagem avanada de definio de dados;

Descreve a estrutura de documentos de dados XML.

Definies XML Schema so feitas dentro do arquivo XML.

Vantagem do XML Schema:

til para aplicaes EDI (Eletronic Data Interchange)

Mapeamento mais prximo da terminologia e
caractersticas de banco de dados.

Arquivo XML Schema Definition (XSD) usa sintaxe
semelhante ao documento XML.
64
XML Schema de um documento
65
Arquivo com a extenso .dtd que descreve elementos;

Fornece composio do modelo lgico de um sistema,
documento ou banco de dados;

Define regras de sintaxe ou tags vlidas para cada tipo de
documento XML;

Empresas envolvidas em transaes e-commerce necessitam
desenvolver e compartilhar DTDs;

Definies DTD so feitas em um arquivo separado (.dtd),
referenciados no documento XML.
DTD (Document Type Definitions)
66
D
o
c
u
m
e
n
t
o

D
T
D

D
o
c
u
m
e
n
t
o

X
M
L

67
68
Multicast Communication
A troca de mensagens em pares no o melhor modelo para a
comunicao de um processo com um grupo de outros processos
(ex. servio para tolerncia a falhas ou aumento de disponibilidade).
Uma operao de multicast
envia uma mensagem a
partir de um nico processo
para cada um dos membros
de um grupo de processos
de tal maneira que a
composio do grupo
transparente para o
remetente.
69
Multicast Communication (cont.)
Mas por que usar multicast?

Se existem dados que devem ser enviados a vrios
pontos, possvel atingir este objetivo utilizando-se
de uma sequncia de transferncias ponto-a-ponto
(no eficiente).
70
Mas por que usar multicast?

Se existem dados que devem ser enviados a vrios
pontos, possvel atingir este objetivo utilizando-se
de uma sequncia de transferncias ponto-a-ponto
(no eficiente).

Justificativa: Servios baseados em multicast
provm uma diminuio de trfego de rede, habilitam
a descoberta de recursos, alm de serem mais
adequados em videoconferncias.
71
Existem faixas de endereos IP reservados para Multicast:

IP Classe D: Os endereos multicast esto no range
224.0.0.0 at 239.255.255.255.
Caractersticas quanto associao de hosts a grupos:

A associao a um grupo dinmica: hosts podem participar ou
abandon-los a qualquer momento.

No h restrio quanto ao posicionamento geogrfico ou nmero de
membros em um grupo de hosts.

Um host pode ser membro de um ou mais grupos ao mesmo tempo.

Um host no precisa ser membro de um grupo para enviar
datagramas a ele.
72
Roteamento Multicast na Internet

O roteamento de datagramas IP multicast na Internet feiro por
roteadores multicast que podem coexistir ou no com gateways.

Um host transmite um datagrama IP multicast na rede local, sendo
que este alcana todos os membros vizinhos do grupo de host
destino.

Se o datagrama possui um TTL maior que 1, o roteador multicast
associado a esta rede tem a responsabilidade de repass-lo a todas
as outras redes que possuam membros deste grupo destino.

Nas redes alcanveis pelo TTL, o roteador multicast a elas
associado completa a entrega transmitindo o datagrama como um
multicast local aos membros do grupo.
73
Caractersticas

A tolerncia a falhas: Solicitaes do cliente so enviadas
por mensagens multicast a um grupo de servidores
executando operaes idnticas. Caso um servidor falhe
outros podem atender o cliente.

Descoberta de servios em rede: Mensagens multicast
podem ser usadas por servidores e clientes para localizar
servios de descoberta disponveis, a fim de registrar suas
interfaces ou para procurar as interfaces de outros servios
no sistema distribudo.
74
Caractersticas (cont.)

Melhoria de desempenho: Dados podem ser replicados
para aumentar o desempenho de um servio. Cada vez que
ocorre alteraes nos dados, o novo valor enviado por
multicast aos processos que fazem a gesto das rplicas.

Propagao de notificaes de eventos: Multicast pode
ser usado para notificar os processos quando algo
acontece. Ex. Facebook, quando algum altera o seu
status, todos os seus amigos recebem notificaes. Da
mesma forma, protocolos publish/subscribe podem fazer
uso de multicast para divulgar eventos para assinantes.
IP Multicast (cont.)

No nvel da aplicao IP multicast est disponvel apenas via UDP.
Um aplicativo executa multicast atravs do envio de datagramas
UDP com o multicast a endereos e nmeros de porta comuns. O
aplicativo pode participar de um grupo multicast, fazendo seu socket
se juntar ao grupo, permitindo-lhe receber mensagens para o grupo.

Ao nvel de IP, um computador pertence a um grupo multicast
quando um ou mais dos seus processos tem sockets que pertencem
a este grupo. Quando uma mensagem multicast chega a um
computador, as cpias so encaminhadas para todos os sockets
locais que aderiram ao endereo multicast especificado e que esto
vinculados ao nmero de porta especificado.
75
4. Comunicao em SDs Remote Invocation
76
Remote Invocation
77
4. Comunicao em SDs
Taxonomia da
Distribudos
78
Request-Reply
79
Request-Reply
A forma de comunicao Request-Reply (Requisio-
Resposta) foi projetada para suportar as funes e trocas de
mensagens em tpicas interaes Cliente/Servidor.

80
Request-Reply
A forma de comunicao Request-Reply (Requisio-
Resposta) foi projetada para suportar as funes e trocas de
mensagens em tpicas interaes Cliente/Servidor.

No caso mais comum, a comunicao Request-Reply
sncrona, pois o processo cliente bloqueia at que a resposta
do servidor chegue. um protocolo confivel j que a
resposta efetivamente a confirmao de que a requisio
chegou ao servidor.

A comunicao de requisio de resposta assncrona uma
alternativa til em situaes onde os clientes podem recuperar
as respostas posteriormente.
81
Request-Reply
Para o mtodo request-reply, um protocolo construdo sobre
UDP evita as sobrecargas desnecessrias associadas ao TCP
como:

As confirmaes so redundantes, pois as requisies
so seguidas pelas respostas;

O estabelecimento de uma conexo envolve mensagens
extras, alm do par exigido para a requisio e sua
resposta;

O controle de fluxo redundante para a maioria das
invocaes, que passam apenas pequenos argumentos
e resultados.
82
Request-Reply
O protocolo request-reply baseado em trs primitivas de
comunicao: doOperation, getRequest e sendReply.
83
Request-Reply
public byte[] doOperation(RemoteObjectRef o, int methodId, byte[] arguments)
envia uma mensagem de requisio para um objeto remoto e retorna a resposta. Os
argumentos especificam o objeto remoto, o mtodo a ser invocado e os argumentos desse
mtodo.

public byte[] getRequest();
l uma requisio de cliente por meio da porta de servidor.

public void sendReply (byte[] reply; InetAddress clientHost, int clientPort);
envia a mensagem de resposta para o cliente em seu respectivo endereo IP e porta.
Operaes do Protocolo Requisio-Resposta
84
Request-Reply
O protocolo request-reply projetado justamente para associar respostas
as suas correspondentes requisies, podendo ainda ser projetado de
forma a fornecer garantias quanto a entrega das mensagens.
Se forem usados datagramas UDP, as garantias de entrega devero ser
fornecidas pelo protocolo request-reply, que pode usar a resposta do
servidor como confirmao da requisio feita pelo cliente.
public byte[] doOperation(RemoteObjectRef o, int methodId, byte[] arguments)
envia uma mensagem de requisio para um objeto remoto e retorna a resposta. Os
argumentos especificam o objeto remoto, o mtodo a ser invocado e os argumentos desse
mtodo.

public byte[] getRequest();
l uma requisio de cliente por meio da porta de servidor.

public void sendReply (byte[] reply; InetAddress clientHost, int clientPort);
envia a mensagem de resposta para o cliente em seu respectivo endereo IP e porta.
Operaes do Protocolo Requisio-Resposta
85
Request-Reply Mtodos
doOperation: usado pelos clientes para invocar operaes
remotas. Seus argumentos indicam o IP e Porta, bem como a
referncia ao objeto remoto (remoteObjectRef) e o mtodo a ser
executado, junto com os argumentos exigidos pelo mtodo.
Seu resultado uma resposta RMI, onde na execuo do
doOperation os argumentos so empacotados e
desempacotados em um array de bytes.
Representao de uma referncia de objeto remoto
86
doOperation (cont.): Aps enviar a mensagem de requisio, o
doOperation faz um receive para obter uma mensagem de
resposta de onde ela extrai o resultado e encaminha ao
chamador. Chamador doOperation bloqueado at o
recebimento da resposta.
87
doOperation (cont.): Aps enviar a mensagem de requisio, o
doOperation faz um receive para obter uma mensagem de
resposta de onde ela extrai o resultado e encaminha ao
chamador. Chamador doOperation bloqueado at o
recebimento da resposta.
getRequest: Usado por um processo servidor para ler as
requisies de servio. O servidor usar o mtodo sendReply
para enviar a resposta ao cliente, que ao receb-la
desbloqueia doOperation e o programa continua a execuo.
88
As informaes a serem transmitidas em uma mensagem de
requisio ou resposta so estruturadas conforme ilustrado a
seguir:
Indica se a mensagem Request ou Reply
89
seguir:
Contm um identificador de mensagem. Gerado pelo
doOperation e utilizado pelo servidor nas respostas
correspondentes.
90
seguir:
Referncia a um objeto remoto (igual ao modelo do
slide 67)
91
seguir:
Identificador do mtodo a ser invocado.
92
Request-Reply Modelo de falhas
Se as trs primitivas doOperation, getRequest e sendReply forem
implementadas sob UDP, ento sofrero das mesmas falhas
desse protocolo (falhas por omisso, sem garantia de entrega
na ordem). Falhas devero ser tratadas pelo programador.
93
Para casos de falha no servidor, doOperation utiliza um timeout
para limitar a espera de uma resposta do servidor.
94
Para casos de falha no servidor, doOperation utiliza um timeout
para limitar a espera de uma resposta do servidor.
No caso em que a mensagem de requisio retransmitida
(resposta demorou mais que timeout) poder ocorrer
duplicatas no servidor. O protocolo pode evitar isso ao
reconhecer mensagens sucessivas do mesmo cliente que
possuam o mesmo identificador de requisio.
95
Perda de Mensagens de resposta. Se o servidor j tiver
enviado a resposta quando receber uma requisio duplicata,
ele precisar executar a operao novamente para obter o
resultado.
96
Perda de Mensagens de resposta. Se o servidor j tiver
enviado a resposta quando receber uma requisio duplicata,
ele precisar executar a operao novamente para obter o
resultado.

Operao idempotente aquela que pode ser executada
repetidamente com o mesmo efeito se tiver sido executada
uma nica vez (ex. incluir um objeto num conjunto).
Um servidor onde todas suas operaes so idempotentes
no necessita adotar medidas especiais para evitar as suas
execues mais de uma vez.
97
Para servidores que exigem retransmisso de operaes sem
execut-las novamente, pode ser usado um histrico, que
uma estrutura que contm o registro das mensagens que
foram transmitidas.
Uma entrada em um histrico contm um Id de requisio,
uma mensagem e um Id do cliente destinatrio. O objetivo
permitir que o servidor retransmita a mensagem quando o
cliente solicitar.

Um problema do histrico o consumo de memria devido a
grande quantidade de mensagens de resposta, principalmente
se o servidor possuir muitos clientes.
98
Protocolos RPC
Trs protocolos, que produzem diferentes comportamentos na
presena de falhas de comunicao:

Request (R);
Requesty-Reply (RR);
Requesty-Reply-Acknowledge-Reply (RRA);
Resumo das mensagens enviadas pelos protocolos RPC
99
Protocolos RPC
Request (R): Usado quando no existe nenhum valor a ser
retornado pelo mtodo remoto e o cliente no exige confirmao
se o mtodo foi executado. Cliente no espera pela resposta para
continuar suas execues. Operao no bloqueante.
100
Protocolos RPC

Requesty-Reply (RR): Resposta do servidor considerada
uma confirmao do recebimento da mensagem de requisio do
cliente (e vice versa). Falhas de comunicao podem ser
mascaradas (filtragem replicada e histrico). Operao
bloqueante.
101
Protocolos RPC

Requesty-Reply (RR): Resposta do servidor considerada
uma confirmao do recebimento da mensagem de requisio do
cliente (e vice versa). Falhas de comunicao podem ser
mascaradas (filtragem replicada e histrico). Operao
bloqueante.

Requesty-Reply-Acknowledge-Reply (RRA): Troca de trs
mensagens. A mensagem de confirmao contm a requestId da
mensagem de resposta que est sendo confirmada. Isso permitir
que o servidor descarte entradas do histrico. No bloqueante,
mas ocupa recursos de rede e processamento.
102
TCP no protocolo Requesty-Reply
O comprimento limitado dos datagramas UDP pode no ser
adequado a sistemas transparentes de RMI pois os
argumentos e resultados podem ser de qualquer tamanho.
O TCP utilizado quando se deseja evitar protocolos que
quebram requisies e respostas em mltiplos pacotes. O TCP
permite que argumentos e resultados de qualquer tamanho
sejam enviados.
TCP simplifica a implementao de protocolos requisio-
resposta, alm de reduzir o procedimento de conexo no envio
de cada mensagem (estabelecimento de um fluxo).
103
Remote Procedure
Call
104
RPC (Remote Procedure Call)
Integra o protocolo Request-Reply usado para comunicao
Cliente/Servidor com as linguagens de programao
convencionais permitindo que clientes comuniquem-se com
servidores atravs de chamadas de procedimentos.
105
Integra o protocolo Request-Reply usado para comunicao
Cliente/Servidor com as linguagens de programao
convencionais permitindo que clientes comuniquem-se com
servidores atravs de chamadas de procedimentos.

A chamada remota segue o modelo da chamada local sendo
que o procedimento chamado executa um processo em um
computador localizado remotamente.

No nvel de RPC o servio fornecido por um servidor pode ser
visto como um modulo com uma interface que exporta a
funcionalidade apropriada. Ex: um servio de arquivo (read,
write, open, close, etc).
106
Similar ao RMI pois um processo cliente chama um
procedimento que est sendo executado em um processo
servidor.

Servidores podem ser clientes de outros servidores para
permitir o encadeamento de RPCs.
107
Similar ao RMI pois um processo cliente chama um
procedimento que est sendo executado em um processo
servidor.

Servidores podem ser clientes de outros servidores para
permitir o encadeamento de RPCs.

Um processo servidor define em sua interface de servios os
procedimentos que esto disponveis para serem chamados
de forma remota (ele tem estado e mtodos).

No tem a capacidade de criar novas instncias de objetos e,
portanto, no suporta referncias de objeto remoto.
108
Chamada de
Procedimento
Local
Chamada de
Procedimento
Remoto
109
O contedo das mensagens Request-Reply RPC igual ao do
RMI exceto pelo campo ObjectReference que foi omitido.

O RPC suportado da forma como seria uma linguagem
procedural como C, que no suporta classes e nem objetos.
110
111
Caractersticas:

1. RPC segue o modelo sinttico e semntico de
chamada local de procedimento.

2. Especifica parmetros de entrada e sada.

3. Equivalncia total em parmetros por valor.

4. Executada em ambiente diferente do chamador.

5. No tem acesso a recursos do chamador como:

Variveis globais

Endereos enviados pelo chamador
112
O mecanismo de RPC transparente para o usurio.

Chamador suspenso (bloqueado), passa parmetros e
recebe os resultados.

Conseguir a mesma semntica praticamente impossvel
pois:

Execuo em espao de endereamento disjunto;

Vulnerabilidade a falhas;

Consome mais tempo;
113
Comparao entre o RPC e o RMI
114
RPC Semntica de Chamada
Visa fornecer diferentes nveis de garantia de entrega:

1. Maybe (sem garantias): Se a resposta no foi recebida depois de um
timeout e no existem retransmisses, no existe garantias da execuo do
procedimento remoto.
115


2. At least once (pelo menos uma vez): Retransmite requisies sem filtrar
possveis duplicatas.

Cliente pode receber uma resposta de recebimento ok ou falha.

Cliente no saber quantas vezes o procedimento remoto foi chamado.
116


2. At least once (pelo menos uma vez): Retransmite requisies sem filtrar
possveis duplicatas.

Cliente pode receber uma resposta de recebimento ok ou falha.

Cliente no saber quantas vezes o procedimento remoto foi chamado.

3. At most once (no mximo uma vez): Usado em operaes no
idempotentes, possibilita filtragem de possveis duplicatas e retransmisso de
respostas sem reexecutar as operaes.

Ex. Uma operao para retirar R$100 de uma conta corrente no
idempotente, j que deveria ser executada apenas uma vez.
117
RPC - Funcionamento
a := 1;
b := 3;
c := foo(a, b);
printf(%d,c);
foo(a, b);
// computacao
//
// x := a*b;
return(x);
Objetivo do RPC converter uma chamada local em uma
chamada remota;

Um processo A chama um processo B;

A permanece bloqueado enquanto aguarda a resposta de B;

Operao transparente para a Aplicao;
Processo A Processo B
118
RPC - Funcionamento
Para conseguir a transparncia o mecanismo de RPC
baseado no conceito de stubs, que permite a abstrao da
chamada.

Componentes da implementao de um mecanismo RPC:

1. Cliente

2. Stub cliente

3. RPC runtime

4. Stub servidor (Skeleton)

5. Servidor
119
RPC - Funcionamento
RPC possui um princpio semelhante ao de uma System Call.
120
RPC - Funcionamento
121
RPC - Funcionamento
Marshalling: Procedimento que consiste
em transformar, no emissor, uma coleo
de dados em um formato adequado para a
transmisso em uma mensagem.
122
RPC - Funcionamento
Unmarshalling: Procedimento inverso ao
marshalling no receptor, permitindo
desmontagem da mensagem e
recuperao do formato original dos dados
transmitidos.
123
RPC - Funcionamento
124
RPC - Funcionamento
Processamento no Cliente

Pedido:

Constri a mensagem (parameter marshalling);
Envia-a (usando sendto()) para o servidor;
Bloqueia a funo a espera da resposta (usando
recvfrom()).

Resposta:

Recebe a resposta;
Extrai os resultados (unmarshalling);
Retorna-os ao cliente.
125
RPC - Funcionamento
Processamento no Servidor

Pedido:

Recebe mensagem com pedido;
Extrai argumentos;
Invoca a funo.

Resposta:

Constri mensagem com resultado da invocao da
funo;
Envia mensagem;
Bloqueia a espera de novo pedido.
126
RPC - Funcionamento
Dispatcher
Mecanismo de controle utilizado caso exista mais de uma funo
remota. Dispatcher responsvel por direcionar o pedido do cliente
para a funo correta cuja identificao feita pelo par
servio/nome da funo.
127
RPC - Funcionamento
XDR
Linguagem, com semelhanas C, que permite descrio dos
dados (RFC 1832).
Dois componentes:

Compilador para C++ (rpcgen).

Linguagem de Interface XDR: Inicialmente criada para
Representao Externa de Dados, atualmente uma
interface que especifica definies de procedimentos e de tipos
de dados suportados.
Usado na transferncia de dados entre arquiteturas distintas.
128
XDR
1) Utiliza nmeros de programa e nmero de verso ao invs de nomes de
interface. Nmeros de programa podem ser obtidos a partir de uma
autoridade central para garantir unicidade.

Nmero de verso muda quando uma assinatura de procedimento
alterada. Nmero de programa e nmero de verso so passados na
mesma mensagem de requisio para verificar se esto usando a mesma
verso.

2) Definio de um procedimento especifica assinatura e um nmero que
usado como identificador de procedimento.

3) Parmetros: Entrada: Apenas um parmetro de entrada. Para vrios
parmetros devem ser includos como membros de uma nica estrutura.
Sada: So retornados por meio de um nico resultado.

4) Assinatura do Documento: Tipo do Resultado + Nome do Procedimento +
Tipo de Parmetro de Entrada.
129
XDR
I
n
t
e
r
f
a
c
e
s

d
e

P
r
o
c
e
d
i
m
e
n
t
o
s

n
a

X
R
D

(
S
u
n
)

130
XDR
I
n
t
e
r
f
a
c
e
s

d
e

P
r
o
c
e
d
i
m
e
n
t
o
s

n
a

X
R
D

(
S
u
n
)

Dois procedimentos: READ e WRITE.
131
XDR
I
n
t
e
r
f
a
c
e
s

d
e

P
r
o
c
e
d
i
m
e
n
t
o
s

n
a

X
R
D

(
S
u
n
)

Nmero da verso = 2
Nmero do Programa = 9999
132
XDR
I
n
t
e
r
f
a
c
e
s

d
e

P
r
o
c
e
d
i
m
e
n
t
o
s

n
a

X
R
D

(
S
u
n
)

READ recebe como parmetro:

Entrada: Uma estrutura com 3
componentes (ID de Arquivo, Posio do
Arquivo), Nmero de bytes a serem
lidos).

Resultado: Estrutura contendo o nmero
de bytes retornados e os dados do
arquivo.
133
XDR
I
n
t
e
r
f
a
c
e
s

d
e

P
r
o
c
e
d
i
m
e
n
t
o
s

n
a

X
R
D

(
S
u
n
)

A IDL define constantes, typedefs,
estruturas, tipos enumerados, unies e
programas.
Sintaxe C
134
XDR
O compilador da interface (rpcgen) gera o seguinte:

procedimento stub no cliente;

procedimento main, dispatcher e procedimentos stub
no servidor;

procedimento de marshalling e unmarshalling de
XDR a serem usados pelo dispatcher e pelo stub
cliente e servidor.
135
Binding
RPC executa em cada computador um servio de vinculao local
(port mapper) em um nmero de porta bem conhecido (rpcbind 111).

Cada instncia de um port mapper grava o N do programa, n da
verso e o n da porta para cada servio em execuo.
136
Binding
Quando um servio tem vrias instncias sendo executadas
em diferentes computadores, interfaces usam diferentes
nmeros de porta para receber requisies.

Uma mensagem multicast pode ser enviada para todos os port
mappers caso um cliente precise enviar uma requisio para
todas as instncias do servio.

Cada port mapper encaminha tais chamadas para o programa
de servio local apropriado.
137
RPC e Falhas
Possveis Problemas que podem ocorrer em uma RPC:

Requisio perdida

Resposta perdida

Servidor falha aps receber requisio

Cliente falha aps enviar requisio
138
RPC e Falhas
Possveis Problemas que podem ocorrer em uma RPC:

Cliente

Temporizar requisies.

Percebe falta de resposta e retransmite a requisio.

Servidor

Recebe, processa e envia a resposta a primeira vez.

Se recebe novamente a mesma requisio, retransmite
a resposta sem repetir o processamento.
139
RPC - Implementao
rpcgen

uma ferramenta capaz de gerar:

Rotinas de adaptao (tanto do cliente quanto do servidor);

Esqueletos dos programas cliente e servidor;

Requer como entrada uma especificao incluindo:

A especificao das funes remotas (i.e., os seus
prottipos);

A definio de tipos de valores e das constantes passados ou
retornados por essas funes.
140
RPC - Implementao
rpcgen
141
Sada de rpcgen -a -C -N date.x

date.h header file com os prottipos das funes e a definio de
constantes e de tipos.

date_clnt.c rotina de adaptao do cliente (funo de interface rotina
de adaptao).

date_svc.c esqueleto do programa servidor, incluindo dispatcher, e rotina
de adaptao do servidor.

date_xdr.c funes auxiliares para converter estruturas de dados
complexas entre o formato nativo e XDR.

date_client.c esqueleto de programa cliente, incluindo
Invocao de cada uma das funes remotas.

date_server.c funes envelope das funes remotas.

Obs: Geralmente no se altera 4 primeiros arquivos.
142
RPC - Implementao
rpcgen e o Desenvolvimento de Aplicaes Baseadas em
RPC

1. Identificar as funes remotas e definir os seus prottipos.

2. Definir os prottipos das funes remotas, dos tipos e constantes
necessrias em RPCL.

3. Executar rpcgen.

4. Escrever as funes remotas (i.e. do servidor), possivelmente a partir
das funes em _server.c.

5. Compilar a aplicao servidora.

6. Escrever a aplicao cliente, possivelmente a partir das funes em
_client.c.

7. Compilar a aplicao cliente.
143
RPC - Implementao
Exemplo: Funo remota de Tempo
struct timeval_
{
long tv_sec;
long tv_usec;
};

program TEMPOPROG
{
version TEMPOVERS
{
timeval_ TEMPO(void)=1;
}=1;
}=0x20000001;
tempo.x
id do programa
[0x20000000, 0x3fffffff]
podem ser atribudos por programadores
Representao Externa de Dados - XDR
144
RPC - Implementao
Implementao do procedimento no Lado Servidor
#include <stdio.h>
#include <sys/time.h>
#include "tempo.h

// Definio do prottipo em tempo.h
timeval_ * tempo_1_svc(void *a, struct svc_req *b)

{
static struct timeval tempo;
// precisao em micro segundos ...
gettimeofday(&tempo, NULL);
return (timeval_ *)&tempo;
}
tempo_procedimentos.c
145
RPC - Implementao
Implementao do procedimento no Lado Cliente (1/2)
#include <stdio.h>
#include <rpc/rpc.h>
#include "tempo.h"

int main(int argc, char **argv){
CLIENT *c;
char *servidor;
if (argc != 2){
printf ("uso: %s <ip_servidor>", argv[0]);
return 0;
}
servidor = argv[1];
c = clnt_create(servidor, TEMPOPROG, TEMPOVERS, "tcp");
if (!c){
clnt_perror(c, servidor);
return 0;
}
.
.
.
Cliente.c
146
RPC - Implementao
.
.
.
struct timeval *result;
result = (struct timeval *)tempo_1(NULL, c);
if (!result) {
clnt_perror(c, servidor);
return 0;
}
printf("tempo segundos: %ld, microssegundos: %ld\n", result->tv_sec, result->tv_usec);
return 0;
}
Cliente.c
#> rpcgen tempo.x
#> gcc -Wall -o cliente cliente.c tempo_clnt.c tempo_xdr.c
#> gcc -Wall -o servidor tempo_procedimentos.c tempo_svc.c tempo_xdr.c
Compilao
Implementao do procedimento no Lado Cliente (2/2)
147
Exerccio
Faa um programa em C utilizando RPC que l um arquivo em um servidor
e retorne o contedo de um determinado registro.
Instrues:

No servidor dever existir um arquivo que contm registros de
funcionrios de uma empresa. Ex:

001 Jimi Hendrix Soldador
002 Amy Winehouse Estagiria
003 Valesca Popozuda Gerente

No cliente dever ser digitado um nmero de matrcula. O servidor
recebe a solicitao, chama o mtodo que obtm o registro a partir do
arquivo e retorna para o cliente o nome e o cargo do funcionrio.

O programa dever ser apresentado pela dupla na prxima aula.
responsabilidade da dupla preparar o ambiente para apresentao do
exerccio.
148
Remote Method
Invocation
149
Remote Invocation
Objetos que podem receber invocaes a mtodos remotos
so chamados de objetos remotos e implementam uma
interface remota.
A camada de middleware usa protocolos baseados em
mensagens entre processos para fornecer suas abstraes de
mais alto nvel como as invocaes a eventos remotos.
Aplicativos
Sistema Operacional
RMI, RPC e eventos
Protocolo Request-Reply
Representao externa de dados
Camada do
middleware
150
Interfaces
A maioria das linguagens fornece uma maneira de organizar
um programa em mdulos que podem se comunicar. A
comunicao entre os mdulos pode ser feita:

Por meio de chamadas de procedimento entre eles;

Pelo acesso direto s variveis de outro mdulo.
A interface de um mdulo especifica os procedimentos e as
variveis que podem ser acessadas a partir de outros mdulos.
151
Interfaces
A maioria das linguagens fornece uma maneira de organizar
um programa em mdulos que podem se comunicar. A
comunicao entre os mdulos pode ser feita:

Por meio de chamadas de procedimento entre eles;

Pelo acesso direto s variveis de outro mdulo.
A interface de um mdulo especifica os procedimentos e as
variveis que podem ser acessadas a partir de outros mdulos.
Os mdulos so implementados de forma a ocultar suas
informaes construtivas, menos as que estiverem disponveis
explicitamente por intermdio de sua interface.
152
Interfaces
Em um programa distribudo, os mdulos podem ser
executados em processos separados. No possvel um
mdulo ser executado em um processo e acessar as variveis
de um mdulo em outro processo (troca de contexto).
153
Interfaces
Em um programa distribudo, os mdulos podem ser
executados em processos separados. No possvel um
mdulo ser executado em um processo e acessar as variveis
de um mdulo em outro processo (troca de contexto).
A passagem de parmetros usados em mtodos locais
(chamada por valor ou por referncia) no so convenientes
para processos diferentes.
A especificao de um procedimento na interface de um
mdulo de um programa distribudo descreve os parmetros
como sendo de entrada ou de sada.
154
Interfaces
Parmetros de Entrada: So passados para o mdulo remoto
atravs do envio dos valores dos argumentos na mensagem
de requisio, e ento, repassados como argumentos para
operao a ser executada no servidor.
155
Interfaces
Parmetros de Sada: So retornados na mensagem de
resposta e usados como resultado da chamada, ou para
substituir os valores das variveis correspondentes no
ambiente de chamada.
OBS: Variveis tipo ponteiro no so vlidas em outro
processo remoto e por isso no podem ser passados como
argumentos e nem retornados como resultados.
Parmetros de Entrada: So passados para o mdulo remoto
atravs do envio dos valores dos argumentos na mensagem
de requisio, e ento, repassados como argumentos para
operao a ser executada no servidor.
156
RMI (Remote Method Invocation)
O modelo baseado em objetos para um SD estende o modelo
suportado por linguagens de programao OO para aplic-lo
em objetos distribudos.
Os sistemas de objetos distribudos podem adotar a arquitetura
cliente/servidor, nesse caso os objetos so gerenciados pelo
servidor e seus clientes invocam seus mtodos usando
invocao a mtodo remoto (RMI), onde:
157
RMI (Remote Method Invocation)
O modelo baseado em objetos para um SD estende o modelo
suportado por linguagens de programao OO para aplic-lo
em objetos distribudos.
Os sistemas de objetos distribudos podem adotar a arquitetura
cliente/servidor, nesse caso os objetos so gerenciados pelo
servidor e seus clientes invocam seus mtodos usando
invocao a mtodo remoto (RMI), onde:
A requisio de um cliente para invocar um mtodo de um
objeto enviada via mensagem para um servidor que
gerencia o objeto.

A invocao realizada pela execuo do mtodo e o
resultado retornado para o cliente em outra mensagem.
158
Modelo de Objeto Distribudo
Cada processo contm um conjunto de objetos, alguns dos
quais podem receber invocaes remotas, enquanto outros
podem receber apenas invocaes locais.
Invocaes a mtodos remotos: Invocaes a mtodos entre
objetos em diferentes processos (no mesmo computador ou
no).
159
Objetos remotos, so os que podem receber invocaes
remotas. Todos os objetos podem receber invocaes locais
de outros objetos que contenham referncias a eles. Conceitos
fundamentais:
Referncia de objeto remoto: Outros objetos podem
invocar mtodos de um objeto remoto, se tiverem acesso
sua referncia de objeto remoto. Ex. Uma referncia de
objeto remoto de B deve estar disponvel para A.
160
Objetos remotos, so os que podem receber invocaes
remotas. Todos os objetos podem receber invocaes locais
de outros objetos que contenham referncias a eles. Conceitos
fundamentais:
Referncia de objeto remoto: Outros objetos podem
invocar mtodos de um objeto remoto, se tiverem acesso
sua referncia de objeto remoto. Ex. Uma referncia de
objeto remoto de B deve estar disponvel para A.
Interface Remota: Todo objeto remoto tem uma interface
remota especificando qual de seus mtodos pode ser
invocado de forma remota. Ex. Os objetos B e F devem
ter interfaces remotas
161
RMI Java
Java contm um pacote que permite que objetos em execuo
em uma JVM invoquem mtodos de objetos rodando em outra
JVM.
JVM 1

Mtodo()
objeto
JVM 2

Mtodo()
objeto
162
RMI Java
Java contm um pacote que permite que objetos em execuo
em uma JVM invoquem mtodos de objetos rodando em outra
JVM.
JVM 1

Mtodo()
objeto
JVM 2

Mtodo()
objeto
Objetivo: Prover suporte para comunicao de objetos Java
atravs de seus mtodos, independentemente da localizao
desses objetos (transparncia de localizao).
163
RMI Java
Para obter transparncia de localizao necessrio que
exista um mecanismo que oculte os aspectos de programao
em rede envolvidos no desenvolvimento de aplicaes cliente-
servidor.
Implementao da transparncia de localizao feita
atravs de duas entidades:

Stub

Skeleton
164
RMI Java
Client Stub
Reside na mquina cliente.

Recebe chamadas locais a mtodos
remotos;

Ajusta estas chamadas para serem
transferidas via rede para a mquina
onde se localiza o objeto remoto.

Recebe o resultado da invocao de
um mtodo e o transfere para o objeto
local.
JVM 1

Mtodo()
objeto
Stub
165
RMI Java
Server Skeleton
Reside na mquina servidora;

Aceita conexes estabelecidas por um
stub;

Traduz os dados recebidos por esta
conexo em chamadas para um
objeto local.

Transfere o resultado da invocao do
mtodo para a mquina remota.
JVM 2

Mtodo()
objeto
Skeleton
166
RMI Java - Arquitetura
JVM 2

Mtodo()
objeto
Skeleton
JVM 1

Mtodo()
objeto
Stub
Internet
167
Gerao do Stub e do Skeleton
Stub e Skeleton so gerados automaticamente por um
utilitrio chamado rmic a partir da definio de uma classe
remotamente acessvel.
168
Criao de classes remotamente acessveis

1) Em uma interface se declara os mtodos que se deseja tornar pblicos;

2) A classe a ser criada deve ento implementar esta interface;
169
Criao de classes remotamente acessveis

1) Em uma interface se declara os mtodos que se deseja tornar pblicos;

2) A classe a ser criada deve ento implementar esta interface;
Ex: Define-se a interface x.
A seguir, cria-se a classe y
(remotamente acessvel) da
seguinte maneira:
public class y implements x
{
//...
}
y.java
170
Criao de classes remotamente acessveis (cont.)

Aps a implementao da classe "y", gera-se o stub e o skeleton
para esta classe atravs das seguintes compilaes:

#> javac y.java
#> rmic y
171


#> javac y.java
#> rmic y
Como o cliente obtm um stub para se comunicar com um
objeto remoto?
172


#> javac y.java
#> rmic y
objeto remoto? RMI implementa um servio de registro de nomes.

Como enderear os diferentes objetos remotos existentes em
uma mesma mquina?
173


#> javac y.java
#> rmic y
objeto remoto? RMI implementa um servio de registro de nomes.

Como enderear os diferentes objetos remotos existentes em
uma mesma mquina? Objetos so endereados por:

nome_host + nome_objeto
174
Servio de Nomes
A primeira ao realizada por um cliente que deseja fazer
chamadas a um objeto remoto procurar pelo objeto no
servidor de nomes RMI (rmiregistry).
server
rmi://server/name
client
name
Naming Registry
Remote Object
Referncia
Remota
Internet
175
Comunicao entre os componentes do Sistema
RMI
176
RMI Java - Implementao
Exemplo: Daytime

Neste exemplo ser abordado:

Como registrar o nome de um objeto pblico no servio
de registro de nomes;

Como o gerar o stub e o skeleton de uma classe
remotamente acessvel;

Como um cliente obtm uma referncia remota a um
objeto;
177
Exemplo: Daytime

Passos para criao do servidor:

Definio da interface remota;
Implementao da interface remota (objeto);
Registro do objeto remoto no servio de nomes;
Execuo do servidor de registro de nomes;
Execuo do servidor de Daytime;

Passos para criao do cliente:

Implementao de um cliente;
Execuo do cliente;
178
O Objeto Remoto

Objeto implementado de forma a aceitar chamadas de
mtodos feitas por outro objeto que esteja executando em
uma mquina remota.

A implementao feita atravs da escrita de uma interface
que descreve os mtodos pblicos do objeto remoto.

A classe que define o objeto deve implementar esta
interface.

Interface deve estender a classe java.rmi.Remote.
179
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.Date;

public interface DateServer extends Remote {
public Date getDate () throws RemoteException;
}
DateServer.java
Todos os mtodos declarados em uma interface remota
podem gerar excees do tipo RemoteException.
Implementao do Servidor
Define uma interface que descreve quais mtodos do objeto
remoto devem ser acessveis aos clientes.
180
Aps a definio da interface deve-se fazer a implementao
da mesma, que consiste na implementao do objeto
remoto.

Classe que define o objeto remoto deve:

Estender a interface java.rmi.server. RemoteObject

Em geral usa-se a interface UnicastRemoteObject.

Implementar as interfaces remotas

No caso do exemplo apenas interface remota chamada
DataServer.
181
Implementao da Interface do Objeto Remoto no Servidor
import java.rmi.server.UnicastRemoteObject;
import java.rmi.RMISecurityManager;
import java.rmi.RemoteException;
import java.rmi.Naming;

public class DateServerImpl extends UnicastRemoteObject implements DateServer {
public DateServerImpl () throws RemoteException {
}
public Date getDate () {
return new Date ();
}

public static void main (String args[]) throws Exception {
DateServerImpl dateS = new DateServerImpl ();
Naming.bind ("DateServer", dateS);
}
}
DateServerImpl.java
182

Passo 1: Compilar a Classe DateServerImpl

javac DateServerImpl.java

Passo 2: Usar o utilitrio rmic passando o nome da classe
como parmetro

rmic DateServerImpl

Sero gerados dois arquivos .class

DateServerImpl_Skel.class
DateServerImpl_Stub.class

183
O Mecanismo de Nomeao

Clientes s podem invocar mtodos em objetos remotos se
possurem uma referncia ao objeto.

Um servidor de nomes simplificado provido no pacote RMI a fim
de prover tais referncias aos clientes.

Objetos remotos devem ser registrados atravs da classe
java.rmi.Naming.

Usa um esquema de nomeao baseado em URLs.

Servio de nomes ativado atravs do comando rmiregistry.

Deve ser ativado antes da execuo de clientes e servidores.
Clientes usam a classe java.rmi.Naming para obter referncias a
objetos remotos.
184
A Classe DateClient

Funcionamento:

Procura o objeto DateServer no servio de nomes;

Obtm uma referncia a este objeto;

Faz uma chamada ao seu mtodo getDate();

Imprime resultado recebido.
185
Implementao do Cliente
import java.rmi.RMISecurityManager;
import java.rmi.Naming;

public class DateClient {
public static void main (String args[]) throws Exception {
if (args.length != 1) throw
new RuntimeException ("Syntax: DateClient <hostname>");
System.out.println("//" + args[0] + "/DateServer");
DateServer dateServer =
(DateServer) Naming.lookup("//" + args[0] + "/DateServer");
Date when = dateServer.getDate ();
System.out.println (when);
}
}
DateClient.java
186
Exerccio
Faa um programa em Java utilizando RMI que l um arquivo em um
servidor e retorne o contedo de um determinado registro (igual ao
exerccio de RPC).
Instrues:

No servidor dever existir um arquivo que contm registros de
funcionrios de uma empresa.

No cliente dever ser digitado um nmero de matrcula. O servidor
recebe a solicitao, chama o mtodo que obtm o registro a partir do
arquivo e retorna para o cliente o nome e o cargo do funcionrio.

O programa dever ser apresentado pela dupla na prxima aula.
responsabilidade da dupla preparar o ambiente para apresentao do
exerccio.

Faa um relatrio que compare as implementaes RMI e RPC.
187
4. Comunicao em SDs
Taxonomia da
Distribudos
188
4. Comunicao em SDs
Tem como essncia a comunicao atravs de um intermedirio e,
portanto, no existe nenhuma ligao direta entre o emissor e um
ou mais receptores.
PRINCIPAIS PROPRIEDADES
Desacoplamento de Espao: O remetente no sabe ou no precisa saber
a identidade do receptor e vice-versa. Devido ao desacoplamento de espao, o
desenvolvedor tem muitos graus de liberdade para lidar com mudanas:
Remetentes ou receptores, podem ser substitudos, atualizados, replicados ou
migrados.
189
4. Comunicao em SDs
Tem como essncia a comunicao atravs de um intermedirio e,
portanto, no existe nenhuma ligao direta entre o emissor e um
ou mais receptores.
PRINCIPAIS PROPRIEDADES
Desacoplamento de Espao: O remetente no sabe ou no precisa saber
a identidade do receptor e vice-versa. Devido ao desacoplamento de espao, o
desenvolvedor tem muitos graus de liberdade para lidar com mudanas:
Remetentes ou receptores, podem ser substitudos, atualizados, replicados ou
migrados.

Desacoplamento de Tempo: O emissor e o receptor podem ter tempos de
vida independentes, ou seja, no precisam existir no mesmo tempo da
comunicao.

Exemplo: Ambientes mveis, onde os usurios podem se conectar e desconectar
rapidamente da rede.
190
4. Comunicao em SDs Indirect Communication
Acoplamento de Espao e Tempo em Sistemas Distribudos
191
Group Communication
192
Oferece um servio onde uma mensagem enviada para um
grupo e repassada para todos os membros desse grupo.

Caractersticas:

Remetente no tem conhecimento da identidade dos
receptores;

Baseia-se no conceito de abstrao de grupo, com
operaes previstas para entrada e sada do grupo;

Mensagens so enviadas a um grupo ao invs de
processos individuais e mensagens so entregues para
cada membro do grupo;
Group Communication
193
Group Communication Funcionamento
194
Possvel implementao sobre multicast (ou uma rede
sobreposta equivalente). Agrega mais valor do que a
comunicao broadcast:

Entrega ordenada de mensagens;

O grupo bem definido e gerenciado;

Tolerncia a falhas, garantia de entrega.
Group Communication
195
Possvel implementao sobre multicast (ou uma rede
sobreposta equivalente). Agrega mais valor do que a
comunicao broadcast:

Entrega ordenada de mensagens;

O grupo bem definido e gerenciado;

Tolerncia a falhas, garantia de entrega.
Group Communication
Vantagens
Ocupao eficiente da banda. Uma mensagem de grupo torna-se um
multicast que mais eficiente que um broadcast ou diversos unicasts.

Tambm trabalha com a semntica e no apenas a sintaxe.

Gesto: Processos entram e saem do grupo coordenados por um
servio de membros.
196
Group Communication Aplicaes

Divulgao confivel de informaes para um nmero
potencialmente grande de clientes. Ex. Setor financeiro, onde as
instituies necessitam de acesso preciso e atualizado em uma
grande diversidade de fontes de informao.

Suporte para aplicaes colaborativas, onde os eventos precisam
ser divulgados para mltiplos usurios para preservar uma viso
nica para o usurio. Ex: Jogos multiusurios.
197
Group Communication Aplicaes

Divulgao confivel de informaes para um nmero
potencialmente grande de clientes. Ex. Setor financeiro, onde as
instituies necessitam de acesso preciso e atualizado em uma
grande diversidade de fontes de informao.

Suporte para aplicaes colaborativas, onde os eventos precisam
ser divulgados para mltiplos usurios para preservar uma viso
nica para o usurio. Ex: Jogos multiusurios.

O suporte para diversas estratgias de tolerncia a falhas, incluindo
a atualizao constante de dados replicados ou servidores de alta
disponibilidade.

Suporte para monitoramento e gerenciamento do sistema. Ex.
Estratgias de balanceamento de carga.
198
Grupos de Processos

Mensagens so enviadas apenas para processos;

Nvel de servios similar aos sockets;

Mensagens so tipicamente um conjunto de bytes no estruturados
sem suporte para o empacotamento de tipos complexos de dados
(como disponibilizados por RPC e RMI).
Group Communication Tipos de Grupos
199
Grupos de Processos

Mensagens so enviadas apenas para processos;

Nvel de servios similar aos sockets;

Mensagens so tipicamente um conjunto de bytes no estruturados
sem suporte para o empacotamento de tipos complexos de dados
(como disponibilizados por RPC e RMI).

Grupo de Objetos

Abordagem alto-nvel para computao em grupo. Pode processar
invocaes simultneas;

Clientes invocam operaes de um objeto nico e local, que atua
como um proxy para o grupo. O proxy usa a comunicao em grupo
para enviar as invocaes para os membros.

Parmetros de objeto e resultados so empacotados como no RMI.
Group Communication Tipos de Grupos
200
Grupos Fechados e Abertos

Fechado: Apenas membros podem fazer multicast para o grupo. til para
servidores cooperativos enviarem mensagens entre si que apenas eles
podem receber.

Aberto: Processos fora do grupo podem enviar mensagens para ele. til
para entrega de mensagens a grupos de processos interessados em
determinados eventos que ocorrem fora do grupo.
201
Implementao
Confiabilidade

Na Comunicao Multicast definida em termos da:

Integridade: A mensagem recebida a mesma que a
que foi enviada, e mensagens no so entregues em
duplicidade.

Validade: Toda mensagem enviada entregue.

Acordo: Se a mensagem for entregue a um processo,
ento entregue a todos os processos do grupo.
As questes de implementao envolve confiabilidade,
ordenao e gesto de membros do grupo em ambientes
dinmicos.
202
Implementando Confiabilidade

1) Remetente envia uma mensagem para cada membro do
grupo e aguarda o reconhecimento (ACK);

2) Se mensagens de reconhecimento
no so recebidas em um dado
perodo de tempo, reenvia a
mensagem. Repete isso n vezes
se necessrio.

3) Se todas as mensagens de reconhecimento so recebidas,
remetente reporta o sucesso ao chamador.
203
Implementando Confiabilidade (cont.)

ACKs no so escalveis: ACK Explosion.

Utilizando ACKs negativos (NACKs)

Se tudo est ok o receptor no diz nada.

Se uma mensagem perdida o receptor avisa ao remetente.
204
Ordenao

Servios de comunicao em grupo oferecem multicast
ordenada, podendo utilizar as seguintes propriedades:

Ordenao FIFO (First-In-First-Out): A camada de comunicao
forada a entregar as mensagens que chegam do mesmo processo
na mesma ordem em que elas foram enviadas.
m1 e sempre entregue antes de m2, assim como m3 e sempre entregue
antes de m4.
205
Ordenao (cont.)

Ordenao Causal: Entrega as mensagens de modo que a
potencial causalidade entre as mensagens diferentes seja
preservada. Utiliza relgios vetoriais para garantir que uma
mensagem seja entregue somente se todas as mensagens que a
precederem por causalidade tambm tenham sido recebidas.
206
Ordenao (cont.)

Ordenao Total: Independente da entrega da mensagem ser
ordenada por FIFO ou por causalidade, exige-se adicionalmente
que, quando as mensagens forem entregues, devam ser entregues
na mesma ordem a todos os membros do grupo.
Existe uma violao da ordenao total pois P1 entrega m1 a P2 antes de
m3 ser entregue por P4 e o mesmo no acontece nas entrega de
mensagens a P3 (que tambm deveria receber m1 antes de m3).
A FIFO tambm precisa ser respeitada nesse caso.

207
Ordenao (cont.)
Totalmente Ordenado
(mensagens T
1
e T
2
).
FIFO (mensagens F
1
e F
2
)
Ordenao Causal
(mensagens C
1
e C
3
)
208
Implementando Ordenao Total

Abordagem do Sequenciador (centralizado)

1. Todos os pedidos so enviados para um sequenciador, onde
eles recebem uma identificao (ID);

2. O sequenciador atribui IDs com valores crescentes;

3. Requisies que chegam a um site so retidas at que sejam os
prximos da sequncia.

Problemas: Sequenciador = Gargalo + Ponto nico de falha

Outras abordagens

Acordo distribudo para gerar IDs (Ex. Software Isis).

Atribuio de timestamps a partir de um relgio global (fsico ou lgico).
209
Gerenciamento de Membros
Envolve elementos essenciais para a gerncia de comunicao em
grupo, onde necessrio manter uma viso precisa dos membros
participantes, uma vez que entidades podem entrar/sair do grupo,
ou mesmo falhar.
210
Um servio de grupos possui quatro tarefas principais:

Fornecer uma interface para mudanas do grupo: O servio
fornece operaes para criar/destruir grupos de processos e para
adicionar/retirar um processo de um grupo.

Deteco de falhas: O servio monitora os membros do grupo, no
s no caso deles falharem, mas tambm caso se tornem inacessveis
devido a uma falha de comunicao.
211
Um servio de grupos possui quatro tarefas principais:

Fornecer uma interface para mudanas do grupo: O servio
fornece operaes para criar/destruir grupos de processos e para
adicionar/retirar um processo de um grupo.

Deteco de falhas: O servio monitora os membros do grupo, no
s no caso deles falharem, mas tambm caso se tornem inacessveis
devido a uma falha de comunicao.

Notificao aos membros das mudanas grupo: O servio
informa os membros do grupo quando um processo adicionado ou
excludo.

Realizar expanso do endereo do grupo: Quando um processo
faz multicast de uma mensagem, ele fornece o identificador de grupo,
em vez de uma lista de processos no grupo.
212
Um tpico servio de Group Communication
OBS: JGroups Toolkit (Kit Java para Comunicao confivel em Grupo).
213
4. Comunicao em SDs
Taxonomia da
Distribudos
214
Publish-Subscribe
215
Publish-Subscribe
Tcnica muito utilizada, tambm chamada Sistemas Baseados em
Eventos Distribudos. um sistema onde editores divulgam
(Publish) eventos estruturados para um servio de eventos e
assinantes (Subscribers) expressam interesse a determinados
eventos atravs de inscries.
216
Publish-Subscribe
Aplicaes
Sistemas de informao financeiros;

reas que utilizam live feeds e dados de tempo real;

Suporte para o trabalho cooperativo, onde um nmero de participantes
precisa ser informado de eventos de interesse comum;

Suporte para computao ubqua, incluindo a gesto de eventos que
emanam a partir da infra-estrutura ubqua (ex: eventos de localizao);

Aplicaes de monitoramento (ex: monitoramento de rede na Internet).
Tcnica muito utilizada, tambm chamada Sistemas Baseados em
Eventos Distribudos. um sistema onde editores divulgam
(Publish) eventos estruturados para um servio de eventos e
assinantes (Subscribers) expressam interesse a determinados
eventos atravs de inscries.
217
Publish-Subscribe
218
Exemplo: RSS
um subconjunto de "dialetos" XML que
servem para agregar contedo podendo ser
acessado atravs de programas ou sites
agregadores. Usado principalmente em sites
de notcias e blogs.
O utilizador pode permanecer informado de diversas
atualizaes em diversos sites sem precisar visit-los um a
um.
Permite aos usurios da internet se
inscreverem em sites que fornecem "feeds"
RSS (que tipicamente so sites que mudam
ou atualizam o seu contedo regularmente).
219
Publish/Subscribe Caractersticas
Heterogeneidade

Eventos permitem que os componentes do sistema
distribudo, que no interoperavam, trabalhem em conjunto.

Assincronicidade

Publishers e Subscribers esto desacoplados;

As notificaes so enviadas de forma assncrona.

Garantias de Entrega

Pode apresentar diferentes nveis de garantias;

Determinado pelos requisitos da aplicao.
220
Publish-Subscribe Modelo
O modelo de programao publish/subscribe baseado em
um pequeno conjunto de operaes.
221
Publishers publicam um evento atravs da
operao publish(e).
222
Subscribers manifestam interesse em
um conjunto de eventos atravs de
inscries.
223
A inscrio feita atravs da operao
subscribe(f), onde f um filtro (um padro
definido sobre o conjunto de todos os
eventos possveis).
A expressividade dos filtros determinada
pelo modelo de assinatura.
224
Quando os eventos alcanam um
subscriber, so entregues de forma
assncrona atravs de uma operao
notify(e).
225
Atravs de anncios, publishers tm
a opo de declarar a natureza de
futuros eventos atravs de uma
operao advertise(t).
226
O sistema funciona como um
intermedirio (broker) para entregar
eventos aos assinantes corretos.
227
Modelos de Inscrio
Channel-Based

Publishers publicam eventos em canais nomeados e
subscribers inscrevem-se para receber os eventos enviados
para o canal.

Esquema bastante primitivo e o nico que define um canal
fsico. Todos os demais sistemas utilizam alguma forma de
filtrar o contedo de eventos.

Embora simples, esse esquema tem sido usado com
sucesso no CORBA Event Service;
228
Modelos de Inscrio (cont.)
Topic-Based

Cada notificao expressa por uma quantidade de campos, com
um campo que indica o tpico. As inscries so definidas em
termos do tema de interesse.

Tpico pode ser organizado hierarquicamente, e declarado
explicitamente.
229
Topic-Based
Modelo mais popular, mas com expressividade limitada:

Assinante interessado num subconjunto de eventos de um tpico recebe todos
os eventos do tpico.

Extenso para modelo hierrquico (Topico A pode ser um subtpico de um
tpico B mais geral).
230
Content-Based

Um filtro baseado em contedo uma consulta definida em
termos de composies de restries sobre os valores dos
atributos de um evento.
Assinantes somente
recebem as notificaes
que correspondam aos
critrios definidos.

A sofisticao das
linguagens de consulta
variam de sistema para
sistema.
231
Content-Based
Os dados publicados no sistema so mais estruturados.

Filtra eventos inteis antes de notificar um assinante.

Cada assinatura pode ser expresso como um conjunto de restries expressos
em atributos.
232
Type-Based

Intrinsecamente ligada s abordagens baseadas em objetos onde
os objetos tm um tipo especfico. Assinaturas so definidas em
termos de tipos de eventos.
A baixa-granularidade possibilita consultas mais refinadas a partir
de atributos e mtodos de um determinado objeto.
233
Modelos de Inscrio Adicionais
Concept-Based: Permite descrever um esquema de eventos num
nvel mais alto de abstrao com o uso de ontologias, e atravs do
uso de metadados e funes de mapeamento, fornecem uma base
de conhecimento para uma interpretao no ambgua da estrutura
do evento. Filtros so expressos em termos semnticos e sintticos.
234
Modelos de Inscrio Adicionais
Concept-Based: Permite descrever um esquema de eventos num
nvel mais alto de abstrao com o uso de ontologias, e atravs do
uso de metadados e funes de mapeamento, fornecem uma base
de conhecimento para uma interpretao no ambgua da estrutura
do evento. Filtros so expressos em termos semnticos e sintticos.

Baseado em XML: Suporta um modelo de dados semi-
estruturado, geralmente baseado em documentos XML. Fornece
vantagens naturais, como interoperabilidade, independncia da
implementao e extensibilidade.

Location-awareness: Usado em ambientes mveis normalmente
requerem apoio de assinaturas sensveis a localizao.
235
Implementao
Um sistema Publish/Subscribe tem a funo de garantir que os
eventos sejam entregues de forma eficiente para todos os
assinantes que possuem filtros correspondentes para um
determinado evento.

Adicionalmente tambm tem responsabilidades em termos de
segurana, escalabilidade, concorrncia e qualidade do
servio.

As implementaes podem ser:

Centralizadas (broker);

Distribudas (peer-to-peer).
236
Implementao
A implementao CENTRALIZADA a abordagem mais simples
onde um nico n atua como intermedirio (broker) do evento.

Publishers publicam eventos a um broker, subscribers enviam
inscries para o broker e em troca recebem notificaes.

A interao com o broker feita atravs de uma srie de
mensagens ponto-a-ponto, implementadas atravs de Message
Passing ou Remote Invocation.

Implementao mais simples, mas apresenta deficincias quanto
a escalabilidade, alm do fato do broker ser um ponto potencial
de falha e gargalo.
Centralizada vs Distribuda
237
Implementao
A implementao DISTRIBUDA constituda por uma rede de
brokers que cooperam para oferecer a funcionalidade desejada.

Mais apta a sobreviver a falhas, opera bem na escala da internet
(P2P).
Centralizada vs Distribuda (cont.)
Sem distines entre
publishers e subscribers.
Todos os ns agem como
brokers, que implementam
cooperativamente o
roteamento para os
eventos.
238
Arquitetura dos Sistemas Publish/Subscribe
239
Envia notificao de evento para todos os ns e realiza a
correspondncia no assinante.

Tambm possvel enviar inscries de volta para todos os
editores e a correspondncia e feita no editor. Eventos
correspondentes so enviadas diretamente para os assinantes.

Abordagem simples, fcil de implementar (broadcast, multicast),
mas pode resultar em alto trfego.

Outras tcnicas tentam otimizar a quantidade de mensagens
trocadas considerando o contedo.
Roteamento de Eventos Flooding
240
Roteamento de Eventos Flooding
241
Roteamento de Eventos Subscription Flooding
Cada assinatura copiada para cada n (broker);

Cada n (broker) mantm tabelas de assinatura completas,
que so usadas para combinar eventos e diretamente
notificar assinantes interessados.

A abordagem sofre uma grande sobrecarga de memria,
mas a difuso do evento otimizada;

Impraticvel em aplicaes onde as assinaturas mudam
com frequncia.
242
Roteamento de Eventos Subscription Flooding
243
244
Aplica filtro em redes de brokers. Publishers transmitem
notificaes apenas quando h um caminho vlido para um
assinante.

Cada n precisa manter uma lista de vizinhos na rede de
brokers, uma lista de assinantes e uma tabela de
roteamento.

Correspondncia: Uma funo de correspondncia toma
uma notificao de evento e uma lista de ns com
respectivas inscries e retorna a um conjunto de ns onde
a notificao corresponde com a inscrio.
Roteamento de Eventos Filtering
245
246
247
248
Combina o evento com a lista de inscrio.
249
Encaminha o evento para todos
os ns com inscries
correspondentes na (matchlist).
250
Usa match function, desta vez
combinando o evento com a
tabela de roteamento e
enviando apenas para os
caminhos que levam a uma
assinatura (fwdlist).
251
Se o evento de inscrio vem
de um assinante diretamente
conectado, assinatura deve ser
inserida na tabela de inscritos.
252
Caso contrrio, o publisher
um n intermedirio. O n
agora sabe que existe um
caminho para essa assinatura
e, portanto, uma entrada
adicionada a tabela de
roteamento.
253
Em ambos os casos a
assinatura do evento
transmitida para cada vizinho
a partir do n origem.
254
Advertisements podem reduzir o trfico de
mensagens atravs da propagao de
alertas diretamente para os assinantes.
255
256
Roteamento de Eventos Rendezvous
Visualiza-se o conjunto de todos os eventos possveis como um
espao de eventos e divide-se as responsabilidades para este
espao de eventos entre um conjunto de brokers da rede.

Particiona-se o espao de eventos em partes e aloca-se a
responsabilidade por cada pedao a um determinado broker
(conhecido por n rendezvous para o evento). Implementao
requer duas funes:

1) SN(s) que toma uma assinatura (s), e retorna um ou mais ns
rendezvous que tomam responsabilidade para cada assinatura.

2) EN(e) que toma um determinado evento (e), e retorna um ou mais
ns rendezvous responsveis por correlacionar e com as assinaturas
no sistema.
257
Fase 1: Dois ns emitem a mesma assinatura s.
258
Fase 2: Um evento
e correspondente a
s roteado para o
n de rendezvous,
onde comparado
com s.
Broker um n rendezvous entre o evento e e a assinatura s.
259
EN retorna ns responsveis por
corresponder a e.
260
SN retorna ns responsveis por s.
261
Consideraes:

Tanto SN(s) e EN(e) retornam mais que um n se confiabilidade
um requisito.

Essa abordagem apenas funciona se a interseo de EN(e) e
SN(s) no vazia para um dado e que possui relao com s
(regra do mapeamento de interseo).

Roteamento baseado em rendezvous mapeia um espao de
eventos em uma DHT (Distributed Hash Table).

Uma funo hash pode ser usada para mapear eventos e
inscries em um n rendezvous correspondente para o
gerenciamento de suas inscries.
262
263
Roteamento de Eventos Informed Gossip
Abordagens baseadas em Gossip so populares para alcanar
multicast (incluindo multicast confivel).

Tais abordagens operam atravs de ns na rede e
periodicamente e probabilisticamente trocam eventos (ou dados)
com os ns vizinhos.

Com esta abordagem, possvel propagar eventos de forma
eficaz pela rede sem a estrutura imposta por outras abordagens.

Uma pura abordagem Gossip efetivamente uma estratgia
alternativa para a implementao de flooding. possvel levar
em conta os contedos (chamados Gossip Informed).
264
Exemplos de Sistemas Publish/Subscribe
265
4. Comunicao em SDs
Taxonomia da
Distribudos
266
Message Queues
267
A comunicao em grupos e publish/subscribe disponibilizam
uma comunicao 1:N, Message Queues disponibilizam
servio de comunicao indireta ponto-a-ponto.

Contm as propriedades de desacoplamento de espao e de
tempo. Message queues tambm so chamadas Message-
Oriented Middleware (MOM).

Middlewares Comerciais:

IBM WebSphere MQ

Microsoft MSMQ

Oracle Stream Advanced Queuing (AQ)

JMS (Java Messaging Service)
Message Queues
Aplicaes: EIA e Sistemas
de Processamento de
Transaes Comerciais.
268
MQ oferece um sistema de comunicao distribudo atravs
de filas, onde o produtor de processos pode enviar mensagens
para uma fila, e um processo consumidor pode receber
mensagens dessa fila.
Message Queues Modelo de Programao
269
MQ oferece um sistema de comunicao distribudo atravs
de filas, onde o produtor de processos pode enviar mensagens
para uma fila, e um processo consumidor pode receber
mensagens dessa fila.
Message Queues Modelo de Programao
Geralmente suporta trs estilos de recebimento:
Blocking Receive: Bloqueia at que uma mensagem apropriada
esteja disponvel.

Non-blocking Receive: Operao de pooling, que ir verificar o
estado da fila e retornar uma mensagem se disponvel, ou uma
indicao de que no est disponvel em caso contrrio.

Notify: Operao que emitir uma notificao de evento quando
uma mensagem est disponvel na fila associada.
270
Message Queues
Remetente coloca a mensagem na fila, a qual pode ser
removida mais tarde por um processo de recepo.
(blocking)
(non-blocking)
(subscription)
(query/filtering)
Poltica da Fila: Normalmente FIFO, dependendo da aplicao tambm priorizao.
271
Message Queues
Uma mensagem consiste de um destinatrio (identificador
nico da fila destino), metadado (associado a mensagem e
inclui campos de prioridade, modo de entrega, corpo da
mensagem).
Contedo da mensagem serializado usando marshalling,
serializao de objeto ou XML. O tamanho da mensagem
pode ser configurado.
272
Message Queues
Uma mensagem consiste de um destinatrio (identificador
nico da fila destino), metadado (associado a mensagem e
inclui campos de prioridade, modo de entrega, corpo da
mensagem).
Contedo da mensagem serializado usando marshalling,
serializao de objeto ou XML. O tamanho da mensagem
pode ser configurado.

Mensagens so persistentes (mensagem fica armazenada na
fila at se consumida).

Toda mensagem enviada validada, ntegra, entregue uma
vez, mas no se pode dizer nada sobre o tempo para entrega.
273
Message Queues
Funcionalidades Adicionais
Muitos middlewares de MQ suportam o envio/recebimento de
mensagens contidas numa transao. O objetivo garantir que
todos os passos da transao sejam completados.

Alguns sistemas suportam transformao de mensagens (Big-
Endian/Little-Endian, representao externa de dados, ex. SOAP
para IIOP (Internet Inter-ORB Protocol).
274
Message Queues
Funcionalidades Adicionais
Algumas implementaes suportam segurana (Ex. WebSphere MQ
com SSL, autenticao e controle de acesso).

Similar a Message Passing, mas MQ a fila explcita e separada do
transmissor/receptor, Message Passing implicita (Ex. Buffers de
mensagem do MPI).
Muitos middlewares de MQ suportam o envio/recebimento de
mensagens contidas numa transao. O objetivo garantir que
todos os passos da transao sejam completados.

Alguns sistemas suportam transformao de mensagens (Big-
Endian/Little-Endian, representao externa de dados, ex. SOAP
para IIOP (Internet Inter-ORB Protocol).
275
Message Queues Implementao
Implementaes podem ser centralizadas ou distribudas;

Implementaes centralizadas possui uma ou mais filas de
mensagens gerenciadas por um gerente de filas (queue
manager) localizadas em um dado n.

Esquema tem a vantagem de ser simples, mas o gerente de
filas pode ser tornar um gargalo ou um ponto nico de
falhas;

Implementaes distribudas tem sido mais adotadas (Ex.
WebSphere MQ (IBM).
276
Estudo de Caso WebSphere QM
Desenvolvido pela IBM;

As filas no WS QM so gerenciadas por um queue manager
que hospeda e gerencia filas, e permitie que aplicativos
acessem as filas atravs do Message Queue Interface
(MQI).
277
Desenvolvido pela IBM;

As filas no WS QM so gerenciadas por um queue manager
que hospeda e gerencia filas, e permitie que aplicativos
acessem as filas atravs do Message Queue Interface
(MQI).

MQI possibilita que aplicaes executem operaes como
conexo e disconexo a partir de uma fila (MQCONN e
MQDISC) ou enviar (receber) mensagens para (de) uma fila
(MQPUT e MQGET).

Um nico servidor fsico pode alojar mltiplos queue
manager.
278
Um cliente acessa um queue manager
atravs de um canal cliente.
279
Canais cliente utilizam o conceito de proxy, onde
comandos MQI so emitidos num servidor proxy que envia
de forma transparente para o queue manager para
execuo, utilizando RPC.
280
Uma aplicao cliente envia mensagens para um queue manager
remoto, e mltiplos servios consomem as mensagens entrantes.
281
Queue Managers podem
estar ligados atravs de uma
estrutura federada por meio
de um canal de mensagens
(Message Channel).
Conexo unidirecional,
assncrona.
282
Cliente Channel Message Channel
283
Message Channel Agent (MCA) gerencia o Message Channel. MCAs
so responsveis por estabelecer e manter o canal.
284
Tabelas de roteamento possibilitam que outras topologias (mesh, rvores,
barramento) sejam criadas para atender requisitos especficos da aplicao
(escalabilidade, desempenho).
285
Estudo de Caso JMS
Java Messaging Service uma especificao para
comunicao indireta em programas Java.

Unifica os paradigmas Publish/Subscribe e Message Queue,
suportando tpicos e filas como destinos alternativos de
menssagens.
Algumas implementaes:

Java Messaging para Jboss,
Suns Open MQ, Apache ActiveMQ,
OpenJMS,
WebSphere MQ.
286
Estudo de Caso JMS
Um cliente JMS um programa ou componente Java que
produz ou consome mensagens, um produtor JMS um
programa que cria ou produz mensagens e um consumidor
JMS um programa que recebe e consome mensagens.

Um provedor JMS qualquer dos mltiplos sistemas que
implementam a especificao JMS.
287
Estudo de Caso JMS
Um cliente JMS um programa ou componente Java que
produz ou consome mensagens, um produtor JMS um
programa que cria ou produz mensagens e um consumidor
JMS um programa que recebe e consome mensagens.

Um provedor JMS qualquer dos mltiplos sistemas que
implementam a especificao JMS.

Uma mensagem JMS um objeto que usado para comunicar
informaes entre clientes JMS (dos produtores para
consumidores).

Um destino JMS um objeto que suporta comunicao indireta
no JMS. Pode ser um Tpico JMS ou uma Fila JMS.
288
Estudo de Caso JMS
289
Estudo de Caso JMS
Para interagir com Provedor
JMS, primeiro necessrio criar
uma conexo entre um
programa cliente e um provedor
atravs da fbrica de conexes
(servio responsvel por criar
conexes com as propriedades
necessrias).
290
Estudo de Caso JMS
A conexo resultante um canal
lgico entre o cliente e o
provedor (ex. Socket TCP/IP).
291
Estudo de Caso JMS
Conexes podem ser
utilizadas para criar uma
ou mais sees. Uma
seo um conjunto de
operaes envolvendo a
criao, produo e
consumo de mensagens
relacionadas a uma tarefa
lgica.
O objeto de seo
resultante tambm
contempla operaes
para criao de
transaes, suportando
a execuo de tudo-ou-
nada de um conjunto de
operaes.
292
Estudo de Caso JMS
Podem existir uma ou
mais sees do tipo
tpico ou do tipo fila, mas
no possvel misturar
esses estilos em uma
conexo.
293
Estudo de Caso JMS
Cabealho: Contm todas as informaes
necessrias para identifica e rotear a mensagem,
incluindo o destino (uma referncia tanto para um
tpico ou uma fila), a prioridade da mensagem, data
de expirao, um ID e timestamp.
O objeto de sesso fundamental para o funcionamento da
JMS, suportando mtodos para criao de mensagens,
produtores e consumidores de mensagens:
294
Estudo de Caso JMS
Cabealho: Contm todas as informaes
necessrias para identifica e rotear a mensagem,
incluindo o destino (uma referncia tanto para um
tpico ou uma fila), a prioridade da mensagem, data
de expirao, um ID e timestamp.

Propriedades: Podem ser utilizadas para expressar
contexto adicional associado a mensagem, incluindo
campo de localizao.

Corpo: Pode ser uma mensagem de texto, um fluxo
de bytes, um objeto serializado Java, um fluxo de
valores primitivos Java ou conjunto de pares
nome/valor mais estruturado.
O objeto de sesso fundamental para o funcionamento da
JMS, suportando mtodos para criao de mensagens,
produtores e consumidores de mensagens:
295
4. Comunicao em SDs
Taxonomia da
Distribudos
296
Distributed Shared
Memory
297
DSM (Distributed Shared Memory)
Consiste em uma memria abstrata utilizada por vrios
processadores em um SD, no qual se permite aos processos
compartilharem memria mesmo que estejam executando em
nodos que no compartilham memria fisicamente.
298
DSM (Distributed Shared Memory)
Consiste em uma memria abstrata utilizada por vrios
processadores em um SD, no qual se permite aos processos
compartilharem memria mesmo que estejam executando em
nodos que no compartilham memria fisicamente.
Benefcios:

Apresenta as vantagens de programao de um sistema
multiprocessado aplicadas a um sistema de multicomputadores;

Oculta do programador os problemas da comunicao em rede;

Permite a escalabilidade inerente dos sistemas
multicomputadores.

Prov uma maior desacoplamento do que Message Passing e
RPC.
299
DSM Estrutura
DSM constituda de CPUs distintas e independentes conectadas
por uma rede, cada uma com memria RAM prpria e usufruindo de
um espao comum de memria compartilhada.
300
DSM Comparao com outras tecnologias
Dados so compartilhados diretamente por processos, no
precisando ser passados como mensagens (MOM) ou
parmetros (RPC/RMI).

Requer o uso de mecanismos de controle de concorrncia para
garantir a consistncia dos dados na rea de memria
compartilhada.
301
DSM Comparao com outras tecnologias
Dados so compartilhados diretamente por processos, no
precisando ser passados como mensagens (MOM) ou
parmetros (RPC/RMI).

Requer o uso de mecanismos de controle de concorrncia para
garantir a consistncia dos dados na rea de memria
compartilhada.

No modelo Message Passing variveis precisam ser
empacotadas (marshalled) por um processo, transmitidas e
desempacotadas em variveis no processo receptor. DSM o
processo compartilha variveis diretamente (sem marshalling).

Muitas implementaes permitem que variveis armazenadas na
DSM sejam nomeadas e acessadas de forma similar a variveis
comuns no compartilhadas.
302
DSM - Implementao
Ocorrem tanto em hardware quanto em software.
1. HARDWARE
Nessa estratgia a memria compartilhada tipicamente se refere a
grandes blocos de RAM que podem ser acessados por diferentes
CPUs em um sistema de multiprocessamento baseado na arquitetura
NUMA (Ex. Multiprocessador Dash).

CPUS compartilham a mesma viso dos dados, e a comunicao entre
processadores muito rpida.

As CPUs tratam das instrues de memria LOAD e STORE
comunicando-se com a memria remota e com mdulos de cache,
conforme for necessrio, para armazenar e recuperar dados.
303
DSM - Implementao
1. HARDWARE Problemas

As CPUs necessitam de acesso rpido memria e por isso utilizam
sistemas de cache na prpria CPU. Complicaes:

A conexo da CPU para a memria se torna um gargalo no
sistema.

Computadores com memria compartilhada no possuem boa
escalabilidade.

Integridade da cache: Cache precisa estar atualizada com
informaes corretas e atuais. Mudanas na cache de uma CPU
devem ser replicadas as demais caches das demais CPUs.
304
DSM - Implementao
Arquitetura NUMA (Non-Uniform Memory Access)
Servidores de virtualizao exigem grandes quantidades de
memria e de CPUs para sustentar as cargas exigidas por diversas
maquinas virtuais.

Problema: Otimizao de acesso da CPU com a memria em
servidores virtuais. O objetivo permitir que o processador acesse
o banco de memria da forma mais rpida possvel.

Questo: Colocar muitos bancos de memria com muitos
processadores em um nico barramento de acesso no eficiente
para sustentar grandes exigncias dos aplicativos, SOs e mquinas
virtuais.
305
DSM - Implementao
Arquitetura NUMA (Non-Uniform Memory Access)
Soluo: Dividir as memrias e
CPUs em grupos (ns) visando
um acesso mais eficiente entre os
componentes do mesmo grupo.
Host NUMA
A latncia de acesso
CPU/memria no mesmo n
baixa.

A CPU pode acessar memrias
de outros ns, ao custo de uma
maior latncia devido ao
barramento.
306
DSM - Implementao
Acessos entre componentes de um mesmo n e de ns
diferentes.
307
DSM - Implementao
2. SOFTWARE
a) Baseados em Paginas: Implementam a DSM como uma regio de
memria virtual ocupando o mesmo intervalo de endereos no espao
de endereamento de cada processo participante.

Esse tipo de implementao normalmente conveniente apenas para
um conjunto de computadores homogneos, com dados e formatos de
pginas comuns.
308
DSM - Implementao
2. SOFTWARE
a) Baseados em Paginas: Implementam a DSM como uma regio de
memria virtual ocupando o mesmo intervalo de endereos no espao
de endereamento de cada processo participante.

Esse tipo de implementao normalmente conveniente apenas para
um conjunto de computadores homogneos, com dados e formatos de
pginas comuns.

Tem a vantagem de no impor nenhuma estrutura em particular para a
DSM, que aparece como uma sequncia de bytes.

Normalmente implementada a nvel do usurio
Exemplos: IVY, Munin, Treadmarks, Mirage, Clouds, Choices, COOL,
Mether.
309
DSM - Implementao
2. SOFTWARE (cont.)
b) Baseados em Objetos: Suporta formas de DSM sem nenhum
suporte para hardware ou paginao, de uma maneira neutra quanto a
plataforma.

Compartilhamento feito por meio da comunicao entre instncias da
camada de suporte em nvel de usurio nos clientes e servidores.
310
DSM - Implementao
2. SOFTWARE (cont.)
b) Baseados em Objetos: Suporta formas de DSM sem nenhum
suporte para hardware ou paginao, de uma maneira neutra quanto a
plataforma.

Compartilhamento feito por meio da comunicao entre instncias da
camada de suporte em nvel de usurio nos clientes e servidores.

Processos fazem chamadas a essa camada quando acessam itens de
dados na DSM.

As instncias dessa camada nos diferentes computadores acessam
itens de dados locais e se comunicam para manter a consistncia.
Exemplos: Orca, Linda, JavaSpaces, Tspaces.
311
DSM Organizao dos Dados
Os dados compartilhados podem ser organizados de
diferentes maneiras:

a) Organizao em pginas de memria:

uma das mais simples.

O espao de endereamento dividido em pginas com
cada uma presente na memria de cada mquina.

As pginas armazenam as variveis compartilhadas pelo
sistema.
312
DSM Organizao dos Dados
Os dados compartilhados podem ser organizados de
diferentes maneiras:

b) Organizao em objetos:

Os dados so encapsulados em estruturas chamadas
objetos ao invs de compartilhar variveis.

Objetos tambm possuem mtodos que atuam sobre os
dados, e permitem aos processos manipul-los por
invocao.

No permite acesso direto aos dados.
313
DSM Coerncia dos Dados
necessrio que as escritas feitas por uma CPU em
posies da DSM sejam propagadas para as demais CPUs.

Protocolos de Propagao de Escrita:

Protocolo de Atualizao

Protocolo de Invalidao
314
Protocolos de propagao de Escrita:

i) Protocolo de Atualizao: Uma escrita em um dado
compartilhado causa a atualizao de todas as suas cpias.

Abordagem mais complicada, pois a cada operao de escrita um
novo valor deve ser enviado ao invs de uma mensagem de
notificao.

Mesmo que vrias escritas consecutivas ocorram na mesma cpia,
sem a interferncia de leituras nas outras cpias, todas as cpias
recebero todas as mensagens de atualizao (muito trfego na
rede).
315
Protocolos de propagao de Escrita:

ii) Protocolo de Invalidao: Uma escrita em um dado
compartilhado causa a invalidao de todas as suas cpias. Neste
momento, passa a existir apenas uma cpia vlida no sistema.

Como as cpias foram invalidadas, as prximas operaes de escrita na
cpia vlida no iro produzir efeito algum sobre as outras cpias.

Na prxima operao sobre uma cpia que foi invalidada, ir ocorrer uma
falha de acesso, sendo que uma cpia vlida dever ser buscada
novamente para a memria local.

Vantagens: Utiliza um menor nmero de mensagens de notificao
minimizando o trfego na rede.
316
necessrio que as escritas feitas por uma CPU em
posies da DSM sejam propagadas para as demais CPUs.

Protocolos de Propagao de Escrita:

i) Protocolo de Atualizao

ii) Protocolo de Invalidao

Estratgias para Coerncia de Dados:

i) Centralizada

ii) Migrao

iii) Replicao
317
i) Centralizada: As pginas de memria compartilhadas so
mantidos em um servidor central, que executa as operaes
requisitadas pelos clientes.
318
ii) Migrao: As pginas de memria (ou objetos de dados)
so migrados de um n para outro, viabilizando a execuo
local das operaes com memria desejada.
319
iii) Replicao: a mais utilizada por alcanar melhor
desempenho para uma grande quantidade de aplicaes.

Cada n mantm uma cpia local dos dados;

Mais eficientes que as estratgias centralizada e por
migrao, pois permitem o acesso concorrente aos dados;

Exigem extremo cuidado para manter os dados
consistentes e sincronizados;

Mecanismos de controle de concorrncia (locks, monitores,
semforos...) devem ser usados para garantir a
consistncia
320
iii) Replicao (cont.): Trocas de mensagens so efetuadas
para manter os dados sincronizados.

Quando um dado for alterado por um n, duas estratgias
podem ser empregadas para sincronizao das rplicas:

1) Atualizar todas as rplicas.

2) Invalidar as demais rplicas, obrigando que sejam
atualizadas antes do prximo acesso.
321
iii) Replicao (cont.)
Replicao Somente-Leitura:

Dados podem ser lidos concorrentemente

Alteraes nos dados so coordenadas por um servidor,
que atualiza/invalida as rplicas.
322
iii) Replicao (cont.)
Replicao Leitura/Escrita

Dados so lidos e alterados em paralelo

Sequenciador responsvel por atualizar/invalidar
cpias desatualizadas.
323
Comunicao: A comunicao entre os ns pode afetar
negativamente o desempenho das aplicaes, principalmente
quando for usada replicao.

Estratgias para diminuir a quantidade de mensagens
enviadas pela rede:

Aguardar que um n faa todas as alteraes
necessrias nos dados antes de propag-las.

Usar multicast para enviar atualizaes.

O retardo causado pela propagao de mensagens na
rede pode resultar em inconsistncias momentneas.
324
DSM Funcionamento
O modelo de programao DSM permite que os acessos a dados
sejam realizados como se todos os dados estivessem presentes na
memria local dos nodos.
325
DSM Funcionamento
Entretanto nem todos os dados
esto presentes localmente em
cada CPU.
326
DSM Funcionamento
cada CPU.
Quando um dado no est
presente na memria local da
CPU, corre uma falha de
pgina.
327
DSM Funcionamento
cada CPU.
Quando um dado no est
presente na memria local da
CPU, corre uma falha de
pgina.
Software DSM busca uma
cpia atualizada da pgina da
memria remota para a local e
reinicia o processo.
328
DSM Funcionamento
Dependendo da operao (leitura ou escrita) o procedimento
DSM diferente:

Falha de Leitura: A pgina replicada com permisso de somente
leitura para todas as rplicas.

Falha de Escrita:

Uma mensagem de invalidao enviada para todas as CPUS como
cpias da pgina.

Cada CPU que recebe esta mensagem invalida sua cpia da pgina e
envia uma mensagem de confirmao para o escritor.

Como resultado, a cpia escrita da pgina torna-se a nica cpia.
329
DSM Algoritmos
Questes aos algoritmos para implementao de DSM:

Distribuio dos dados compartilhados esttica ou dinamicamente
atravs do sistema, para minimizar a latncia de acesso;

Preservar a coerncia dos dados compartilhados, enquanto
minimiza o overhead gerado com o gerenciamento de coerncia.
Algoritmos:
SRSW - Single Reader Single Writer

MRSW - Multiple Reader Single Writer

MRMW - Multiple Reader Multiple Writer
330
DSM Algoritmos

SRSW - Single Reader Single Writer
Um nico servidor central controla todas as requisies de acesso aos
dados compartilhados, fisicamente localizados neste nodo.

Sofre de problemas de desempenho (servidor central = gargalo).

Variante: Distribuio esttica de responsabilidade de partes do
espao de endereamento compartilhado para diferentes servidores.
Funes de mapeamento (ex. hashing), podem servir para localizar o
servidor apropriado de um determinado dado.

Permite migrao. Entretanto, somente uma cpia de determinado
bloco de dados pode existir, sendo que esta cpia pode migrar sob
demanda.
331
DSM Algoritmos

MRSW - Multiple Reader Single Writer
Tambm conhecidos por replicao de leitura.

Visa reduzir o custo mdio das operaes de leitura, contando que
compartilhamento de leitura o padro que prevalece em aplicaes
paralelas.

Permitem operaes de leitura simultneas em execues locais em
vrios nodos. Somente um nodo por vez pode receber permisso para
atualizar a cpia replicada.

Uma escrita nesta cpia aumenta o custo desta operao, porque os
usurios das outras cpias deste dado devem ser notificados.

Usualmente baseados em invalidao.
332
DSM Algoritmos

MRMW - Multiple Reader Multiple Writer
Tambm chamados de replicao total. Permitem replicao dos blocos
de dados com permisso de leitura e gravao.

Alteraes em cada cpia devem ser distribudas para todas as outras
cpias em nodos remotos, por mensagens multicast ou broadcast.

Apropriado para compartilhamento de escrita.

Frequentemente funciona com protocolos de atualizao.

Podem produzir trfego de coerncia alto, especialmente quando a
frequncia de atualizaes e o nmero de cpias replicados so altos.

Permitir que vrias escritas concorrentes possam ocorrer na pgina.
333
DSM Modelos de Consistncia - Notao
Uma linha para cada CPU no sistema;
Tempo evolui da esquerda para a direita;
Cada operao executada na DSM aparece na linha da CPU;
Utiliza:
Consistncia de memria: Poltica que determina como e
quando mudanas feitas por uma CPU so vistas pelas outras.
334

Operaes:

- Write - W (var) valor: Armazenar valor na varivel compartilhada var;

- Read - R (var) valor: Realizar a leitura de var para obter valor;

- Sinchronizarion - S: Sincronizao dos dados no sistema;

- Acquire - Acq(L) ou Acq(Lx): Obter um lock associado a uma varivel ou
para acessar uma regio de dados compartilhados;

- Release - Rel(L) ou Rel(Lx): Liberar um lock associado a uma varivel ou
uma regio de dados compartilhados.
Utiliza:
335

Operaes:

- Write - W (var) valor: Armazenar valor na varivel compartilhada var;

- Read - R (var) valor: Realizar a leitura de var para obter valor;

- Sinchronizarion - S: Sincronizao dos dados no sistema;

- Acquire - Acq(L) ou Acq(Lx): Obter um lock associado a uma varivel ou
para acessar uma regio de dados compartilhados;

- Release - Rel(L) ou Rel(Lx): Liberar um lock associado a uma varivel ou
uma regio de dados compartilhados.
Utiliza:
Exemplos:

W(x)1 = Armazenar o valor 1 na varivel x.

R(x)2 = Realizar a leitura da varivel x e obter o valor 2.

S = Momento da sincronizao e os dados so atualizados,

Acq(L) ou (Lx) = Travar a varivel x ou a regio de memria
para acesso por outras operaes.

Rel(L) ou (Lx) = Liberar para acesso por outras operaes a
varivel x ou a regio DSM.
336
Locks, Unlocks e Monitors
Lock: Estrutura fornecida pela linguagem de programao para prover a
excluso mtua no acesso as variveis compartilhadas. Formas de se
trabalhar com locks so:

Acquire (Obteno): Espera at o lock estar livre para obt-lo;

Release (Liberao): Libera quem estava com lock em Acquire (Unlock).

Regras para uso dos locks: Sempre realizar um acquire (obteno)
antes de acessar uma estrutura DSM. Ao finalizar o acesso sempre
realizar um release (liberao).
337
Locks, Unlocks e Monitors
Lock: Estrutura fornecida pela linguagem de programao para prover a
excluso mtua no acesso as variveis compartilhadas. Formas de se
trabalhar com locks so:

Acquire (Obteno): Espera at o lock estar livre para obt-lo;

Release (Liberao): Libera quem estava com lock em Acquire (Unlock).

Regras para uso dos locks: Sempre realizar um acquire (obteno)
antes de acessar uma estrutura DSM. Ao finalizar o acesso sempre
realizar um release (liberao).

Monitors: Conjunto de procedimentos, variveis e estruturas de dados,
todas agrupadas em um mdulo especial. Somente um processo pode estar
ativo dentro do monitor em um instante.
338
DSM Modelos de Consistncia
Consistncia No-Sincronizada (Ordenados): No possuem um
mecanismo de sincronizao explcito, ou seja, as operaes em memria
consideram apenas uma determinada ordem.

Consistncia Rgida ou Estrita
Consistncia Sequencial
Consistncia Causal
Consistncia PRAM
Consistncia em Cache
Consistncia em Processador
339
Consistncia No-Sincronizada (Ordenados): No possuem um
mecanismo de sincronizao explcito, ou seja, as operaes em memria
consideram apenas uma determinada ordem.

Consistncia Rgida ou Estrita
Consistncia Sequencial
Consistncia Causal
Consistncia PRAM
Consistncia em Cache
Consistncia em Processador

Consistncia Sincronizada: Utilizam mecanismos de sincronizao explcitos,
tal como variveis de sincronizao, introduzindo dessa maneira restries
adicionais s operaes triviais de ordenao de memria.

Consistncia Fraca
Consistncia de Liberao
Consistncia de Liberao Preguiosa
Consistncia de Entrada
340
Modelos de Consistncia
No Sincronizados
341
Consistncia Rgida ou Estrita Operao de leitura retorna
o valor de escrita mais recente. Alcanado somente quando
existe uma noo global de tempo que possa fornecer uma
ordem determinstica para todas as leituras e escritas.
Acesso com consistncia
estrita
Acesso sem consistncia
estrita
342
Consistncia Sequencial Cada CPU do sistema enxerga
as operaes de escrita na memria na mesma ordem,
embora esta ordem seja diferente da ordem definida pelo
tempo real de execuo as operaes.
sequencial
sequencial
343
Consistncia Sequencial Cada CPU do sistema enxerga
as operaes de escrita na memria na mesma ordem,
embora esta ordem seja diferente da ordem definida pelo
tempo real de execuo as operaes.
344
Consistncia Causal Apenas as operaes que
potencialmente possuam uma relao causa/efeito devem ser
vistos na mesma ordem pelas CPUs. As operaes
concorrentes que no possuem essa relao podem ser vistos
em ordens diferentes pelas CPUs.
causal
causal. W(x)1 e W(x)2
possuem relao causal.
345
Consistncia PRAM (Pipelined Random Access Memory)

Escritas feitas por uma unica CPU so vistas por todos as
outras CPUs na ordem em que foram realizadas.

Escritas feitas por vrias CPUs possivelmente sero vistas em
uma ordem diferente pelas vrias CPUs.

o modelo que melhor reflete a realidade das redes atuais
(latncias diferente).

346
Consistncia em Cache Determina que todas as escritas
realizadas no mesmo local de memria sejam executadas em
alguma ordem sequencial.

Consistncia em Processador Deve manter a consistncia
PRAM. Suas escritas no mesmo local de memria devem ser
vistas na mesma ordem sequencial por todas as CPUs.
de processador
de processador
347
Modelos de Consistncia
Sincronizados
348
Consistncia Fraca Introduz a utilizao de variveis de
sincronizao junto com operaes de leitura e escrita de
memria, considerando as seguintes propriedades:

Os acessos s variveis de sincronizao devem ser
sequencialmente consistentes;

Nenhum acesso a uma varivel de sincronizao liberado para
execuo at que todas as operaes de escritas anteriores a esta
varivel de sincronizao tenham sido completadas;

Nenhum acesso a dados. Operaes de leitura e escrita na memria
so liberadas para execuo at que todos os acessos anteriores as
variveis de sincronizao tenham sido completados.
349
Consistncia Fraca As propriedades viabilizam a
construo de condies para a implementao de barreiras
de sincronizao e sees crticas (locks e unlocks), que
determinam que todas as operaes planejadas para serem
executadas antes da barreira, devem obedecer esta restrio.
Modelo de consistncia fraca. Todas as
operaes de leitura e escrita precedem
a operao de sincronizao.
Sem Modelo de consistncia fraca. CPU
P2 faz a leitura do dado 1 em x aps a
operao de sincronizao quando a
varivel x assume o valor 2.
350
Consistncia de Liberao Otimizao do modelo de
consistncia fraca. Premissas:

Antes de qualquer operaes de leitura ou escrita, todas as
operaes de obteno (Acquire) devem ser executadas;

Antes de um acesso de liberao (Release) ser executado, todas as
operaes de leitura ou escrita na memria devem ser executadas;

Acessos especiais (Acquire ou Release) devem ser sequencialmente
consistentes.
351
Consistncia de Liberao Preguiosa Est baseado no
modelo de consistncia de liberao deixando menos rgidas
as suas condies. No se exige que antes de um acesso de
liberao, todas as operaes de leitura e escrita na memria
tenham sido executadas.

Este modelo procura retardar o mximo possvel a atualizao
das variveis compartilhadas.

A atualizao ocorre somente quando o processo ou
processador requisitar aquele valor atualizado.
352
Consistncia de Entrada Estabelece que cada varivel de
sincronizao seja associada com uma ou mais variveis
compartilhadas.

Obtenes (Acquires) ou liberaes (Releases) s mantm
atualizadas variveis compartilhadas associadas com
determinadas variveis de sincronizao.

O modelo de memria do JAVA equivalente ao modelo de
consistncia de entrada:
Locks so associados com os objetos

Valores armazenados em caches locais somente so requisitados para
leitura em uma memria global quando locks so obtidos ou liberados.
353
Consistncia de Entrada
Quando o processador P2 tentou efetuar a leitura de uma varivel
compartilhada sem, antecipadamente, realizar uma obteno (Acquire) do
seu lock, o valor retornado foi nulo.
Cada varivel compartilhada possui um lock (varivel de
sincronizao), validando o modelo de consistncia de
entrada.
354
DSM Modelos de Consistncia (Consideraes)
Os modelos de consistncia sincronizados requerem um
maior esforo do sistema, pois exigem uma memria global
sincronizada.

Isso se torna aceitvel diante da solidez destes modelos e
do custo de cada acesso de memria em um sistema
sequencialmente consistente que muito maior que o custo
da sincronizao.

Os modelos sincronizados apresentam vantagens sobre os
modelos ordenados, sendo os mais utilizados atualmente.
355
DSM Software
IVY (Integrated Virtual Shared-Memory)
Itens compartilhados so encapsulados no formato de pginas de
memria (extenso do mecanismo de memria virtual).
Arquitetura
A arquitetura do IVY constituda de cinco mdulos:

- Gerenciador de Processos (Process Management)

- Alocao de Memria (Memory Allocation)

- Inicializao (Initialization)

- Operao Remota (Remote Operation)

- Mapeamento de Memria (Memory Mapping)
356
DSM IVY Arquitetura
Contm um conjunto de primitivas que podem ser usadas pelas aplicaes que iro
compartilhar a memria virtual (MV).
357
Faz o mapeamento das
memrias locais para o
espao de endereamento
da MV compartilhada.

Visa manter o espao de
endereamento coerente,
retornando para uma
operao de leitura sempre
o ltimo valor escrito em
uma mesma posio de
memria.
DSM IVY Arquitetura
358
Faz o mapeamento das
memrias locais para o
espao de endereamento
da MV compartilhada.

Visa manter o espao de
endereamento coerente,
retornando para uma
operao de leitura sempre
o ltimo valor escrito em
uma mesma posio de
memria.
Realiza a comunicao entre
os processos das aplicaes
que compartilham a MV.
DSM IVY Arquitetura
359
Semelhante MV normal (a CPU ao tentar acessar uma posio de
memria em uma pgina que no se localiza na sua memria fsica
ocorre uma page fault que fica a espera da recuperao da referida
pgina de outra mquina).

Uma cpia desta pgina enviada para o nodo que a est requisitando,
o que gera mltiplas cpias da mesma pgina em diferentes nodos do
sistema (controlado pelo MRSW e protocolo de invalidao).
DSM IVY Funcionamento
360
Semelhante MV normal (a CPU ao tentar acessar uma posio de
memria em uma pgina que no se localiza na sua memria fsica
ocorre uma page fault que fica a espera da recuperao da referida
pgina de outra mquina).

Uma cpia desta pgina enviada para o nodo que a est requisitando,
o que gera mltiplas cpias da mesma pgina em diferentes nodos do
sistema (controlado pelo MRSW e protocolo de invalidao).

Utiliza o modelo de consistncia sequencial (todas as CPUs iro
enxergar as escritas na memria na ordem determinada pelos processos
que esto executar e no na ordem que elas realmente foram
realizadas).

Modelo extremamente custoso em termos de comunicao entre as
CPUs, frequentemente prejudicando a performance do sistema.
361
362
4. Comunicao em SDs
Taxonomia da
Distribudos
363
Tuple Spaces
364
Tuple Spaces
Possibilita a comunicao entre processos de forma indireta
ao disponibilizar um espao para compartilhamento que
permite a escrita e leitura de tuplas.

As tuplas so acessadas por correspondncia de padro de
contedo (pattern matching on content) e no por endereo
(estratgia memria endereada por contedo ou memria
associativa).
365
Tuple Spaces
Possibilita a comunicao entre processos de forma indireta
ao disponibilizar um espao para compartilhamento que
permite a escrita e leitura de tuplas.

As tuplas so acessadas por correspondncia de padro de
contedo (pattern matching on content) e no por endereo
(estratgia memria endereada por contedo ou memria
associativa).

A comunicao por Tuple Spaces (TS) tem sido muito utilizada
no campo da computao ubqua.

Softwares: Linda, Agora, JavaSpaces, TSpaces (IBM).
366
Tuple Spaces Estrutura
Processos se comunicam atravs de um espao compartilhado de
tuplas. Tuplas consistem de uma sequncia de um ou mais campos
de dados (Ex. <"fred", 1958>; <"sid", 1964> e <4, 9,8, "Yes">)
367
Tuple Spaces Funcionamento
Qualquer combinao de tipos de tuplas podem existir no mesmo
Tuple Space. Processos compartilham dados ao acessar o mesmo
espao de tuplas atravs de operaes:

write: Processo insere uma tupla no espao de tuplas sem afetar tuplas
pr-existentes.

read: Processo l (devolve) uma tupla sem afetar os contedos do
espao de tuplas.

take: Tambm retorna uma tupla, mas tambm a remove do espao.
368
Qualquer combinao de tipos de tuplas podem existir no mesmo
Tuple Space. Processos compartilham dados ao acessar o mesmo
espao de tuplas atravs de operaes:

write: Processo insere uma tupla no espao de tuplas sem afetar tuplas
pr-existentes.

read: Processo l (devolve) uma tupla sem afetar os contedos do
espao de tuplas.

take: Tambm retorna uma tupla, mas tambm a remove do espao.
Ao manipular uma tupla do espao de tuplas, um processo fornece
uma especificao da tupla e o espao retorna qualquer tupla que
coincide com essa especificao.
369
Para sincronizao entre os processos, as operaes read e
take bloqueiam at que encontrem uma tupla correspondente.

A especificao de uma tupla inclui o nmero de campos,
valores ou tipos de campos necessrios.

Exemplos:

take(<String, integer>), retorna tanto <"fred", 1958>
quanto <"sid", 1964>;

take(<String, 1958>) obtm apenas <"fred", 1958>.
370
Tuplas so imutveis. O paradigma Tuple Space no permite
acesso direto as tuplas, processos precisam substituir tuplas
no espao de duplas ao invs de modific-las.

Exemplo: Supondo que um conjunto de processos mantm e
compartilham um contador no TS. Um processo precisa
executar o cdigo abaixo para incrementar o contador no
Tuple Space myTS:

<s, count> := myTS.take(<"counter", integer>);
myTS.write(<"counter", count+1>);
371
Tuple Spaces Propriedades
Desacoplamento de Espao: Uma tupla colocada no TS
pode ser originria de vrios processos remetentes e podem
ser entregues a qualquer quantidade de potenciais
destinatrios.

Desacoplamento de Tempo: Uma tupla colocada no TS
permanecer nesse espao at ser removida e portanto o
emissor e o receptor no precisam existir no mesmo tempo.

TS proporciona um espao para o compartilhamento
distribudo de variveis.
372
Tuple Spaces Software
Linda
Foi um dos primeiros sistemas baseados em objetos, criado em 1986
introduziu o conceito de espao de tuplas.

A tupla pode ser considerada como uma unidade de memria
elementar, consistindo essencialmente em registros cujos campos so
tipados e contm os dados compartilhados entre os nodos do sistema.
373
Tuple Spaces Software
Linda
Foi um dos primeiros sistemas baseados em objetos, criado em 1986
introduziu o conceito de espao de tuplas.

A tupla pode ser considerada como uma unidade de memria
elementar, consistindo essencialmente em registros cujos campos so
tipados e contm os dados compartilhados entre os nodos do sistema.

Os dados podem ser acessados atravs operaes baseadas em um
mecanismo de reconhecimento de padres semnticos de acesso.

Utiliza o PRAM como modelo de consistncia, onde a ordem das
operaes s observada no momento do processamento de uma
determinada operao.
374
Tuple Spaces Linda Arquitetura

Consiste em:

(i) Runtime kernel, que implementa a comunicao e a
gerncia de processos;

(ii) Pr-processador ou compilador.

Teoricamente, o kernel do Linda independente de
linguagem, mas somente testes com conjuntos de bibliotecas
C e FORTRAN foram realizados.

O Linda tambm disponibiliza operadores que devem ser
utilizados nas implementaes para realizar a programao
paralela de uma aplicao.
375

Comparao Linda vs Memria Convencional

Enquanto que na memria convencional a unidade de
armazenamento o byte fsico, no Linda a unidade de
armazenamento a tupla lgica ou um conjunto ordenado de
valores;
376

Comparao Linda vs Memria Convencional

Enquanto que na memria convencional a unidade de
armazenamento o byte fsico, no Linda a unidade de
armazenamento a tupla lgica ou um conjunto ordenado de
valores;

Na memria convencional os elementos so acessados por
endereos enquanto que no Linda no h endereos e os
elementos so acessados pelo nome da tupla, sendo este nome
qualquer seleo de dados.

Enquanto que o acesso a memria convencional feito por duas
operaes read e write, no Linda h trs operaes read, add e
remove.
377
Tuple Spaces Linda Funcionamento

A comunicao entre os processos nunca ocorre diretamente entre
eles, mas atravs do espao de tuplas. Operaes:

out(t): Adiciona a tupla t ao espao de tuplas;

in(s): Recupera uma tupla t que identificada pelo template
fornecido por s. Nesta operao, o valor da tupla t atribudo a s
e a tupla t retirada do espao de tuplas.

Caso uma tupla t no seja encontrada atravs do template
fornecido por s, a execuo do processo bloqueada at que
uma tupla t do mesmo tipo do template seja encontrado.
read(s): Faz o mesmo procedimento que in(s) com a diferena
que a tupla t permanece no espao de tuplas.
378

379

Funcionamento do
espao de tuplas a
partir do comando
Out("X", 6, TRUE) em
um dos nodos.
380

Funcionamento do
espao de tuplas a
partir do comando
um dos nodos.
A tupla inserida
no TS e fica
disponvel para
os outros ns.
381

Funcionamento do
espao de tuplas a
partir do comando
um dos nodos.
A tupla inserida
no TS e fica
disponvel para
os outros ns.
N 3 executa
Read(X, int i, bool b)
para recuperar uma
informao com base
nesse template.
382

Funcionamento do
espao de tuplas a
partir do comando
um dos nodos.
A tupla inserida
no TS e fica
disponvel para
os outros ns.
N 3 executa
Read(X, int i, bool b)
para recuperar uma
informao com base
nesse template.
Os valores 6 e
TRUE so
atribudos as
variveis i e b
para o programa
que est rodando
no n 3.
383
Tuple Spaces Consideraes
Modelo original Linda considera um nico e global TS (no escalvel,
no tolerante a falhas). Outros sistemas propuseram Mltiplas TS,
incluindo a habilidade de cri-las dinamicamente (Ex. JavaSpaces).

Pesquisas: Modificar ou estender as operaes fornecidas em TS,
adaptando a semntica subjacentes.
384
Modelo original Linda considera um nico e global TS (no escalvel,
no tolerante a falhas). Outros sistemas propuseram Mltiplas TS,
incluindo a habilidade de cri-las dinamicamente (Ex. JavaSpaces).

Pesquisas: Modificar ou estender as operaes fornecidas em TS,
adaptando a semntica subjacente.

Unificar os conceitos de tuplas e Tuple Spaces atravs da modelagem
como conjuntos desordenados. Tuple Spaces so conjuntos de tuplas e
tuplas so conjunto de valores.

Mudana de paradigma: TS de tipos de itens de dados, para TS de
Objetos de Dados. Espao de Tuplas Espao de Objetos. (Ex.
JavaSpaces).
385
Tuple Spaces Linda Consideraes
Muitas implementaes de TS adotam soluo centralizada
onde o recurso TS gerenciado por um nico servidor.

Vantagens: Simplicidade.

Desvantagens: No tolerante a falhas, no escalvel.
386
Tuple Spaces Linda Consideraes
Muitas implementaes de TS adotam soluo centralizada
onde o recurso TS gerenciado por um nico servidor.

Vantagens: Simplicidade.

Desvantagens: No tolerante a falhas, no escalvel.

Estratgias para superar as desvantagens:

Abordagem P2P: Todos os ns cooperam para disponibilizar o
TS. (Ex. PeerSpaces, desenvolvido usando middleware JXTA).

Replicao: Abordagem Mquina de Estado. TS faz troca de
estados em resposta aos eventos recebidos de outras rplicas ou
do ambiente.
387
Replicaes
e Operaes
no TS
388
TSSs (Tuple Space Servers)

Tuplas so particionadas entre TSSs.

No tem replicao de tuplas (apenas uma cpia)
Quando uma tupla
colocada num TS, um
algoritmo hashing usado
para selecionar um dos
TSSs a ser usado.

CCT320 - 4 - Comunicação em SD

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CCT320 - 4 - Comunicação em SD

Загружено:

Авторское право:

Доступные форматы

CCT320 Sistemas Distribudos

Вам также может понравиться