Distributed Systems Principles and Paradigms Maarten van Steen VU Amsterdam, Dept. Computer Science (Tradução e Adaptação Ricardo Anido - IC/Unicamp) Capítulo 04: Comunicação Versão: 20 de março de 2014
2 / 16 Conteúdo Capítulo 01: Introdução 02: Arquiteturas 03: Processos 04: Comunicação 05: Nomeação 06: Sincronização 07: Consistência & Replicação 08: Tolerância a Falhas 09: Securança 10: Distribuição de Sistemas Baseados em Objetos 11: Sistemas de Arquivos Distribuídos 12: Sistemas Distribuídos Baseados na Web 13: Sistemas Distribuídos Baseados em Coordenação
3 / 16 Comunicação Protocolos em Camadas Camadas de baixo nível Camada de Transporte Camada de Aplicação Camada de Middleware
Comunicação 4 / 16 Modelo Básico de Rede Application Presentation Session Transport Network Data link Physical Application protocol Presentation protocol Session protocol Transport protocol Network protocol Data link protocol Physical protocol 7 6 5 4 3 2 1 Network Deficiências Foco apenas em passagem de mensagem Não raramente funcionalizades não necessárias ou não desejadas Viola transparência de acesso
5 / 16 Comunicação Camadas de baixo nível Recap Camada Física: contém a especificação e implementação de bits, e sua transmissão entre remetentes e destinatários Camada de enlace de dados: divide transmissão em pedaços, e fornece recuperação de erros e controle de fluxo. Camada de Rede: descreve como os pedaços de dados são roteados pela rede. Observação Para muitos sistemas distribuídos, a interface de mais baixo nível é a camada de rede.
6 / 16 Camada de Transporte Comunicação Importante A camada de transporte provê as facilidades de comunicação para sistemas distribuídos. Protocolos padrões da Internet TCP: orientada a conexão, confiável, orientada a streams (fluxo de bits) UDP: não confiável (melhor esforço), datagrama
7 / 16 Comunicação Camada de Middleware Observação Camada de middleware foi inventada para prover serviços e protocolos comuns que podem ser usadas por aplicações diferentes. Um rico conjunto de protocolos de comunicação (Un)marshaling de dados Protocolos de nomeação, para permitir compartilhamento de serviços Protocolos de Segurança, para comunicação segura Mecanismos para escalar aplicações, como replicação e cache
8 / 16 Tipos de comunicação Comunicação Client Request Synchronize at request submission Synchronize at request delivery Transmission interrupt Storage facility Synchronize after processing by server Reply Server Time Distinguir Comunicação Transiente versus persistente Comunicação Assíncrona versus síncrona
Comunicação Tipos de comunicação Client Synchronize at request submission Synchronize at request delivery Synchronize after processing by server Request Transmission interrupt Storage facility Reply Server Time Transiente versus persistente Comunicação Transiente: Servidor descarta mensagem quando não pode ser entregue (próximo servidor ou destino) Comunicação Persistente: Uma mensagem é armazenada por tanto tempo quanto necessário para entrega. 9 / 16
Comunicação 10 / 16 Tipos de comunicação Client Synchronize at request submission Synchronize at request delivery Synchronize after processing by server Request Transmission interrupt Storage facility Reply Server Time Locais de sincronização Na submissão de requisições Na entrega da requisição Após o processamento da requisição
Comunicação 11 / 16 Cliente/Servidor Observações Modelo Cliente/Servidor é geralmente baseado em comunicação transiente assíncrona: Cliente e servidor devem estar ativos ao mesmo tempo Cliente envia requisição e bloqueia até receber resposta Servidor essencialmente espera por requisições Deficiências de comunicação síncrona Cliente não pode fazer qualquer outro trabalho enquando espera O modelo pode não ser apropriado (mail, news)
Comunicação 11 / 16 Cliente/Servidor Observações Modelo Cliente/Servidor é geralmente baseado em comunicação transiente assíncrona: Cliente e servidor devem estar ativos ao mesmo tempo Cliente envia requisição e bloqueia até receber resposta Servidor essencialmente espera por requisições Deficiências de comunicação síncrona Cliente não pode fazer qualquer outro trabalho enquando espera O modelo pode não ser apropriado (mail, news)
Comunicação 12 / 16 Mensagens Middleware orientado a mensagens Provê comunicação persistente,assíncrona: Processos enviam mensgens entre si, que são enfileiradas Remetente não precisa esperar por resposta imediata, pode fazer outras tarefas Middleware geralmente garante algum tipo de tolerância a falhas
13 / 16 Comunicação Remote Procedure Call (RPC) 4.2 Remote Procedure Call Operação básica RPC Passagem de Parâmetros Variações
Comunicação 4.2 Remote Procedure Call RPC - operação básica Observação Modelo familiar a desenvolvedores Bem projetadas, podem operar com isolamento (black box) Não existe razão fundamental para não executar procedimentos em máquinas separadas Conclusão Comunicação entre chamador & chamado pode ser escondido usando esse mecanismo Client Server Call remote procedure Request Wait for result Reply Call local procedure and return results Return from call Time 14 / 16
RPC - operação básica Client machine Comunicação 4.2 Remote Procedure Call Server machine Client process k = add(i,j) proc: "add" int: val(i) int: val(j) 1. Client call to procedure Server stub Client stub 2. Stub builds message Server process Implementation of add k = add(i,j) proc: "add" int: val(i) int: val(j) 6. Stub makes local call to "add" 5. Stub unpacks message Client OS proc: "add" int: val(i) int: val(j) Server OS 4. Server OS hands message to server stub 3. Message is sent across the network 1 Procedimento cliente chama um stub 2 Stub empacota parâmetros, constrói mensagem, chama OS local 3 OS envia mensagem para OS servidor. 4 OS remoto entrega mensagem para stub. 5 Stub desempacota parâmetros e chama servidor 6 Servidor retorna resultado para stub 7 Stub empacota resultado, monta mensagem; calls OS. 8 OS servidor envia mensagem para OS cliente 9 OS entrega mensagem para stub 10 Stub cliente desepacota mensagem e entrega resultado para cliente 15 / 16
Comunicação 4.2 Remote Procedure Call 16 / 16 RPC: Passagem de parâmetros Tratamento (marshaling) de parâmetros Mais do que apenas montar mensagem: Cliente e servidor podem usar diferentes representação de dados (byte ordering) Empacotar um parâmetro significa transformar em uma sequência de byte Cliente e servidor devem concordar sobre a codificação: Como valores de dados básicos são representados (integers, floats, characters) Como dados complexos são representados (arrays, unions) Cliente e servidor devem interpretar corretamente as mensagens, transformando-as para representação independente de máquina.