03 ComunicacaoProcessos (C4)

Prévia do material em texto

Comunicação entre processos
Sistemas Distribuídos
Bacharelado em Sistemas de Informação
UENP – CLM
1
Prof. MSc. Bruno Miguel – brunomiguel@uenp.edu.br
Roteiro
1. Introdução - camadas de middleware
2. API da Internet
3. Representação externa de dados
4. Comunicação cliente-servidor
5. Comunicação em grupo
2
• “middleware”: camada de software que fornece uma abstração de 
programação, assim como o mascaramento da heterogeneidade 
das redes, do hardware, sistemas operacionais e linguagens.
• Exemplos:
▫ CORBA - Common Object Request Broquer
▫ Java RMI - Remote Method Invocation
• Modelo computacional uniforme para desenvolvedor de serviços e 
de aplicativos distribuídos
Aplicações, serviços
Camadas de 
Middleware
Protocolo de requisição-resposta
Empacotamento e representação de dados externa
UDP and TCP
RMI and RPC
3
API para Protocolos da Internet
• Passagem de mensagens é a forma mais 
primitiva de comunicação entre processos de 
um sistema distribuído
• Duas operações: send e receive
• Mensagem é um conjunto de bytes, como uma 
estrutura
• Um processo envia com send uma mensagem 
a um processo destino, que usa receive para 
receber
4
Sincronismo na comunicação
• Cada destino de mensagem está associado a uma fila
▫ Processo que envia acrescenta mensagem à fila remota
▫ Processo que recebe remove mensagem de fila local
• Envio síncrono: processo remetente bloqueia até que 
receptor receba a mensagem
• Recepção síncrona: processo receptor bloqueia até que 
exista uma mensagem a ser lida
• Recepção assíncrona: receptor solicita mensagem e 
indica em que endereço ela deve ser copiada quando 
chegar
• Recepção não-bloqueante: processo tenta receber mas 
retorna com erro se não há mensagem
5
Destinos de mensagens
• Sistema de mensagens pode usar: id de 
processo, IP: porta,caixa postal, etc.
• No caso de um serviço que é disponibilizado 
por um processo servidor, clientes precisam 
saber para onde enviar mensagens
• Modelos:
– um-para-um
– um-para-vários (também há vários-para-vários)
6
Confiabilidade e ordenamento
• A rede “subjacente” de comunicação que 
transporta mensagens pode perder mensagens, 
corromper, reordenar ou duplicar
• Confiabilidade: se apesar disso, mensagens são 
entregues íntegras, em ordem e sem duplicação
• Ordenamento: algumas aplicações exigem que 
mensagens sejam entregues na ordem que foram 
enviadas
• Um-para-um é simples, mas um-para-vários e 
vários-para vários impõem questões de 
ordenamento mais difíceis de se resolver
7
Protocolos de transporte
1. Soquetes UDP e TCP (idéia surgida com o sistema UNIX de Berkeley -BSD 
Unix)
▫ Abstração para representar a comunicação entre processos:
▫ a comunicação entre dois processos consiste na transmissão de uma 
mensagem de um soquete num processo para um soquete noutro 
processo.
Mensagem
Porta conhecida
Porta cliente socketsocket
Endereço de Internet= 138.37.88.249
Endereço de Internet= 138.37.94.248
Outras portas
cliente servidor
8
• Para receber mensagens, um processo pode usar várias 
portas simultaneamente, mas não pode partilhar uma 
porta com outro processo diferente no mesmo computador 
(Exceção: processos que usem IP multicast) . 
• Cada soquete é associado a um determinado protocolo, 
UDP ou TCP.
• Protocolo de transporte TCP (com conexão)
– confiabilidade: recupera perda de pacotes, ordena, informa 
sobre perdas “permanentes”
– stream (fluxo) de bytes
• Protocolo de transporte UDP (sem conexão)
– requisições ou respostas podem ser perdidas, atrasadas, 
duplicadas ou entregues fora de ordem
– fronteiras entre mensagens
Protocolos de transporte
9
Protocolos de transporte
• Nos protocolos internet, as mensagens são 
enviadas para um par(endereço internet, nº 
de uma porta). 
• O soquete de um processo tem que ser 
conectado a uma porta local para que possa 
começar a receber mensagens.
• Uma vez criado tanto serve para receber 
como para enviar mensagens. O número de 
portas disponíveis por computador é 2**16. 
10
Comunicação através do protocolo UDP
A comunicação entre dois processos é 
feita através dos métodos send e receive.
• um item de dados (“datagram”) é enviado 
por UDP sem confirmação 
(“acknowledgent”) nem reenvio
• qualquer processo que queira enviar ou 
receber uma mensagem tem que criar um 
soquete com o IP da máquina local e o 
número de uma porta local
11
...
• a porta do servidor terá que ser conhecida 
pelos processos clientes
• o cliente pode usar qualquer porta local 
para conectar o seu soquete
• o processo que invocar o método 
receive(cliente ou servidor) recebe o IP e a 
porta do processo que enviou a mensagem, 
juntamente com os dados da mensagem.
12
Comunicação através do protocolo 
UDP
Tamanho da mensagem. 
• O receptor da mensagem, tem que definir um 
array (buffer) com dimensão suficiente para os 
dados da mensagem . 
• O IP permite mensagens até 216 bytes, (tamanho 
padrão -8KB). 
• Mensagens maiores que o buffer definido, serão 
truncadas
13
Comunicação através do protocolo UDP
Operações bloqueáveis
•send–não bloqueável
•O processo retorna do send assim que a mensagem é enviada
•No destino, é colocada na fila do soquete respectivo
•Se nenhum processo estiver ligado ao soquete a mensagem é descartada
•receive–bloqueável
•O processo que executa o receive, bloqueia até que consiga ler a 
mensagem para o buffer do processo
• Enquanto espera por uma mensagem o processo pode criar uma nova 
thread para executar outras tarefas
•Ao soquete pode ser associado um timeout, findo o qual o receive
desbloqueia.
14
Comunicação através do protocolo 
UDP
• Modelo de Falhas
– Tipo de falhas que podem ocorrer:
• Falha por omissão –a mensagem não chega porque:
• Buffer cheio local ou remotamente 
• Erro de conteúdo -checksum error
• Falha de ordenamento –as mensagens chegam fora de 
ordem 
15
Comunicação através do protocolo UDP
•Utilização do protocolo UDP:
• Aplicações onde são aceitáveis avarias de omissão. 
•Domain Naming Service-DNS. 
•Transmissão de imagem.
•Classe DatagramSocket em Java. 
•permite criar um soquete na máquina local para o processo 
corrente. 
•construtor sem argumentos, usa o primeiro porta disponível. 
construtor com argumentos especifica-se o nº da porta. 
•Se a porta está sendo usada é gerada a excepção
SocketException.
16
Comunicação através do protocolo 
UDP
• Classe DatagramPacket em Java
• Ao instanciar um DatagramP acket para enviar 
uma mensagem, usar o construtor com os 
parâmetros: 
• um array de bytes que contém a mensagem, 
• o comprimento da mensagem
• o endereço Internet do soquete destino (objeto do tipo 
InetAddress)
• nº da porta do soquete destino
17
Comunicação através do protocolo UDP
Classe DatagramPacket em Java
•Ao instanciar um DatagramPacket para receber uma mensagem, 
usar o construtor com os parâmetros: 
• referência de um buffer de memória para onde a mensagem 
será transferida
• o comprimento desse buffer
• mensagem é colocada neste objeto do tipo DatagramPacket.
• Para extrair os dados da mensagem usa-se o método
getData() da classe DatagramPacket
•Os métodos getPort() e getAddress() devolvem o nº do porta e 
o IP do processo emissor, respectivamente.
18
Comunicação através do protocolo 
UDP
• Exemplo de utilização de soquetes UDP em Java:
• Um processo cliente envia uma mensagem para um 
nó remoto e recebe em resposta a mesma mensagem. 
A mensagem e o nome da máquina remota são 
passados como parâmetros do programa. 
• O processo servidor fica à espera de mensagens na 
porta 6789. Ao receber uma mensagem, extrai a 
mensagem e envia-ade volta para o cliente, para o IP 
e a porta recebidas. 
19
UDP: cliente envia requisição e recebe resposta
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
// args give message contents and server hostname
DatagramSocket aSocket = null;
try {
aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost,
serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = newDatagramPacket(buffer, buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
} catch (SocketException e){System.out.println("Socket: " + 
e.getMessage());
} catch (IOException e){System.out.println("IO: " + e.getMessage());
} finally {
if (aSocket != null) aSocket.close();
}
}
}
20
import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
DatagramSocket aSocket = null;
try{
aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer, buffer.length);
aSocket.receive(request);
DatagramPacket reply = new DatagramPacket(request.getData(),
request.getLength(), request.getAddress(), request.getPort());
aSocket.send(reply);
}
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e) {System.out.println("IO: " + e.getMessage());
} 
finally {
if(aSocket != null) aSocket.close();
}
}
} 
UDP: servidor recebe requisição e envia resposta
21
Utilização da abstração stream para ler/escrever 
dados.
• Tamanho das mensagens:
– a aplicação é que decide quantos bytes devem ser 
enviados ou lidos da stream, sem a preocupação 
do tamanho máximo de pacotes
• Perda de Mensagens:
– O protocolo TCP usa um esquema de confirmação 
de recepção das mensagens. Se necessário 
retransmite a mensagem.
Comunicação através do protocolo TCP
22
Comunicação através do protocolo TCP
• Controle do fluxo de execução:
– O TCP tenta uniformizar as velocidades dos processos que 
lêem e escrevem de/numa stream. Se “quem” escreve é 
muito mais rápido do que “quem” lê, então o processo que 
escreve é bloqueado até que o outro processo leia dados 
suficientes
• Ordenação e duplicação de mensagens:
– Identificadores de mensagens são associados com cada 
pacote de dados, permitindo ao receptor detectar e 
rejeitar mensagens duplicadas ou reordenar mensagens 
fora de ordem.
23
• Destino das mensagens:
– -Um par de processos estabelece uma conexão antes de 
poderem comunicar por uma stream. A partir dessa ligação, 
podem comunicar sem terem de indicar o endereço IP nem o 
nº de porta. 
• Modelo de comunicação:
– Quando dois processos tentam estabelecer uma ligação 
através de Soquetes TCP, um dos processos desempenha o 
papel de cliente e outro de servidor. Depois de estabelecida a 
ligação podem comportar-se como processos pares
Comunicação através do protocolo TCP
24
Comunicação através do protocolo TCP
Cliente:
– Cria um objeto do tipo Soquete que tenta estabelecer uma ligação com uma 
porta de um servidor, numa máquina remota. Para estabelecer esta ligação é 
necessário indicar o endereço IP e a porta da máquina remota.
Servidor:
– Cria um objeto do tipo “listening” soquete associado à porta servidora. Este 
soquete possui um método que fica bloqueado até que receba um pedido de 
ligação à portar correspondente. 
– Quando chega o pedido de ligação, o servidor aceita-a instanciando um novo 
soquete que, tal como o soquete do cliente, tem duas streams associadas, 
uma para saída outra para entrada de dados.
25
Classes em Java
• Socket, ServerSocket
• Multi-threaded serversem
Modelo de Falhas
Streams TCP usam:
– Checksums para detectar e rejeitar pacotes corrompidos
– número de seqüência para detectar e rejeitar pacotes duplicados
– Timeout de retransmissão para lidar com pacotes perdidos 
Se uma mensagem não chega porque o sistema está congestionado, o sistema 
não recebe a confirmação da recepção da mensagem, reenvia sucessivamente 
a mensagem até que a conexão é cancelada após um certo tempo. 
A mensagem não é transmitida, os processos participantes ficam sem saber o que 
aconteceu!falha na rede? falha do outro processo?
Utilização do protocolo TCP.
– Os serviços HTTP, FTP, Telnet, SMTP, ...
Comunicação através do protocolo TCP
26
Pt2-Representação externa de dados
• Em um programa, informações são representadas via 
estruturas de dados
• Para transmitir uma estrutura entre processos de máquinas 
diferentes, é necessário colocar a estrutura em uma 
mensagem na forma de um vetor de bytes
• Este vetor de bytes precisa ser “interpretado” na máquina 
destino (formato pode ser incompatível)
• Representação de tipos primitivos pode diferir, como inteiros 
em ordem de bits diferente, representação de ponto 
flutuante, e codificação de caracteres
27
Montando e desmontando dados
• Representação externa de dados: uma forma 
de descrever os dados de forma que seja 
entendida em diferentes máquinas
• Marshalling (montagem): pegar um conjunto 
de dados e montá-los em um formato 
conveniente para transmissão de uma 
mensagem
• Unmarshalling (desmontagem): desmontar o 
conteúdo recebido e transformar no conjunto 
de dados equivalente
28
Representações Externas: Três estudos de caso
• 1. Representação de dados comum do CORBA
• 2. Serialização de objetos da linguagem Java
• 3. XML (Extensible Markup Language)
29
CDR CORBA
• Common Data Representation (CDR): representação comum 
de dados, conforme definida no CORBA 2.0 (2004)
• Pode representar todos os argumentos que podem ser 
passados ou retornados, incluindo 16 tipos primitivos
• Formato é o do transmissor e especificado na mensagem, 
receptor converte caso necessário
• Tipo e ordem dos dados não são transmitidos com a 
mensagem, pois assume que receptor saiba de antemão
• Tipos de dados a serem transmitidos são especificados 
através da Interface Definition Language (IDL)
30
Tipo Representação
sequence comprimento (unsigned long) seguido de seus
elementos, em ordem
string comprimento (unsigned long) seguido pelos caracteres
que a compõem (um caracter pode ocupar mais de um
byte)
array elementos de vetor, fornecidos em ordem (nenhum
comprimento é especificado, porque é fixo)
struct na ordem de declaração dos componentes
enumerated unsigned long (os valores são especificados na ordem
declarada)
union identificador de tipo seguido do membro selecionado
CDR CORBA
31
• Em Java, tanto objetos como tipos primitivos podem ser passados como 
argumentos e resultados em comunicações remotas (“invocação remota de 
método” ou RMI)
• Modificador “implements Serializable” após nome da classe permite que a 
mesma seja serializada
• Serializar um objeto em Java consiste em transformar seu conteúdo em uma série 
de bytes
• Destino que faz a “deserialização” não possui nenhum conhecimento sobre a 
forma original dos dados
• Nome e versão da classe são incluídos nos dados, e receptor usa isso para 
carregar a classe correta
• Objetos que contenham referências para outros objetos: 
– o objeto referenciado é também serializado 
– a cada referência é associado um número (handle)
– em posteriores serializações do mesmo objeto é usado o seu handle
(economiza-se tempo e espaço) 
Serialização em Java
32
• Seja a classe 
public class Pessoa implements Serializable {
private String nome;
private String local;
private int anoNasc;
public Pessoa (Stringn, String l, int i){
nome = n;
lugar= l;
anoNasc = i; }
} 
Serialização em Java
The true serialized form contains additional type markers; h0 and h1 are handles
Serialized values
Pessoa
3
1976
8-byte version number
int anoNasc
7 Ronaldo
java.lang.String
nome:
14 Rio de Janeiro
h0
java.lang.String
local:
h1
Explanation
class name, version number
number, type and name of 
instance variables 
values of instance variables
Seja o objeto:
Pessoa p = new Pessoa (“Ronaldo”, “Rio de Janeiro”, 1976);
33
Serialização em Java
• Para serializar o objeto p, usa-se o método:
void writeObject(Object), da classe ObjectOutputStream
• Para desserializar:
Object readObject() da classe ObjectInputStream
• Para escrever /ler num arquivo usam-se as streams
FileOutputStream e FileInputStream
• Para escrever/ler de um Socket usam-se as streams de output 
e input associadas ao socket
• Com o RMI a serialização e a desserialização são feitas pelo 
middleware
34
Serialização em Java:Referências para objetos
• Uma referência para um objeto remoto é um identificador de um objeto 
válido em todo o âmbito do sistema distribuído.
• Seja um objeto remoto a que queremos acessar, a sua referência deverá 
existir no processo local, na mensagem que enviamos ao objeto e no 
processo remoto que é quem possui a instância do objeto cujo método 
estamos invocando.
• Referências remotas devem ser geradas de forma a garantir unicidade no 
espaço e no tempo:
• Por ex.:
– Concatenando o endereço IP do computador com o nº da porta do processo 
que contém o objeto, com a hora da sua criação e ainda com um nº 
seqüencial para o objeto em questão. Formato de uma referência para um 
objeto remoto: 
Internet address port number time object number
interface of 
remote object
32 bits 32 bits 32 bits 32 bits
35
• Extensible Markup Language - “linguagem de marcação” definida 
pelo W3C para uso na Web
• Representa um texto e os detalhes de sua estrutura 
• Dados são rotulados com tags, que descrevem a estrutura lógica 
dos dados
• Pode ser usada para armazenar (em um repositório) ou transferir 
dados pela rede de forma portátil
XML
<pessoa id="123456789">
<nome>Ronaldo</nome>
<local>Rio de Janeiro</local>
<ano>1976</ano>
<!-- a comment -->
</pessoa >
36
• Linguagem extensível: usuários definem suas próprias tags
• Programa que codifica os dados binários em XML para enviar ou 
gravar deve usar um conjunto de tags pré-estabelecido com 
quem decodifica (recebe ou lê)
• Esquema XML: define os elementos e atributos que podem 
aparecer em um documento, aninhamento, etc.
• Existem implementações de API para marshaling e
• unmarshaling de objetos em diversas linguagens, incluíndo Java 
e Python
XML
37
• Formato texto para codificação de dados e o uso de tags tem as 
seguintes vantagens:
– Independência de palataforma
– Legível a humanos
– Entretanto, dados codificados em XML apresentam
• sobrecarga em termos de:
– Espaço de armazenamento
– Codificação e decodificação
– Buscas (não é um array, e sim lista)
– Existem críticas sobre essa ineficiência. Trade-off.
Vantagens e Desvantagens de XML
38
JSON
• JSON = JavaScript Object Notation
• Baseado em Javascript
• é em formato independente de linguagem;
• usa convenções que são familiares às 
linguagens C e familiares, incluindo C++, C#, 
Java, JavaScript, Perl, Python e muitas outras.
39
JSON
• JSON está constituído em duas estruturas:
• Uma coleção de pares nome/valor. Em várias 
linguagens, isto é caracterizado arrays
associativas.
• Uma lista ordenada de valores. Na maioria das 
linguagens, isto é caracterizado como 
um array.
40
JSON - Formato
• Objetos
• Vetores
41
JSON - Formato
• Valores podem ser...
42
JSON - Formato
• String
43
JSON - Formato
• Número
44
JSON – Exemplo vs XML
{“Empregados":[
{ “Nome":"John", “SobreNome":"Doe" },
{ “Nome":"Anna", "SobreNome":"Smith" },
{ “Nome":"Peter", “SobreNome":"Jones" }
]}
45
<empregados>
<empregado>
<Nome>John</Nome> <SobreNome>Doe</SobreNome>
</ empregado >
< empregado >
<Nome>Anna</Nome> <SobreNome>Smith</SobreNome>
</ empregado >
< empregado >
<Nome>Peter</Nome> <SobreNome>Jones</SobreNome>
</ empregado >
</ empregados >
JSON e XML - Similaridades 
• Ambos são autodescritores (Interpretável);
• Hierárquicos (Valores dentro de Valores);
• Podem ser empacotados e usados em várias
linguagens de programação;
• Podem ser encaminhados via 
XMLHttpRequest
46
JSON e XML - Diferenças
• JSON não usa tag final;
• JSON é menor;
• JSON é mais rápido para leitura e escrita;
• JSON pode utilizar vetores (arrays);
• XML precisa ser empacotado por um XML 
parser. JSON pode ser empacotado por uma
função padrão do JavaScript;
47
Pt3 - Comunicação Cliente Servidor: O protocolo pedido-
resposta
• É necessário um protocolo que, utilizando um mecanismo de transporte 
(e.g. TCP ou UDP), permita a conversação entre cliente e servidor
– Usado pela maioria dos sistemas que suportam RPC e RMI
– O protocolo para RMI é implementado usando três operações base:
– doOperation -ativa um método remoto
– getRequest -espera por pedidos de clientes 
– sendReplay -envia a resposta ao cliente
Request
ServerClient
doOperation
(wait)
(continuation)
Reply
message
getRequest
execute method
message
select object
sendReply
48
Comunicação Cliente Servidor
Implementação usando o protocolo UDP
public byte[] doOperation
(RemoteObjectRef o, int methodId, byte[] 
arguments)
Envia uma mensagem de pedido (request) a um objecto
remoto e retorna uma resposta (reply).
Os argumentos especificam o objeto remoto,o método 
a ser invocado e os argumentos desse método.
Depois de enviar a mensagem o processo invoca uma 
operação de receive ficando bloqueado até à chegada 
da resposta
49
Comunicação Cliente Servidor
• public byte[] getRequest();
• Espera por pedidos de clientes.
• O processo servidor quando recebe um pedido de um 
cliente, executa o método solicitado e envia a resposta 
correspondente ativando o método sendReply
• public void sendReply (byte[] reply, InetAddress clientHost, 
int clientPort);
• Envia a resposta ao cliente usando o seu endereço internet 
e porta.
• Quando o cliente recebe a resposta Implementação usando 
o protocolo UDP
50
• 1º campo: Tipo da mensagem: 0 se pedido, 1 se resposta
• 2º campo: 
• Identificador único para cada mensagem do cliente, o servidor copia-o e reenvia-o 
na resposta, permite ao cliente verificar se a resposta diz respeito ao pedido que 
fez.
• 3º campo: referência do objeto remoto ;
• 4º campo: identificador de qual dos métodos é invocado
• 5º campo: argumentos do método invocado devidamente serializados
messageType
requestId
objectReference
methodId
arguments
int (0=Request, 1= Reply)
int
RemoteObjectRef
int or Method
array of bytes
Estrutura das mensagens de pedido e resposta 
Comunicação Cliente Servidor
51
• Para ser possível um sistema confiável de entrega de 
mensagens é necessário que cada mensagem tenha um 
identificador único.
• Identificador de uma mensagem:
– requestId + número do porta (do emissor) + endereço IP 
(do emissor). 
– requestId –inteiro, incrementado pelo cliente sempre que 
envia uma mensagem (quando atinge o valor inteiro 
máximo volta a zero) (é único para o emissor).
– a porta e o IP do emissor tornam o identificador da 
mensagem único no sistema distribuído.
– (podem ser retirados das mensagens recebida no caso de 
a implementação ser em UDP)
Comunicação Cliente Servidor
52Modelo de Falhas do protocolo pedido-resposta
• Se as três operações são implementadas sobre UDP, então sofrem do 
mesmo tipo de falhas de comunicação: 
– Falhas de omissão.
– Mensagens não são garantidamente entregues por ordem.
• Além disso, podem ocorrer falhas no processo:
– assumem-se “crash failures”, se o processo parar, permanece parado não 
produzindo valores arbitrários
• Timeouts
– Para resolver o problema das mensagens perdidas, a doOperation permite 
definir um serviço de tempo, timeout
– Após esgotar o timeout, a operação pode retornar com uma indicação de erro. 
Geralmente, em vez de retornar, reenvia a mensagem várias vezes para ter a 
certeza que o problema foi “o fim” do servidor e não mensagens perdidas.
• O que fazer com as mensagens de pedido repetidas !?
– -O servidor, se estiver a funcionar, pode detectar repetições através do 
requestId
53
Perda da mensagem de resposta
–Se a resposta se perdeu, o servidor ao receber novo pedido 
pode processar o método (caso seja idempotente) novamente 
e reenviar os resultados.
–Operações Idempotentes –têm o mesmo efeito se 
executadas uma ou mais vezes.
– Ex. Operação que adiciona um elemento a um conjunto
–Contra-exemplo: adicionar um montante a uma conta 
bancária 
–Em vez de re-executar o método, pode reenviar a mensagem, 
desde que fique armazenada num arquivo que faz o registro 
do histórico do servidor.
Modelo de Falhas do protocolo pedido-resposta
54
• Problema –consumo de memória. 
– Solução –o servidor ser capaz de identificar que o registro pode 
ser apagado do histórico, exemplo: quando a resposta tiver sido 
recebida.
– Como o cliente só pode enviar um pedido de cada vez, pode 
considerar que a recepção de um novo pedido é a confirmação 
da última resposta. 
– Dependendo do protocolo de transporte podem ser oferecidas 
diferentes garantias quanto ao número de execuções de um 
pedido:
• Maybe(talvez) –
• At-least-once (pelo-menos-uma-vez)
• At-most-once (no máximo-uma-vez)
Modelo de Falhas do protocolo pedido-resposta
55
Comunicação em Grupo
• Multicast é a transmissão de um-para-vários 
– muitas instâncias de um-para-um não é o modelo mais eficiente;
• Exemplos de uso:
– Tolerância a falhas baseado em um conjunto de servidores replicados
– Localização de servidores de descoberta na interligação em redes 
espontâneas;
– Melhor desempenho através da replicação de dados, através do uso 
de caches (que precisam ser mantidas atualizadas);
– Propagação de notificações de eventos: por exemplo, um sistema de 
eventos avisando seus usuários dos próximos eventos;
• Existem diferentes “níveis de garantia” quanto à 
confiabilidade e ordenamento na entrega de mensagens
56
Multicast IP
• Implementação de multicast em nível de rede
• Endereço IP classe D (224.0.0.0 / 239.255.255.255)
• Transmissor envia um datagrama, que é replicado 
através de uma “árvore de roteadores” na rede
• Datagrama é eficientemente propagado para onde 
existam destinatários (assinando o grupo dado pelo 
endereço IP classe D)
• API de sockets possui suporte para Multicast; em 
Java, MulticastSocket e joinGroup
• Não há garantias de confiabilidade nem 
ordenamento
57
Efeito da confiabilidade no multicast
• Tolerância a falhas baseado em um conjunto de servidores 
replicados: exige que todos os servidores recebam todas as 
mensagens de requisição, ou as cópias ficarão inconsistentes;
• Localização de servidores de descoberta na interligação em 
redes espontâneas: desde que qualquer processo que queira 
localizar reenvie periodicamente uma consulta, não há 
problema maior;
• Melhor desempenho através da replicação de dados: imagine 
um sistema em que os próprios dados replicados são 
distribuídos com multicast; o impacto de perdas dependeria 
da importância de todas as réplicas estarem sincronizadas;
• Propagação de notificações de eventos: a aplicação específica 
determina a necessidade de confiabilidade. 
58