Sistemas Distribuídos Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação

Modelos de comunicação em Sistemas Distribuídos

Conteúdo Elementos básicos de comunicação 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: » Serialização (Conversão) / Deserializaçã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 Marshalling: Transformação de uma coleção de itens de dados estruturados de forma a serem armazenados ou transmitidos 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 original Também chamado de serialização Também chamado de deserialização

Associação entre um nome e um objeto Identificar os objetos Localizar os objetos Partilhar os objetos Simplificar a interface com os utilizadores Simplificar a gestão do sistema 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

Nomes e Identificadores Nome: representação de um objeto, normalmente na forma de uma cadeia de caracteres Atribuído pelo utilizador Um objeto pode ser designado por vários nomes Cada objeto tem que ter pelo menos um nome Identificador: nome sistema de um objeto, normalmente em formato binário Atribuído por uma autoridade Permite identificar e acessar o objeto Autoridade: gere o objeto, suporta a sua implementação

Exemplos de Identificadores e Autoridades

Hierarquia das Associações  A associação nome/objeto é lógica, sendo frequentemente entre nomes pertencentes a diferentes níveis de abstração:  Arquivo Unix : a/b/c  inode 1056  dispositivo - número do bloco disco;  Nó da rede Internet :  endereço IP  endereço Ethernet.

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

Chamada de Procedimentos Remotos (RPC) Chamada remota de procedimento (RPC, acrônimo de Remote Procedure Call) é uma tecnologia de comunicação entre processos que permite a um programa de computador chamar um procedimento em outro espaço de endereçamento (geralmente em outro computador, conectado por uma rede). O programador não se preocupa com detalhes de implementação dessa interação remota: do ponto de vista do código, a chamada se assemelha a chamadas de procedimentos locais. 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

Stubs Para permitir que os servidores sejam acessados por diferentes clientes, diversos sistemas padronizados de RPC foram criados. A maioria deles usa uma linguagem de descrição de interface (IDL) para que diferentes plataformas possam chamar procedimentos. Pode-se gerar interfaces entre cliente e servidor a partir de um arquivo IDL, os chamados stubs. Resumindo: São partes (fragmentos) de algoritmos que provêm a abstração de uma chamada (local) de procedimento (método) fazendo a ligação deste com o mecanismo de comunicação. O stub é parte do código que faz a chamada remota, é utilizado no cliente e no servidor.

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)

Funções dos Stubs 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)

Funções dos Stubs Client stub recebe a mensagem de reply (através do núcleo) desempacota o resultado passa o resultado para o cliente

Chamadas e mensagens em RPC Máquina do ClienteMáquina do Servidor Kernel clienteservidor empacota parâmetros desempacota resultados desempacota parâmetros empacota resultados transporte de mensagens via rede

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 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

Implementações CORBA — padrão RPC independente de plataforma Sun RPC — RPC para as plataformas Unix e Linux DCOM — RPC para Windows RMI — RPC para Java SOAP — padrão RPC para web service

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 consistência

Tipos de grupos Visibilidade: 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 emissor 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