Não É Possível Estabelecer Um Limite Do Tempo Que Se Leva para Que Tal Servidor Envie A Resposta Ao Cliente

Slides for Chapter 4:
Comunicação entre processos
From Coulouris, Dollimore and Kindberg

Distributed Systems:
Concepts and Design
Edition 4, © Addison-Wesley 2005
Agenda
 API para comunicação entre processos

 Representação externa de dados
 Comunicação cliente-servidor
 Comunicação em Grupo
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
API para Comunicação
 Interface de programação para utilizar os serviços

básicos oferecidos pelo subsistema de comunicação
subjacente
 Tópicos abordados:
Características da comunicação entre processos
Resolução de nomes
Comunicação usando sockets
Características de Comunicação
 Duas operações básicas: send e receive

Definidas em termos de destinos e mensagens
Implementadas através de “filas” (buffers) de mensagens
em cada lado da comunicação
Podem envolver a sincronização entre o processo que
envia mensagem e o processo que a recebe
 Comunicação síncrona
Envio e recebimento sincronizados para cada mensagem
(operações “bloqueantes”)
send - bloqueia o processo remetente até que o receive
correspondente tenha sido executado no lado servidor
receive - bloqueia o processo de destino até a chegada
de uma mensagem
 Comunicação assíncrona
Envio e recebimento sem sincronização (operações “não-
bloqueantes”)
send
libera o processo remetente assim que a mensagem
tiver sido copiada para a fila (buffer) local;
execução e transmissão ocorrem em paralelo.
 receive
libera o processo destino antes da chegada da
mensagem, a qual deve ser retirada da fila
posteriormente, através de um mecanismo de pooling
ou de notificação (callback)
 Comunicação síncrona é a mais usada na prática!

Operações não-bloqueantes ainda podem exigir alguma
forma de sincronização no nível da aplicação
 Operações bloqueantes podem ser utilizadas sem

interromper totalmente o processo que as invocou
quando executadas em fluxos (threads) separados de
execução
 Destino = (endereço de rede + porta)

Endereço de rede corresponde ao IP do computador onde é executado o
processo que receberá a mensagem
Porta corresponde ao destino de uma mensagem dentro de um mesmo
computador (especificado como um inteiro entre 0 e 65535: 216 portas)
A cada porta é associado um único processo destino (exceto no
caso de portas usadas para difusão seletiva de mensagens)
Um mesmo processo pode ter múltiplas portas associadas a ele
Qualquer processo que conhece o número da porta de outro
processo pode enviar mensagens para ele através dessa porta
Servidores costumam divulgar suas portas para os seus clientes ou
usam portas padrão (ex.: HTTP = 80, FTP = 21, etc.)
 Não há transparência de localização!
 Destinos transparentes quanto à localização podem ser

obtidos da seguinte forma:
Utilizando nomes simbólicos para referenciar endereços
de rede e um serviço de nomes para traduzir nomes em
endereços em tempo de execução
Forma mais comum de implementar transparência de
localização na Internet!
DNS
Suporta re-alocação dos serviços e distribuição de
carga
 Confiabilidade
Definida em termos da validade e da integridade do
serviço de comunicação
Validade: garantia de que as mensagens serão
entregues mesmo diante de um número “razoável” de
falhas de transmissão (perdas de pacotes)
Integridade: garantia de que as mensagens serão
entregues sem serem corrompidas ou duplicadas
 Ordenação
Serviço de comunicação deve garantir que as mensagens
serão entregues na ordem em que são enviadas pelo
processo remetente
Entrega fora da ordem de envio pode ser considerada
falha de transmissão por aplicações que dependem da
ordem das mensagens
 API de Java para resolução de nomes de domínio

 Implementada através da classe InetAddress
Métodos encapsulam localização e consulta a servidor DNS
Independente do formato da representação interna (IPv4, IPv6, ...)
Programação de sockets com TCP
Socket: uma porta entre o processo de aplicação e o

protocolo de transporte fim-a-fim (UDP ou TCP)
Serviço TCP: transferência confiável de bytes de um
processo para outro
2 - 14
Comunicação usando sockets (I)
 Socket: abstração para cada um dos extremos

(endpoints) da comunicação entre dois processos
Originário do BSD UNIX e posteriormente incorporado em
virtualmente todos os outros sistemas operacionais
Usado tanto para comunicação assíncrona (protocolo
UDP) quanto para comunicação síncrona (protocolo
TCP)
Comunicação usando sockets (II)
 Comunicação exige a criação de um socket pelo processo

remetente e de um outro pelo processo destinatário
socket do destinatário (servidor) deve estar
exclusivamente acoplado a uma porta do computador local
Um mesmo socket pode ser usado tanto para enviar
quanto para receber mensagens (comunicação
bidirecional)
Um processo pode usar múltiplas portas, mas não pode
compartilhar portas com outros processos do mesmo
computador (exceto no caso de sockets associados a
endereços de difusão seletiva)
Comunicação usando sockets (III)
Comunicação usando sockets - UDP (I)
 Transmissão não confiável de “pacotes” (datagramas)

entre um processo cliente e um processo servidor
Não garante entrega, nem ordem de recebimento das
mensagens
Exige que clientes e servidores criem um socket
acoplado ao IP e a uma porta da máquina local
 O servidor escolhe uma porta específica (conhecida
pelos clientes)
 O cliente utiliza uma porta qualquer dentre as portas
disponíveis
Comunicação usando sockets - UDP (II)
 Comunicação sem conexão prévia

No cliente: endereço e porta do servidor passados como
parâmetros de entrada para cada operação send
No servidor: endereço e porta do cliente recebidos como
parâmetros de saída de cada operação receive
Comunicação usando sockets - UDP (III)
 Operações bloqueantes e não-bloqueantes

send retorna logo após repassar a mensagem para os
protocolos subjacentes (UDP/IP)
 A mensagem é descartada na chegada se não há um
socket acoplado ao endereço e à porta de destino
receive bloqueia processo se não houver mensagens na fila
 Variação não-bloqueante disponível em algumas
implementações
 Bloqueio pode ser controlado através de temporizadores
(timeouts)
 Pode receber mensagens de diferentes endereços de
origem
Comunicação usando sockets - UDP (IV)
 Modelo de falha
Checksums para detectar e rejeitar mensagens
corrompidas
Garantia de entrega e ordem de chegada fica a cargo
da aplicação
É preciso implementar tais funcionalidades
Reliable UDP
Comunicação usando sockets - UDP (V)
 Uso de UDP
Em algumas aplicações, pode ser aceitável utilizar um
serviço sujeito a falhas de omissão ocasionais (ex.: DNS,
VoIP)
Uso de UDP evita custos normalmente associados com
a garantia de entrega das mensagens:
 Necessidade de armazenar informações de estado na
origem e no destino
 Transmissão de mensagens extras (além dos dados
da aplicação)
 Latência no envio
Exemplos de uso em Java e C/Unix
 Em Java:
API implementada em algumas classes do pacote java.net
 DatagramPacket
 DatagramSocket
 Socket
 ServerSocket
 Em C/Unix:
API padrão (biblioteca de funções) para manipulação de
sockets
Definições básicas no arquivo de cabeçalho socket.h
API de Java com sockets sobre UDP
 Principais Classes
DatagramPacket
Usada pelo cliente para construir um datagram a partir de
um array de bytes e do endereço+porta de um servidor
Usada pelo servidor para armazenar o datagram recebido
juntamente com o endereço+porta do socket cliente
DatagramSocket
Usada para criar sockets para enviar e receber datagramas
Construtores com ou sem a opção de especificar a porta
desejada (se a porta não for especificada, o sistema escolhe
uma porta disponível)
Lança exceção SocketException se a porta especificada já
estiver em uso
Exemplo de uso no lado do cliente
import java.io.*;
import java.net.*;
class UDPClient {
public static void main(String args[]){
DatagramSocket clientSocket = null;
String msg = args[0];
String ipDoServidor = args[1];
int port = 6789;
try {
clientSocket = new DatagramSocket();
byte[] sendArray = msg.getBytes();
InetAddress IpServidor =InetAddress.getByName(ipDoServidor);
DatagramPacket sendPacket = new DatagramPacket(sendArray, sendArray.length,
IpServidor, port);
clientSocket.send(sendPacket);
byte[] receiveArray = new byte[1000];
DatagramPacket receivePacket = new DatagramPacket(receiveArray, receiveArray.length)
clientSocket.receive(receivePacket);
String resposta = new String(receivePacket.getData(), 0, receivePacket.getLength());
System.out.println("Resposta do servidor: " + resposta);
} catch (Exception e) {
e.printStackTrace();
} finally {
if (clientSocket != null) clientSocket.close();
} Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
} © Pearson Education 2005
Exemplo de uso no lado do servidor
importimport java.io.IOException;
import java.net.*;
class UDPServer {
public static void main(String args[]) throws Exception {
DatagramSocket serverSocket = null;
try {
serverSocket = new DatagramSocket(6789);
System.out.println("Servidor em execução!");
byte[] receiveData = new byte[1024];
while (true) {
DatagramPacket request = new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(request);
String msg = new String(request.getData(), 0, request.getLength());
InetAddress ip = request.getAddress();
int port = request.getPort();
String respota = msg.toUpperCase(); // Este é o SERVIÇO prestado pelo servidor
byte[] replyData = respota.getBytes();
DatagramPacket reply = new DatagramPacket(replyData, replyData.length, ip, port);
serverSocket.send(reply);
}
} catch (Exception e) {
e.printStackTrace();
} finally {
if (serverSocket != null) serverSocket.close();
Comunicação usando sockets - TCP (I)
 Transmissão confiável de mensagens entre um processo cliente e um

processo servidor
 Cliente solicita a conexão de um socket acoplado a uma porta local qualquer
para o endereço e a porta do socket no servidor
 Servidor aceita conexões entre seu socket local e os sockets dos clientes
 Conexão feita através de um par de “fluxos” (streams)
 Um fluxo de saída no cliente é conectado a um fluxo de entrada no
servidor, e vice-versa
 Permite a comunicação bi-lateral e concorrente entre clientes e
servidores
Comunicação usando sockets - TCP (II)
 Noção de fluxos de dados abstrai das seguintes

características da rede:
 A aplicação pode escolher a quantidade de dados que vai ler ou
escrever em um fluxo; cabe à implementação do TCP o quanto
desses dados serão transmitidos em cada pacote IP
 Um esquema de confirmações e temporizadores permite a
detecção e retransmissão de mensagens extraviadas
 Um esquema de controle de fluxo permite sincronizar a velocidade
de envio na origem com a velocidade de recebimento no destino
 Se o remetente estiver enviando dados muito rapidamente, ele é bloqueado até
que o destinatário tenha recebido uma quantidade de dados suficiente
 Identificadores de mensagens são associados a cada pacote IP, o
que permite ao destinatário detectar e rejeitar mensagens
duplicadas, ou reordenar eventuais mensagens recebidas fora de
ordem
Comunicação usando sockets - TCP (III)
 Protocolos de interação
 Clientes e servidores devem concordar sobre uma seqüência para
a troca de mensagens e sobre como interpretar seu conteúdo
 Falta de entendimento pode causar erros de interpretação (ex.:
receber um inteiro esperando uma string) e bloqueios indevidos
(ex.: tentativa de receber mais dados do que os que foram de fato
enviados)
 Operações bloqueantes
 send - bloqueia o processo até que haja espaço disponível na fila
correspondente ao stream de entrada do socket de destino
 receive - bloqueia o processo até que haja uma mensagem
disponível na fila correspondente ao stream de entrada do socket
local
Comunicação usando sockets - TCP (IV)
 Modelo de falha
 Checksums para detectar e rejeitar mensagens corrompidas
 Números seqüenciais para detectar e rejeitar mensagens
duplicadas
 Temporizadores e retransmissões para lidar com perdas de
pacotes
 Uso de TCP
 Muitas aplicações da Internet rodam sobre conexões TCP, em portas
reservadas, incluindo:
 HTTP (porta 80)
 FTP (porta 20/21)
 Telnet (porta 23)
 SMTP (porta 25)
API de Java com sockets sobre TCP
 Socket
 Usada pelo cliente para criar um socket (acoplado a uma porta
local qualquer) para ser conectado ao socket de um servidor
remoto
 Lança exceção UnkownHostException se houver problemas com o
endereço do servidor, ou IOException, se houver erros de E/S
 Métodos getInputStream e getOutputStream permitem acesso ao
stream de entrada e ao stream de saída, respectivamente,
associados ao socket
 ServerSocket
 Usada pelo servidor para criar um socket (acoplado a uma
determinada porta local) para aceitar conexões dos clientes
 Método accept devolve um objeto da classe Socket, já conectado ao
socket de um cliente que tenha solicitado conexão, ou bloqueia o
servidor até que um novo pedido de conexão seja recebido
Exemplo de uso no lado do cliente
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
Socket s = null;
try{
int serverPort = 7896;
s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream(s.getInputStream());
DataOutputStream out = new DataOutputStream(s.getOutputStream());
out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3
String data = in.readUTF();
System.out.println("Received: "+ data);
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException e){
System.out.println("EOF:"+e.getMessage());
}catch (IOException e){
System.out.println("IO:"+e.getMessage());
}finally {
if(s!=null){ try {s.close();} catch (IOException e){
System.out.println("close:"+e.getMessage());}
}
Exemplo no lado do servidor
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
in = new DataInputStream( clientSocket.getInputStream());
out = new DataOutputStream( clientSocket.getOutputStream());
}catch(IOException e) {
System.out.println("Listen :"+e.getMessage());
}
}
// this figure continues on the next slide
Exemplo no lado do servidor (cont.)
class Connection extends Thread {

DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {

try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out = new DataOutputStream( clientSocket.getOutputStream());
this.start();
}catch(IOException e){System.out.println("Connection:"+e.getMessage());}
}
public void run(){
try { // an echo server
String data = in.readUTF();
out.writeUTF(data);
}catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
}catch(IOException e) {System.out.println("IO:"+e.getMessage());}
}finally{ try {clientSocket.close();}
catch (IOException e){/*close failed*/}}
}
Agenda

Representação externa de dados
 Motivação:
 Programas e rede manipulam dados em diferentes níveis de abstração
(abstrações de dados X seqüência de bytes)
 Abstrações de dados devem ser “achatadas” (ou “serializadas”) pelo
remetente, antes da transmissão, e então reconstruídas pelo
destinatário, após o seu recebimento
 Nem todos os programas utilizam a mesma forma de representação para
os mesmos tipos de dados
 Diferentes conjuntos de tipos primitivos
 Diferentes tamanhos (em bytes) para os mesmos tipos
 Diferentes ordem de bits para tipos do mesmo tamanho
 Diferentes arquiteturas para números de ponto flutuante
 Diferentes padrões de caracteres (UTF-8, ASCII, Unicode, ...)
 Como fazer para que programas em diferentes computadores
troquem dados de forma consistente?
Representação externa de dados
 Duas abordagens:
 1. Remetente envia os dados no seu formato original (local), junto com
uma indicação do formato utilizado, e destinatário os converte novamente
para o seu formato local, se necessário
 A favor: evita conversões desnecessárias
 Contra: destinatário precisa conhecer todos os outros formatos
 2. Remetente converte os dados para um formato externo (acordado
previamente) antes da transmissão, e destinatário os converte novamente do
formato externo para o seu formato local
 A favor: remetente e destinatário só precisam conhecer um
único formato externo
 Contra: conversões desnecessárias quando os
computadores envolvidos utilizam o mesmo formato (como
otimizar?)
 Exemplos práticos: (CORBA, RMI, SOAP(XML), ProtocolBuffers)
Empacotamento e Desempacotamento (I)
 Empacotamento (marshalling):
 Agrupamento de um conjunto de itens de dados num formato
adequado (representação externa) para transmissão via mensagens
 Desempacotamento (unmarshalling):
 Re-agrupamento dos dados recebidos no formato externo para
produzir um conjunto equivalente de itens de dados no formato local
do destinatário
 Realizados automaticamente pelas camadas do
middleware, sem intervenção do usuário ou programador
 Necessitam da especificação detalhada dos tipos de dados a
serem transmitidos em uma linguagem apropriada (IDL, WSDL, etc)
 Evitam erros de programação
 Podem ser usados para outros fins (ex.: persistência)
Empacotamento/Desempacotamento (II)
 Três abordagens discutidas no curso:

 CDR (CORBA)
 Representação de dados externos em formato binário, utilizada na
invocação de objetos remotos com CORBA
 Suporte para múltiplas linguagens de programação
 Serialização de objetos (Java RMI)
 Representação de dados externos em formato binário, utilizada, entre
inúmeros outros usos, na invocação de objetos remotos com Java RMI
 Apenas para uso com Java
 XML (SOAP)
 Representação de dados externos em formato textual (documentos
XML), utilizada na invocação de serviços web
 Suporte pra múltiplas linguagens de programação
 Representações textuais geralmente são bem maiores do que
representações binárias equivalentes (Vantagens?Desvantagens?)
Representação de dados - CORBA
 Representação comum de dados (Common Data Representation –

CDR) introduzida na versão CORBA 2.0
 Definição de formato para todos os tipos de dados que podem ser
usados como argumentos e valores de retorno em invocações
remotas para objetos CORBA
 15 tipos primitivos: short (16 bits), long (32 bits), double (64 bits), boolean,
char(16 bits), float(32bits), dentre outros.
 6 tipos compostos: sequence, string, array, struct, enumerated, union
 Ordem dos bits (little-endian ou big-endian) segue o estilo local do
remetente e é indicada em cada mensagem (conversão a critério do
destinatário)
 Valores primitivos dos tipos compostos adicionados em seqüência,
seguindo uma ordem específica para cada tipo
Representação de dados - CORBA
Exemplo de representação em CDR
 Definição do dado Pessoa na IDL (Interface Definition

Language) do CORBA:
 struct Pessoa { string nome; string lugar; unsigned long ano};
 Representação em CORBA CDR de um item de dado do
tipo
 Pessoa com os atributos {‘Smith’, ‘London’, 1934}:
Serialização de objetos em Java
 Serialização: atividade de “achatar” o estado de um objeto (ou de

uma hierarquia de objetos relacionados) para uma forma seqüencial
mais adequada para armazenamento ou transmissão
 Valores dos atributos primitivos escritos num formato binário portável
 Atributos não primitivos serializados recursivamente
 Não pressupõe conhecimento sobre o tipo dos objetos para o processo de
reconstrução (“desachatamento”)
 Informações sobre a classe dos objetos, como nome e número de
versão, são incluídas na forma serial
 Implementada através dos métodos writeObject e readObject das classes
ObjectOutputStream e ObjectInputStream, respectivamente
 Transforma tipos primitivos em formato binário
 String e caracteres são gravados pelo método writeUTF
 Executada de forma transparente pelas camadas da middleware em
Java (uso intensivo de Reflexão!)
Exemplo de Serialização em Java
 Definição de um tipo Pessoa em Java:
 Exemplo (simplificado) de serialização de um objeto do tipo
Reflexão
 De posse de um objeto do tipo Class podemos chamar os seguintes

métodos para obter mais informações sobre a classe (a lista a seguir
é apenas um pequeno subconjunto dos métodos da classe Class):
 String getName() - retorna o nome da classe
 Object newInstance() - retorna um novo objeto que é instância da
classe
 Method[] getMethods() - retorna uma lista de objetos da classe
Method, representando os métodos da classe
 Field[] getFields() - retorna uma lista de objetos da classe Field,
representando os campos da classe
 Method getMethod (nome, tipos dos parâmetros) - retorna o método
que tem o nome e parâmetros dados, se existir.
Reflexão
Representação de dados externos XML
 XML é uma linguagem de marcação de propósito geral para uso na

Web, definida e mantida pelo W3C
 Projetada para facilitar a codificação textual de documentos estruturados
 Itens de dados em XML são “marcados” com strings especiais

chamadas marcadores (tags), que representam a estrutura lógica
dos dados
 Diferença para HTML?
 XML é extensível!
 Usuários podem definir seus próprios marcadores
 Extensões precisam ser acordadas no caso de documentos
compartilhados por múltiplas aplicações
 XML é a base para a representação de dados externos (padrão SOAP) e

interfaces (padrão WSDL) nos middlewares baseados na tecnologia de
serviços web (web services)
 Vantagens:
 Permite “compreensão” e facilita monitoramento por humanos (útil em atividades
de teste e depuração)
 Independente de plataforma
 Desvantagens:
 Mensagens bem maiores que suas equivalentes em formato binário
 Maior tempo de processamento para empacotamento/desempacotamento
 Alternativas:
 Compactação de mensagens
 Reduz tamanho mas piora processamento
 XML em formato binário
 Reduz tamanho e processamento, mas impede compreensão
 Representação em XML de um elemento do tipo Pessoa:

<person id="123456789">
<name>Smith</name>
<place>London</place>
<year>1934</year>

</person >
 Espaço de nomes da estrutura Pessoa

<person pers:id="123456789" xmlns:pers = "http://www.cdk4.net/person">
<pers:name> Smith </pers:name>
<pers:place> London </pers:place >
<pers:year> 1934 </pers:year>
</person>
 Um esquema XML define:

 Os elementos e atributos (incluindo seus tipos e valores default)
que podem aparecer em um documento
 Como os elementos são aninhados e em qual ordem e quantidade
 Se um elemento pode ser vazio
 Se um elemento pode conter texto
 Um mesmo esquema pode ser compartilhado por
múltiplos documentos XML
Permite a validação de documentos de acordo com o esquema
 Ex.: uma mensagem SOAP pode ser validada pelo processo
destinatário com base no esquema XML previamente definido
para esse padrão
 XML Schema
 Exemplo de um esquema para o tipo Pessoa definido em XML Schema:
Agenda

Comunicação Cliente-Servidor
 Modelo geral: requisição-e-resposta

 Variantes:
 síncrona: cliente bloqueia até receber a resposta
 assíncrona: cliente recupera (explicitamente) a resposta em um instante
posterior
 não-bloqueante
 Implementação sobre protocolo baseado em datagramas é mais eficiente
 evita: reconhecimentos redundantes, mensagens de estabelecimento de
conexão, controle de fluxo
Protocolo requisição-e-resposta
Client Server
Request
doOperation
message getRequest
select object
(wait) execute
Reply method
message sendReply
(continuation)
Operações utilizadas para implementar o protocolo de requisição-e-resposta
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)

envia uma mensagem de requisição para o objeto remoto e retorna a resposta.
Os argumentos especificam o objeto remoto, o método a ser chamado e os argumentos
para aquele método.
public byte[] getRequest ();

obtém uma requisição de um cliente através de uma porta servidora.
public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);

envia a mensagem de resposta para o cliente, endereçando-a a seu endereço IP e porta.
Estrutura de mensagens de requisição-e-resposta
messageType int (0=Request, 1= Reply)

requestId int
objectReference RemoteObjectRef
methodId Int
arguments array of bytes
Identificador da mensagem
request ID + ID do processo que fez a requisição
Representação de Referências de Objetos
 Necessária quando objetos remotos são passados como parâmetro

 A referência é serializada (não o objeto)
 Contém toda informação necessária para identificar (e endereçar) um objeto
unicamente no sistema distribuído
32 bits 32 bits 32 bits 32 bits
interface of
Internet address port number time object number
remote object
Modelo de falhas
 Suposições
 processos: colapso (falham e permanecem parados)
 canais: podem omitir mensagens, mensagens não chegam em ordem
 Timeouts: em doOperation
 detectar que a resposta (ou a requisição) foi perdida
 alternativas de tratamento:
 sinalizar a falha para o cliente
 repetir o envio da requisição (um certo número de vezes)
 até ter certeza sobre a natureza da falha
 (quem falhou? O canal ou o processo?)
Modelo de falhas (2)
 Descarte de mensagens duplicadas

 o servidor deve distinguir requisições novas de requisições retransmitidas
 apropriado re-executar a requisição?
 Em caso de perda da resposta
 servidor re-executa a requisição para gerar novamente a resposta?
 servidor mantém um histórico das respostas geradas para o caso de precisar
retransmitir?
 o histórico precisa conter apenas a última resposta
enviada para cada cliente. Por que? Suficiente?
Protocolos de troca de mensagens em RPC
Nome Mensagens enviadas pelo

Cliente Servidor Cliente
R Request
RR Request Reply
RRA Request Reply Acknowledge reply
 Tipo de garantia (confiabilidade) em cada caso?
Protocolo de transporte utilizado: TCP
 não impõem limites no tamanho das mensagens

 na verdade, cuida da segmentação de forma transparente
 permite argumentos de tamanho arbitrário (ex.: listas)
 transferência confiável
 lida com mensagens perdidas e duplicadas
 Elimina necessidade de retransmissões e histórico
 controle de fluxo
 overhead reduzido em sessões longas (muitas requisições e respostas
sucessivas)
Protocolo de transporte utilizado: UDP
 se mensagens têm tamanho fixo

 se sessões são curtas (apenas uma requisição e sua resposta)
 não compensa o overhead do handshake TCP
 se operações são idemponentes
 mensagens duplicadas (retransmissões) podem ser re-processadas sem
problema
 otimização do protocolo de confiabilidade para casos específicos
HTTP como protocolo de requisição-e-resposta
 Tipo RR
 Regras para o formato de mensagens
 Marshalling (empacotamento)
 Conjunto fixo de métodos: PUT, GET, POST,...
 Apaicáveis a todos os seus recursos
 Permite negociar o tipo do conteúdo (MIME)
 Conexões persistentes para amortizar o custo de abrir e fechar conexões
TCP
Mensagem HTTP request
 Dois tipos de mensagens HTTP: request, response

 HTTP request message:
 ASCII (formato legível para humanos)
Linha de requisição
(comandos GET, POST, GET /somedir/page.html HTTP/1.0
HEAD ) Host: www.someschool.edu
Connection: close
Linhas de User-agent: Mozilla/4.0
cabeçalho Accept-language:fr
Carriage return, (extra carriage return, line feed)

line feed
indica fim da mensagem
Mensagem HTTP request: formato geral
Mensagem HTTP response
Linha de status
(protocolo
código de status HTTP/1.0 200 OK
frase de status) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Linhas de
cabeçalho Content-Length: 6821
Content-Type: text/html
data data data data data ...

Dados, ex.:
arquivo html
Códigos de status das respostas
Na primeira linha da mensagem de resposta servidor  cliente.

Alguns exemplos de códigos:
200 OK
 Requisição bem-sucedida, objeto requisitado a seguir nesta mensagem
301 Moved permanently
 Objeto requisitado foi movido, nova localização especificada a seguir nesta
mensagem (Location:)
400 Bad request
 Mensagem de requisição não compreendida pelo servidor
404 Not Found
 Documento requisitado não encontrado neste servidor
505 HTTP version not supported
GET condicional
Cliente Servidor
 Razão: não enviar objeto
se a versão que o cliente HTTP request msg
já possui está atualizada If-modified-since: Objeto
<date> não
 Cliente: especifica data da
versão armazenada no modificado
HTTP response
pedido HTTP HTTP/1.0
 If-modified-since: <date> 304 Not Modified
<date> = Last-Modified
 Servidor: resposta não HTTP request msg
contém objeto se a cópia é If-modified-since:
atualizada: <date> Objeto
HTTP/1.0 304 Not modificado
Modified HTTP response
HTTP/1.1 200 OK
<data>
Agenda

Comunicação de Grupo
 Entrega de uma mesma mensagem, enviada por um processo, para cada um

dos processos que são membros de um determinado grupo
 O conjunto de membros do grupo é transparente para o processo que envia
a mensagem
 processo envia a mensagem para o grupo (não para seus membros
diretamente)
 Mensagens comunicadas através de operações de multicast
Aplicações da comunicação de grupo
 Tolerância a falhas baseada em serviços replicados

 Busca por serviços de descoberta em redes espontâneas
 Melhoria de desempenho através de dados replicados
 Propagação de eventos
 Trabalho cooperativo
 etc
IP Multicast
 Protocolo básico para comunicação de grupo

 Assim como o IP (unicast): não-confiável
 mensagens podem ser perdidas (falha de omissão)
 i.e., não entregues para alguns membros do grupo
 mensagens podem ser entregues fora de ordem
 Acessível às aplicações através de UDP
 Grupos são identificados por: end. IP + porta
 utiliza endereços IP que iniciam por 1110 (IPv4-Classe D)
 Processos se tornam membros de grupos, mas não conhecem os demais
membros nem a quantidade deles.
IP Multicast (cont.)
 Um computador é membro de um grupo se ele possui um ou mais

processos com sockets que se juntaram ao grupo: multicast sockets
 Camada de rede:
 recebe mensagens endereçadas a um grupo, se computador é membro
 entrega as mensagens para cada um dos sockets locais que participa do
grupo
 processos membros são identificados pelo número de porta associado ao
grupo
 vários processos compartilham o mesmo núm. de
porta
API Java para IP Multicast
 Classe MulticastSocket
 Derivada de DatagramSocket
 Principais métodos:
 joinGroup
 leaveGroup
 setTimeToLive
 Veja exemplo no próximo slide
Processo entra em um grupo de multicast e envia e recebe datagramas
import java.net.*;
import java.io.*;
public class MulticastPeer{
public static void main(String args[]){
// args give message contents & destination multicast group (e.g. "228.5.6.7")
MulticastSocket s =null;
try {
InetAddress group = InetAddress.getByName(args[1]);
s = new MulticastSocket(6789);
s.joinGroup(group);
byte [] m = args[0].getBytes();
DatagramPacket messageOut =
new DatagramPacket(m, m.length, group, 6789);
s.send(messageOut);
// this figure continued on the next slide

...continuação
// get messages from others in group

byte[] buffer = new byte[1000];
for(int i=0; i< 3; i++) {
DatagramPacket messageIn =
new DatagramPacket(buffer, buffer.length);
s.receive(messageIn);
System.out.println("Received:" + new String(messageIn.getData()));
}
s.leaveGroup(group);
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}finally {if(s != null) s.close();}
}
}
Confiabilidade e ordenação de multicast
 Fontes de falhas
 membros de um grupo podem perder mensagens devido a congestionamento
(fila de chegada cheia)
 falhas em roteadores de multicast
 roteador não propaga a mensagem para os membros
que estão após ele na rede
 Falhas de ordenação
 Mensagens enviadas por um processo podem ser recebidas por outros
processos em ordens diferentes
 Mensagens enviadas por diferentes processos podem não chegar na mesma
ordem em todos os demais processos
Efeitos de falhas nas principais aplicações de comunicação de grupo
 Serviços replicados
 causa inconsistência das réplicas: nem todas as réplicas terão processado
todas as requisições
 Busca por serviços de descoberta
 imune a falhas: basta que alguém responda
 Dados replicados
 depende do modelo de replicação
 Propagação de eventos
 dependente de aplicação
Conclusão sobre IP Multicast
 Protocolo de multicast não-confiável

 Uso sobre redes locais: utiliza multicast físico
 ex.: em redes Ethernet
 Uso na Internet: utiliza roteadores de multicast
 configurados através de algum protocolo de roteamento multicast
 time-to-live para limitar a propagação de msgs
 Se confiabilidade é importante: protocolos de multicast confiável (capítulo
12)
 ordenação total, ordenação causal

Não É Possível Estabelecer Um Limite Do Tempo Que Se Leva para Que Tal Servidor Envie A Resposta Ao Cliente

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Não É Possível Estabelecer Um Limite Do Tempo Que Se Leva para Que Tal Servidor Envie A Resposta Ao Cliente

Transféré par

Droits d'auteur :

Formats disponibles

Slides for Chapter 4:

Comunicação entre processos

From Coulouris, Dollimore and Kindberg

 API para comunicação entre processos

 Interface de programação para utilizar os serviços

 Duas operações básicas: send e receive

 Comunicação síncrona é a mais usada na prática!

 Operações bloqueantes podem ser utilizadas sem

 Destino = (endereço de rede + porta)

 Destinos transparentes quanto à localização podem ser

 API de Java para resolução de nomes de domínio

Socket: uma porta entre o processo de aplicação e o

 Socket: abstração para cada um dos extremos

 Comunicação exige a criação de um socket pelo processo

 Transmissão não confiável de “pacotes” (datagramas)

 Comunicação sem conexão prévia

 Operações bloqueantes e não-bloqueantes

 Transmissão confiável de mensagens entre um processo cliente e um

 Noção de fluxos de dados abstrai das seguintes

// this figure continues on the next slide

class Connection extends Thread {

public Connection (Socket aClientSocket) {

 API para comunicação entre processos

 Três abordagens discutidas no curso:

 Representação comum de dados (Common Data Representation –

 Definição do dado Pessoa na IDL (Interface Definition

 Serialização: atividade de “achatar” o estado de um objeto (ou de

 Definição de um tipo Pessoa em Java:

 Exemplo (simplificado) de serialização de um objeto do tipo

 De posse de um objeto do tipo Class podemos chamar os seguintes

 XML é uma linguagem de marcação de propósito geral para uso na

 Itens de dados em XML são “marcados” com strings especiais

 XML é a base para a representação de dados externos (padrão SOAP) e

 Representação em XML de um elemento do tipo Pessoa:

 Espaço de nomes da estrutura Pessoa

 Um esquema XML define:

 API para comunicação entre processos

 Modelo geral: requisição-e-resposta

public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)

public byte[] getRequest ();

public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);

messageType int (0=Request, 1= Reply)

 Necessária quando objetos remotos são passados como parâmetro

32 bits 32 bits 32 bits 32 bits

 Descarte de mensagens duplicadas

Nome Mensagens enviadas pelo

RRA Request Reply Acknowledge reply

 Tipo de garantia (confiabilidade) em cada caso?

 não impõem limites no tamanho das mensagens

 se mensagens têm tamanho fixo

 Dois tipos de mensagens HTTP: request, response

Carriage return, (extra carriage return, line feed)

data data data data data ...

Na primeira linha da mensagem de resposta servidor  cliente.

 API para comunicação entre processos

 Entrega de uma mesma mensagem, enviada por um processo, para cada um

 Tolerância a falhas baseada em serviços replicados

 Protocolo básico para comunicação de grupo

 Um computador é membro de um grupo se ele possui um ou mais

// this figure continued on the next slide

// get messages from others in group

 Protocolo de multicast não-confiável

Vous aimerez peut-être aussi