sd04 (si) comunicação em sd

Sistemas DistribuídosSistemas Distribuídos

Parte 04Comunicação em SD

OBS: Partes deste material foi baseado em fontes obtidas no site da UNICAMP (mc704)

IntroduçãoIntrodução

• A maior diferença entre um sistema monoprocessado e um sistema distribuído é a comunicação entre processos– Em um sistema monoprocessado:

• Assume-se a existência de memória compartilhada, que é fundamental para o funcionamento de soluções para:

– Comunicação entre processos– Exclusão mútua e regiões críticas– Semáforos, variáveis compartilhadas, etc

– Em sistemas distribuídos:• A ausência de memória compartilhada (ou a impossibilidade de

garantir a disponibilidade deste recurso) obriga os componentes dos sistemas distribuídos a buscar outra solução para interagir

– Troca de mensagens– Implica em adotar protocolos de comunicação para permitir que

ambientes heterogêneos troquem mensagens

Protocolos de ComunicaçãoProtocolos de Comunicação– Protocolos são regras pré-estabelecidas para

comunicação entre duas ou mais partes• O uso de camadas facilita sua implementação e

entendimento, já que cada camada possui responsabilidades específicas

• Em 1983, a International Standards Organization (ISO) desenvolveu um modelo de referência que identifica claramente os vários níveis envolvidos e suas atribuições: o “Modelo OSI” (Open Systems Interconnection Reference Model)

– Voltado para comunicação entre sistemas abertos– Um sistema aberto é preparado para se comunicar com qualquer outro sistema

aberto através de regras que ditam o formato, conteúdo e significado das mensagens enviadas e recebidas.

Modelos de ProtocolosModelos de Protocolos

• Protocolos orientados à conexão– Neste modelo, o emissor e o receptor de uma

determinada mensagem devem estabelecer uma conexão antes que ocorra a troca de dados propriamente dita

• Existe possibilidade inclusive de negociação de aspectos do protocolo

• Protocolos sem conexão– Conforme o nome já indica, não há necessidade de que o

emissor e o receptor de uma determinada mensagem estejam conectados para a comunicação acontecer

O Modelo OSIO Modelo OSI• Características:

– Dividido em sete camadas de funcionalidade

• Cada camada trata de um aspecto da comunicação e provê uma interface (operações que definem os serviços da camada) às camadas adjacentes

– Cabeçalhos e finalizadores podem ser acrescentados e retirados às mensagens

Características Importantes na Comunicação SDCaracterísticas Importantes na Comunicação SD• Dependabilidade (qualidade do serviço oferecido

por um dado sistema)– Em geral, sistema é considerado confiável se há

garantia de entrega de mensagens apesar da perda de um número “razoável” de pacotes

– Reconhecimento de mensagens• Reconhecimento positivo (esta é a mensagem esperada)• Reconhecimento negativo (esta não pode ser a mensagem)

• Ordenação– Alguns sistemas dependem da ordem das mensagens– Fácil implementar para cliente-servidor ou p2p,

porém complexo em comunicação multicast

APIs de ComunicaçãoAPIs de Comunicação• APIs de comunicação permitem que as aplicações enviem e

recebam dados– Fornecem primitivas de comunicação que podem ser chamadas

a partir do código– Oferecem acesso aos serviços de comunicação, que podem

assim ser usados pelas aplicações– Exemplos de APIs de comunicação:

• Sockets: – Portas de comunicação locais ou de rede (Ex: SSL)

• Suportes de RPC (Remote Procedure Call):– Permitem chamar procedimentos/métodos remotamente (ex.: Java RMI, Sun

RPC, ...)• Canais de eventos:

– Permitem notificar threads e processos dos eventos ocorridos no sistema (Ex.: JMS, CORBA Notification Service, …)

API SocketAPI Socket• São abstrações que representam uma porta de

comunicação associada a uma aplicação– Origem: UNIX - depois portado para outros Sos– Identificados por um inteiro de 16 bits:

• Valores de 0 a 1024: serviços padronizados pela rede• Valores acima de 1024: livres para uso (desenvolvedores)

– Tipos de Socket• Sockets Datagrama:

– serviço sem conexão que usa protocolo UDP em mensagens 1 para 1• Sockets Multicast:

– envio para um grupo sem estabelecimento de conexão via UDP• Sockets Stream:

– serviço com conexão, baseado no paradigma cliente-servidor

Comunicação Cliente/ServidorComunicação Cliente/Servidor• Conceitos básicos:

– Servidor: oferece serviços– Cliente: consome serviços oferecidos– Em termos lógicos, para que dois processos se

comuniquem é preciso apenas a existência de duas operações primitivas:

– SEND (enviar) – acionada pelo rementente da mensagem– RECEIVE (receber) – acionada pelo destinatário

– 3 questões importantes:• Como o cliente localiza o serviço?• Como se processa o envio/entrega das mensagens?• Como lidar com o conceito de “garantia de entrega”?

Comunicação Cliente/Servidor (cont.)Comunicação Cliente/Servidor (cont.)

• Como o cliente localiza o servidor para solicitar um serviço?– Opção 1: O pedido é enviado para o endereço do servidor

acompanhado pelo endereço do processo/serviço• Desvantagem: endereço estático no código do cliente

Cliente Servidor

SO SORede Rede

Pedido para 123.1

Resposta para 123.2


• Como o cliente localiza o servidor para solicitar um serviço?– Opção 2: O pedido é enviado para todos

• Desvantagem: sobrecarga da rede

• Variação da opção 2: Antes do pedido ser enviado, é feito um broadcast para localizar o servidor (reduz sobrecarga)

Cliente Servidor

SO SORede Rede

Resposta para 0.0 (broadcast)

Pedido para 0.0 (broadcast)


• Como o cliente localiza o servidor para solicitar um serviço?– Opção 3: O cliente consulta um serviço de resolução de

nomes para localizar o servidor desejado• Desvantagem: exige um serviço adicional centralizado

Cliente

SORede

Servidor

SORede

Pedido de resolução de nomes

Resposta do endereço real

Servidor NS

SORede


• Comportamento das primitivas SEND e RECEIVE:– Na Comunicação Síncrona

– É a solução mais comum– Exige que a origem e o destino da mensagem estejam

sincronizadas a cada troca de mensagem, ou seja, as operações de SEND e RECEIVE causam bloqueios em suas respectivas execuções

– Ao ser emitido um SEND, o emissor é bloqueado até que um RECEIVE correspondente seja realizado

– Ao ser executado um RECEIVE, o processo receptor é bloqueado até a mensagem chegar


• Comportamento das primitivas SEND e RECEIVE:– Na Comunicação Assíncrona

– A operação SEND é “não bloqueante”, permitindo que o processo remetente prossiga em sua execução assim que a mensagem emitida seja armazenada em algum dispositivo (um buffer local, por exemplo) para envio

– Oferece a vantagem de permitir que o processo continue executando paralelamente ao envio real da mensagem


• Comunicação Assíncrona (cont.)– A operação RECEIVE pode ser implementada de duas formas:

– RECEIVE não bloqueante

– A operação RECEIVE consiste em fornecer um buffer para armazenar a mensagem que será recebida em background. Com isso, o processo receptor pode prosseguir sua execução e deve receber uma notificação posterior informando que há dados a serem processados no buffer

– Isso pode ser implementado usando técnicas de polling ou interrupção

– RECEIVE bloqueante

– Se comporta igual ao RECEIVE da comunicação síncrona


• Comunicação Assíncrona (cont.)• A grande maioria dos sistemas não adota a comunicação

assíncrona em virtude de sua complexidade no tratamento de informações que podem ser recebidas fora do fluxo normal de execução

– Quando a comunicação termina?– Houve alguma falha ou necessidade de

intervenção?

Processamento do Pedido/RespostaProcessamento do Pedido/Resposta

• Um mecanismo de controle comum tanto para primitivas bloqueantes quanto para primitivas não bloqueantes, é o uso de timeouts– O estabelecimento de um limite de tempo facilita o

tratamento de situações de espera muito longa– Em primitivas bloqueantes:

• Se o tempo de espera de um send ou receive for muito alto, além de um determinado valor, pode-se notificar um erro.

– Em primitivas não bloqueantes:• O número de tentativas de enviar/receber pode ser limitado.

Garantia de EntregaGarantia de Entrega

– Até o momento assumimos que sempre que um cliente envia uma mensagem para o servidor, esta é entregue ou falha.

• Na realidade, as mensagens podem se atrasar na entrega, ou falhar na entrega.– Cada vez que um SEND é executado, imagina-se que a

mensagem tenha sido recebida– No entanto, não existem garantias de que isso realmente

aconteceu

Conceitos Básicos


• Proposta 1: assumir que o envio é falho e não confiável– Exemplo: Correios

• Quando se deixa uma carta no correio usando postagem normal, sabe-se que ainda falta um caminho a ser percorrido pela carta até seu destino

• O correio faz o seu melhor para entregar a mensagem, mas não há garantias rígidas de entrega ou prazo

• Algumas vezes, caso os Correios saibam que a mensagem não pode ser entregue, é possívem efetuar a devolução da mensagem e até mesmo a recusa da mesma

• Mas o remetente já se imaginava livre dessa tarefa e sua agenda de atividades não prevê tratar este problema

Conceitos Básicos


• Proposta 2: solicitar a confirmação do recebimento da mensagem– ACK (ACKNOWLEDGE)– Um simples pedido/resposta agora tem 4

mensagens

Cliente Servidor

SO SORede Rede

Pedido

Resposta

ACK

ACK


• Proposta 3: solicitar a confirmação do recebimento da Resposta da Mensagem– Possível devido a característica do modelo Cliente-

Servidor– Um pedido/resposta agora tem 3 mensagens

Conceitos Básicos

Cliente Servidor

SO SORede Rede

Pedido

Resposta

ACK

Implementando o Modelo Cliente/ServidorImplementando o Modelo Cliente/Servidor

Localização Processamento de Envio/Recepção de

mensagens

Garantia

Endereços predefinidos e escritos nos clientes

Boloquear enquanto envia/recebe

Não confiar

Broadcast Não Bloquear Solicitar confirmação para cada mensagem

Serviço de Resolução de Nomes

Notificar quando a mensagem estiver pronta

Solicitar confirmação para cada resposta

Conceitos Básicos

Estudo de Caso: RPCEstudo de Caso: RPC• RPC (Remote Procedure Call)

– É um meio de empacotar e trocar mensagens entre processos de forma a tornar isso mais fácil e mais parecido com a programação convencional.

– É um método de transferência de controle• Quem aciona o procedimento remoto suspende

sua execução e fica aguardando o retorno do mesmo (ou seja, passa o controle da execução adiante)

• O procedimento remoto assume o controle, executa suas funções e devolve o controle para quem o acionou

• O acionador retoma sua execução do ponto em que parou

Estudo de Caso: RPCEstudo de Caso: RPC

• RPC (Remote Procedure Call)– A troca de mensagens entre processos ou o I/O

envolvido não são percebidos pelo programador da aplicação• O ambiente que suporta RPC provê toda a

infraestrutura necessária para que a comunicação aconteça sem que o programador precise codificar isso de forma explícita

Estudo de Caso: RPC (cont.)Estudo de Caso: RPC (cont.)• O que motivou a criação do RPC:

– Programar usando primitivas de comunicação não é uma solução transparente, pois exige conhecimento do ambiente físico ao redor

– Primitivas orientadas a Entrada/Saída (E/S) não conseguem reproduzir nos sistemas distribuídos o mesmo efeito obtido em sistemas centralizados

• Objetivo do RPC:– Tornar mais fácil e transparente a implementação

de aplicações distribuídas

Estudo de Caso: RPC (cont.)Estudo de Caso: RPC (cont.)• STUB

– “Um stub ou method stub em desenvolvimento de software, é um pedaço de código usado para substituir algumas funcionalidades de programação.” (Wikipédia)

– O código referente a chamadas à rede é “escondido” (encapsulado) em procedimentos chamados STUBs

• Os STUBs permitem ao RPC proteger os programas de aplicação em relação a preocupações com detalhes (exemplo: SOCKETS)

• A conversão dos tipos de dados acontece nos STUBS durante a passagem de parâmetros

– Reduz a chance de erros, pois torna o sistema transparente em relação a diferentes representações de dados

Estudo de Caso: RPC (cont.)Estudo de Caso: RPC (cont.)

• STUB– Como obter os STUBs?

• Os STUBs são gerados pelo compilador e “linkados” ao programa

– Em vários sistemas baseados em RPC os STUBs são gerados automaticamente, mas existem algumas implementações que oferecem a opção de gerá-los de forma manual

Estudo de Caso: RPC (cont.)Estudo de Caso: RPC (cont.)• BINDER

– Cliente precisa localizar o servidor que vai executar o procedimento remoto, mas isso deve acontecer de forma transparente

• O responsável pelo processo de localização é um programa chamado “Binder”, que fica disponível na rede em uma ou mais máquinas

• STUBs possuem uma chamada o programa BINDER para obter estas informações

– O programa Binder possui uma tabela com:• Nomes e endereços dos serviços ativos e corretamente

exportados• Um Checksum que identifica a versão de cada interface

exportada

Estudo de Caso: RPC (cont.)Estudo de Caso: RPC (cont.)• Funcionamento do BINDER

– Para cada instância de um serviço que está no ar:• A interface é exportada no início da execução do serviço

para o Binder• Cada serviço ativo é incluído na tabela do binder• Um checksum é calculado a partir da interface exportada• O cliente, ao iniciar, precisa se ligar (bind) ao serviço remoto

desejado

– Este processo é chamado de Dynamic Binding• Os tipos de dados no cliente e no servidor devem ser

compatíveis (mas não necessariamente idênticos)• Cliente e servidor são compilados separadamente mas

precisam ter a mesma interface

Estudo de Caso: RPC (cont.)Estudo de Caso: RPC (cont.)CLIENTE

Aplicação CLIENTECALL ‘rotina’ parm1

Serviço executando

EMPACOTAPARÂMETROS

DESEMPACOTARESULTADOS

DESEMPACOTAPARÂMETROS

EMPACOTARESULTADOS

KERNEL do CLIENTE KERNEL do SERVIDOR

TRANSPORTE DE MENSAGENS VIA REDE

STUBCLIENTE

STUBSERVIDOR

SERVIDOR

Comunicação em GrupoComunicação em Grupo

• Um grupo é uma coleção de processos que atuam juntos em um sistema– Para que o grupo funcione bem, é desejável garantir que

qualquer mensagem enviada ao grupo seja conhecida por todos os seus membros

– Grupos são dinâmicos:• Novos grupos podem ser criados e outros podem ser apagados• Um processo pode se unir a um grupo ou deixar-lo• Um processo pode pertencer a mais de um grupo

Comunicação em GrupoComunicação em Grupo

• Outras características de grupos– É preciso haver algum tipo de estratégia de gestão de

grupos– A existência de um grupo precisa ser transparente

• Quando um processo envia uma mensagem para o grupo, ele não precisa saber o tamanho do grupo e nem a localização dos membros

Comunicação em Grupo:Estratégia de ComunicaçãoComunicação em Grupo:Estratégia de Comunicação• A comunicação em pares (um-para-um) não é o melhor

modelo para comunicação de um processo com um grupo– Para estes casos, o emprego da difusão seletiva (multicast) é a

solução mais indicada

– A adoção de multicast permite a implementação de sistemas distribuídos que suportam as seguintes características:

• Tolerância a falhas baseado em serviços replicados• Localização de serviços de descoberta na interligação de

redes• Melhor desempenho através da replicação de dados• Propagação de notificações de eventos

Comunicação em Grupo:Técnicas de implementaçãoComunicação em Grupo:Técnicas de implementação• Comunicação do grupo com outros processos:

– Grupos abertos• Neste tipo de grupo, qualquer processo externo pode enviar

mensagem para o grupo todo• É uma abordagem usada tipicamente em casos de replicação

de serviços

– Grupos fechados• Neste tipo de grupo, apenas os membros do grupo podem

mandar mensagem para o grupo todo• E como alguém de fora fala com o grupo?

– A mensagem é mandada para um único integrante do grupo, que se encarrega de repassar aos demais

• É uma abordagem usada tipicamente em processamento paralelo

Comunicação em Grupo:Técnicas de implementaçãoComunicação em Grupo:Técnicas de implementação• Comunicação do grupo com outros processos:

Comunicação em Grupo:Técnicas de implementaçãoComunicação em Grupo:Técnicas de implementação• Estrutura interna do grupo:

– Grupos igualitários (ou peers)• Todos os processos são iguais e as decisões são tomadas coletivamente• É um grupo simétrico, e isso evita a existência de um ponto único de

falha, já que todos os processos são iguais e podem desempenhar as mesmas funções

• A tomada de decisão bem mais complexa

– Grupos hierárquicos• Existe algum tipo de hierarquia entre os membros• A organização mais simples (mas não a única possível) deste tipo de grupo

consiste em um processo coordenador e outros processos denominados trabalhadores

– Quando uma requisição é feita, o coordenador decide qual trabalhador é o mais apropriado para realizar a tarefa, ou define que todos devem realizar a tarefa

• Possui um ponto único de falha (geralmente, o coordenador)• A tomada de decisão neste tipo de grupo é mais simples

Comunicação em Grupo:Controle de MembrosComunicação em Grupo:Controle de Membros

• É preciso realizar de alguma forma o controle de quais são os membros do grupo, bem como permitir a inclusão e exclusão de membros

• As duas principais formas de fazer essa gerência são:– Usando um servidor de grupo

• Todas as requisições devem ser feitas ao servidor• O servidor deve manter uma base de dados completa de todos os grupos

e seu conjunto exato de membros• É eficiente, direto e fácil de implementar, mas o servidor torna-se uma

vulnerabilidade da solução– Adotando um controle distribuído

• Cada novo membro deve enviar mensagem a todos os membros atuais anunciando a sua presença e, ao sair, deve avisar a todos os outros membros

• É uma solução mais tolerante a falhas• Quando um membro falha ele deixa de pertencer ao grupo e não há

mensagens de aviso• A entrada e a saída do grupo devem ser sincronizadas com a troca de

mensagens

Comunicação em Grupo:AtomicidadeComunicação em Grupo:Atomicidade• Quando uma mensagem é enviada para o grupo, ela deverá

chegar corretamente para todos os membros ou para nenhum deles– Não são permitidas situações onde alguns membros recebem a

mensagem e outros não (entrega parcial da mensagem)– Isso torna a programação de aplicações mais fácil, pois quando um

processo envia uma mensagem para o grupo não precisa se preocupar com o fato de alguém não ter recebido a mensagem

• Falhas na entrega são reportadas ao emissor da mensagem– Sabendo-se que a mensagem falhou, é possível realizar as ações

necessárias para recuperação da consistência do processamento

Comunicação em Grupo:AtomicidadeComunicação em Grupo:Atomicidade• A implementação da atomicidade não é simples

– A única forma de garantir a entrega da mensagem para todos os destinos é através do envio de mensagens de reconhecimento

• Tolerância a falhas– É essencial que a atomicidade seja mantida mesmo na presença

de falhas

– Exemplo de falha:• O emissor envia uma mensagem para todos os membros do

grupo e falha em seguida• Um processo do grupo não recebe a mensagem• Não há mais um emissor para ser avisado, logo, não existe

possibilidade de retransmissão da mensagem• Qual a ação do grupo?

– Resposta: ignorar a mensagem

Comunicação em Grupo:OrdenaçãoComunicação em Grupo:Ordenação• Um mecanismo de comunicação em grupo precisa ter uma

semântica bem definida com relação à ordem em que as mensagens serão entregues.

• A melhor garantia para isto é fazer com que as mensagens sejam entregues na mesma ordem em que foram enviadas

• Como nem sempre é possível imitar a ordem de envio, existem quatro tipos diferentes de ordenação que normalmente estão implementadas nos mecanismos de comunicação de grupo:– Sem Ordem– Ordenamento FIFO– Ordenamento Causal– Ordenamento Total

Comunicação em Grupo:OrdenaçãoComunicação em Grupo:Ordenação• Tipos de ordenação:

– Sem Ordem• As mensagens são enviadas ao grupo sem a preocupação de ordenamento• Tem o menor overhead pois não necessita controle algum de sequência• Nem sempre é adequado para certas aplicações.

– Ordenamento FIFO• Garante que todas as mensagens de um membro sejam entregues aos demais na

ordem que o mesmo enviou• Não garante que todas as mensagens serão ordenadas, apenas ordena por membro

– Ordenamento CAUSAL• Adota o conceito de mensagem dependente de outra• Se uma mensagem “A” é dependente de outra mensagem “B”, então “A” deve

sempre ser recebida depois de “B”• Exemplo: respostas de mensagens em listas de discussão

– Ordenamento TOTAL• Cada membro do grupo recebe TODAS as mensagens na mesma ordem

Comunicação em Grupo:OrdenaçãoComunicação em Grupo:Ordenação

Problema do

ordenamento FIFO

sd04 (si) comunicação em sd

Documents