Arquiteturas de Sistemas Distribuídos: Modelos de Comunicação Alcides Calsavara

Referência Básica [C] Distributed Systems: Concepts and Design. G. Coulouris, J. Dollimore, T. Kindberg. Addison-Wesley, 1994. ISBN 0-201-62433-8. (Capítulos 4 e 5) [T] Distributed Operating Systems. A. S. Tanenbaum. Prentice-Hall, 1995. ISBN 0-13-219908-4. (Seções 2.4 e 2.5)

Conteúdo Elementos básicos de comunicação Comunicação cliente-servidor Transmissão de dados Endereçamento Sincronismo Enfileiramento (Bufferização) Confiabilidade Comunicação cliente-servidor Comunicação em grupo Chamada remota de procedimento

Comunicação cliente-servidor

Transmissão de dados Dados em programas são estruturados enquanto que mensagens carregam informação sequencial: » Linearização/Restauração de dados Heterogeneidade na representação de dados em computadores: » Uso de um formato externo comum » Inclusão de uma identificação de arquitetura na mensagem

Marshalling/Unmarshalling Linearização de uma coleção de itens de dados estruturados Tradução dos dados em formato externo Unmarshalling: Tradução do formato externo para o local Restauração dos itens de dados de acordo com sua estrutura

Endereçamento Esquemas: Endereçamento máquina.processo Endereçamento máquina.id-local Descoberta de endereço via broadcasting (difusão) Descoberta de endereço via um servidor de nomes Problemas potenciais: transparência de localização, sobrecarga, escalabilidade

Comunicação síncrona Primitiva send é bloqueante: processo cliente aguarda enquanto o núcleo envia a mensagem para o processo servidor. Primitiva receive é bloqueante: processo servidor aguarda até que o núcleo receba uma mensagem endereçada para aquele processo.

Comunicação assíncrona Primitiva send não é bloqueante: o processo cliente aguarda somente enquanto a mensagem é copiada para o buffer do núcleo. Primitiva receive pode ser: bloqueante: o processo servidor aguarda por uma mensagem. não bloqueante: o processo servidor simplesmente comunica o núcleo que espera receber uma mensagem.

Enfileiramento Situações: Send ocorre antes de Receive Um cliente faz um Send enquanto o servidor ainda atende a outro cliente Solução trivial: clientes devem insistir ... Solução pragmática: mailbox (uma fila de mensagens controlada pelo núcleo): mailbox criado a pedido do servidor mensagens endereçadas ao mailbox

Confiabilidade Mensagens se perdem, atrasam, duplicam. Abordagens: Send tem semântica não confiável: as aplicações devem garantir entrega de mensagens (ex: timeout) Mensagem de acknowledgement enviada pelo servidor (no nível núcleo) Mensagem de acknowledgement implícita na resposta do servidor

Pacotes em protocolo C-S

Comunicação em grupo Tolerância a falhas baseada na replicação de serviços Localização de objetos em serviços distribuídos Melhor desempenho via replicação de dados Múltipla atualização

Tipos de grupos Visibilidade: Organização: Aberto: um processo fora do grupo consegue enviar mensagens para o grupo todo Fechado: somente processos do grupo enviam mensagens para o grupo todo Organização: Peer: todos os processos tomam decisão Hierárquico: decisão é centralizada

Endereçamento de grupo Multicast: um processo envia uma mensagem simultânea e somente para os membros do grupo. Broadcast: um processo envia uma mensagem para todas as máquinas e somente as que contêm um membro do grupo a assimila. Unicast: um processo envia uma mensagem para todos os membros do grupo em série.

Modificações no grupo Controle centralizado: servidor de grupo Controle descentralizado: acordo entre os membros Operações: Entrada de um membro: atualizar estado Saída de um membro: se involuntária (ex: parada), todos os membros restantes devem notar sua saída.

Primitivas de comunicação GroupSend: envia mensagem para todos os membros do grupo GroupReceive: aguarda mensagem enviada a todo o grupo GetReply: aguarda resposta de todos os membros do grupo após um GroupSend

Atomicidade Uma mensagem enviada ao grupo deve ser recebida por todos os seus membros ou por nenhum deles. Situação: o enviador pode parar enquanto está enviando a mensagem para o grupo. Garantia de consistência do grupo Facilidade de programação

Ordenação de mensagens Todas as mensagens enviadas a um grupo devem chegar a todos os processos na mesma ordem. Abordagens: Ordenação por tempo global Ordenação por tempo consistente: somente uma mensagem por vez é difundida

Chamada de Procedimentos Remotos (RPC) Comunicação baseada em operações de entrada/saída: abstração fraca, sujeito a erros Ideal: programar um sistema distribuído como se fosse centralizado RPC objetiva permitir chamada de procedimento remoto como se fosse local, ocultando entrada/saída de mensagens

Visão geral Um processo A chama um procedimento p de um processo B, entrando em estado de espera O processo B passa a executar o procedimento p, e ao seu término faz um reply para o processo A O processo A volta à sua execução normal após ter recebido o reply

Chamadas de procedimento O procedimento chamador, que já tem suas variáveis locais empilhadas, empilha os parâmetros da chamada e o endereço de retorno O procedimento chamado aloca suas variáveis locais No retorno do procedimento chamado, os parâmetros e o endereço de retorno são desempilhados

Modos de parâmetros Valor: procedimento chamado recebe uma cópia de uma variável conhecida do procedimento chamador Referência: procedimento chamado recebe o endereço de uma variável conhecida do procedimento chamador Cópia/Reescrita: procedimento chamador recebe uma cópia de uma variável conhecida do procedimento chamador e o valor desta cópia é reescrito na variável

Funções dos Stubs Client stub intercepta a chamada empacota os parâmetros (marshalling) envia mensagem de request ao servidor (através do núcleo) Server stub recebe a mensagem de request (através do núcleo) desempacota os parâmetros (unmarshalling) chama o procedimento, passando os parâmetros empacota o resultado envia mensagem de reply ao cliente (através do núcleo) recebe a mensagem de reply (através do núcleo) desempacota o resultado passa o resultado para o cliente

Falhas em RPC O cliente não é capaz de localizar o servidor A mensagem de request do cliente para o servidor é perdida A mensagem de reply do servidor para o cliente é perdida O servidor pára após ter recebido a mensagem de request O cliente pára após ter enviado a mensagem de request

Falha do servidor Passos normais: recebe mensagem de request executa procedimento envia mensagem de reply Falha pode ocorrer: após a execução antes da execução Semânticas de chamada: pelo menos um no máximo um exatamente um

Falha do cliente O servidor torna-se um “órfão” Soluções: exterminação do servidor pela máquina do cliente reencarnação do cliente: toda computação remota é destruída "reencarnação" suave do cliente: somentes as computações remotas referentes a aquele cliente são destruídas expiração: servidor estabele um timeout para confirmação