Sd04 (si) comunicação em sd

524 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
524
On SlideShare
0
From Embeds
0
Number of Embeds
34
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sd04 (si) comunicação em sd

  1. 1. Sistemas DistribuídosParte 04Comunicação em SDOBS: Partes deste material foi baseado em fontes obtidas no site da UNICAMP (mc704)
  2. 2. Introdução• A maior diferença entre um sistema monoprocessado e umsistema 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 degarantir a disponibilidade deste recurso) obriga os componentesdos sistemas distribuídos a buscar outra solução para interagir– Troca de mensagens– Implica em adotar protocolos de comunicação para permitir queambientes heterogêneos troquem mensagens
  3. 3. Protocolos de Comunicação– Protocolos são regras pré-estabelecidas paracomunicação entre duas ou mais partes• O uso de camadas facilita sua implementação eentendimento, já que cada camada possui responsabilidadesespecíficas• Em 1983, a International Standards Organization (ISO)desenvolveu um modelo de referência que identificaclaramente os vários níveis envolvidos e suas atribuições: o“Modelo OSI” (Open Systems Interconnection ReferenceModel)– Voltado para comunicação entre sistemas abertos– Um sistema aberto é preparado para se comunicar com qualquer outro sistemaaberto através de regras que ditam o formato, conteúdo e significado dasmensagens enviadas e recebidas.
  4. 4. Modelos de Protocolos• Protocolos orientados à conexão– Neste modelo, o emissor e o receptor de umadeterminada mensagem devem estabelecer uma conexãoantes que ocorra a troca de dados propriamente dita• Existe possibilidade inclusive de negociação de aspectos doprotocolo• Protocolos sem conexão– Conforme o nome já indica, não há necessidade de que oemissor e o receptor de uma determinada mensagemestejam conectados para a comunicação acontecer
  5. 5. O Modelo OSI• Características:– Dividido em setecamadas defuncionalidade• Cada camada trata deum aspecto dacomunicação e provêuma interface(operações que definemos serviços da camada)às camadas adjacentes– Cabeçalhos efinalizadores podem seracrescentados eretirados às mensagens
  6. 6. Características Importantes naComunicação SD• Dependabilidade (qualidade do serviço oferecidopor um dado sistema)– Em geral, sistema é considerado confiável se hágarantia de entrega de mensagens apesar da perda deum 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
  7. 7. APIs de Comunicação• APIs de comunicação permitem que as aplicações enviem erecebam dados– Fornecem primitivas de comunicação que podem ser chamadasa partir do código– Oferecem acesso aos serviços de comunicação, que podemassim 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, SunRPC, ...)• Canais de eventos:– Permitem notificar threads e processos dos eventos ocorridos no sistema (Ex.:JMS, CORBA Notification Service, …)
  8. 8. API Socket• São abstrações que representam uma porta decomunicaçã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
  9. 9. Comunicação Cliente/Servidor• Conceitos básicos:– Servidor: oferece serviços– Cliente: consome serviços oferecidos– Em termos lógicos, para que dois processos secomuniquem é preciso apenas a existência de duasoperaçõ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”?
  10. 10. Comunicação Cliente/Servidor (cont.)• Como o cliente localiza o servidor para solicitar umserviço?– Opção 1: O pedido é enviado para o endereço do servidoracompanhado pelo endereço do processo/serviço• Desvantagem: endereço estático no código do clienteCliente ServidorSO SORede RedePedido para 123.1Resposta para 123.2
  11. 11. Comunicação Cliente/Servidor (cont.)• Como o cliente localiza o servidor para solicitar umserviç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 (reduzsobrecarga)Cliente ServidorSO SORede RedeResposta para 0.0 (broadcast)Pedido para 0.0 (broadcast)
  12. 12. Comunicação Cliente/Servidor (cont.)• Como o cliente localiza o servidor para solicitar umserviço?– Opção 3: O cliente consulta um serviço de resolução denomes para localizar o servidor desejado• Desvantagem: exige um serviço adicional centralizadoClienteSORedeServidorSORedePedido de resolução de nomesResposta do endereço realServidor NSSORede
  13. 13. Comunicação Cliente/Servidor (cont.)• 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 estejamsincronizadas a cada troca de mensagem, ou seja, asoperações de SEND e RECEIVE causam bloqueios emsuas respectivas execuções– Ao ser emitido um SEND, o emissor é bloqueado até queum RECEIVE correspondente seja realizado– Ao ser executado um RECEIVE, o processo receptor ébloqueado até a mensagem chegar
  14. 14. Comunicação Cliente/Servidor (cont.)• Comportamento das primitivas SEND eRECEIVE:– Na Comunicação Assíncrona– A operação SEND é “não bloqueante”, permitindoque o processo remetente prossiga em suaexecução assim que a mensagem emitida sejaarmazenada em algum dispositivo (um buffer local,por exemplo) para envio– Oferece a vantagem de permitir que o processocontinue executando paralelamente ao envio realda mensagem
  15. 15. Comunicação Cliente/Servidor (cont.)• 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 umbuffer para armazenar a mensagem que serárecebida em background. Com isso, o processoreceptor pode prosseguir sua execução e devereceber uma notificação posterior informando quehá dados a serem processados no buffer– Isso pode ser implementado usando técnicas depolling ou interrupção– RECEIVE bloqueante– Se comporta igual ao RECEIVE da comunicaçãosíncrona
  16. 16. Comunicação Cliente/Servidor (cont.)• Comunicação Assíncrona (cont.)• A grande maioria dos sistemas não adota a comunicaçãoassíncrona em virtude de sua complexidade no tratamentode informações que podem ser recebidas fora do fluxonormal de execução– Quando a comunicação termina?– Houve alguma falha ou necessidade deintervenção?
  17. 17. Processamento do Pedido/Resposta• Um mecanismo de controle comum tanto paraprimitivas bloqueantes quanto para primitivas nãobloqueantes, é o uso de timeouts– O estabelecimento de um limite de tempo facilita otratamento de situações de espera muito longa– Em primitivas bloqueantes:• Se o tempo de espera de um send ou receive for muito alto, alémde um determinado valor, pode-se notificar um erro.– Em primitivas não bloqueantes:• O número de tentativas de enviar/receber pode ser limitado.
  18. 18. Garantia de Entrega– Até o momento assumimos que sempre que umcliente envia uma mensagem para o servidor, esta éentregue ou falha.• Na realidade, as mensagens podem se atrasar naentrega, ou falhar na entrega.– Cada vez que um SEND é executado, imagina-se que amensagem tenha sido recebida– No entanto, não existem garantias de que isso realmenteaconteceuConceitos Básicos
  19. 19. Garantia de Entrega• Proposta 1: assumir que o envio é falho e nãoconfiável– Exemplo: Correios• Quando se deixa uma carta no correio usando postagemnormal, sabe-se que ainda falta um caminho a serpercorrido pela carta até seu destino• O correio faz o seu melhor para entregar a mensagem, masnão há garantias rígidas de entrega ou prazo• Algumas vezes, caso os Correios saibam que a mensagemnão pode ser entregue, é possívem efetuar a devolução damensagem e até mesmo a recusa da mesma• Mas o remetente já se imaginava livre dessa tarefa e suaagenda de atividades não prevê tratar este problemaConceitos Básicos
  20. 20. Garantia de Entrega• Proposta 2: solicitar a confirmação dorecebimento da mensagem– ACK (ACKNOWLEDGE)– Um simples pedido/resposta agora tem 4mensagensCliente ServidorSO SORede RedePedidoRespostaACKACK
  21. 21. Garantia de Entrega• Proposta 3: solicitar a confirmação dorecebimento da Resposta da Mensagem– Possível devido a característica do modelo Cliente-Servidor– Um pedido/resposta agora tem 3 mensagensConceitos BásicosCliente ServidorSO SORede RedePedidoRespostaACK
  22. 22. Implementando o ModeloCliente/ServidorLocalização Processamento deEnvio/Recepção demensagensGarantiaEndereçospredefinidos e escritosnos clientesBoloquear enquantoenvia/recebeNão confiarBroadcast Não Bloquear Solicitar confirmaçãopara cada mensagemServiço de Resoluçãode NomesNotificar quando amensagem estiverprontaSolicitar confirmaçãopara cada respostaConceitos Básicos
  23. 23. Estudo de Caso: RPC• RPC (Remote Procedure Call)– É um meio de empacotar e trocar mensagens entreprocessos de forma a tornar isso mais fácil e maisparecido com a programação convencional.– É um método de transferência de controle• Quem aciona o procedimento remoto suspendesua execução e fica aguardando o retorno domesmo (ou seja, passa o controle da execuçãoadiante)• O procedimento remoto assume o controle,executa suas funções e devolve o controle paraquem o acionou• O acionador retoma sua execução do ponto emque parou
  24. 24. Estudo de Caso: RPC• RPC (Remote Procedure Call)– A troca de mensagens entre processos ou o I/Oenvolvido não são percebidos pelo programadorda aplicação• O ambiente que suporta RPC provê toda ainfraestrutura necessária para que acomunicação aconteça sem que oprogramador precise codificar isso de formaexplícita
  25. 25. 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 exigeconhecimento do ambiente físico ao redor– Primitivas orientadas a Entrada/Saída (E/S) nãoconseguem reproduzir nos sistemas distribuídos omesmo efeito obtido em sistemas centralizados• Objetivo do RPC:– Tornar mais fácil e transparente a implementaçãode aplicações distribuídas
  26. 26. Estudo de Caso: RPC (cont.)• STUB– “Um stub ou method stub em desenvolvimentode software, é um pedaço de código usado parasubstituir algumas funcionalidades deprogramação.” (Wikipédia)– O código referente a chamadas à rede é“escondido” (encapsulado) em procedimentoschamados STUBs• Os STUBs permitem ao RPC proteger os programas deaplicação em relação a preocupações com detalhes(exemplo: SOCKETS)• A conversão dos tipos de dados acontece nos STUBSdurante a passagem de parâmetros– Reduz a chance de erros, pois torna o sistematransparente em relação a diferentesrepresentações de dados
  27. 27. 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ãogerados automaticamente, mas existem algumasimplementações que oferecem a opção de gerá-losde forma manual
  28. 28. Estudo de Caso: RPC (cont.)• BINDER– Cliente precisa localizar o servidor que vai executar oprocedimento remoto, mas isso deve acontecer deforma transparente• O responsável pelo processo de localização é um programachamado “Binder”, que fica disponível na rede em uma oumais máquinas• STUBs possuem uma chamada o programa BINDER paraobter estas informações– O programa Binder possui uma tabela com:• Nomes e endereços dos serviços ativos e corretamenteexportados• Um Checksum que identifica a versão de cada interfaceexportada
  29. 29. 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çopara 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 remotodesejado– Este processo é chamado de Dynamic Binding• Os tipos de dados no cliente e no servidor devem sercompatíveis (mas não necessariamente idênticos)• Cliente e servidor são compilados separadamente masprecisam ter a mesma interface
  30. 30. Estudo de Caso: RPC (cont.)CLIENTEAplicação CLIENTECALL ‘rotina’ parm1Serviço executandoEMPACOTAPARÂMETROSDESEMPACOTARESULTADOSDESEMPACOTAPARÂMETROSEMPACOTARESULTADOSKERNEL do CLIENTE KERNEL do SERVIDORTRANSPORTEDE MENSAGENSVIA REDESTUBCLIENTESTUBSERVIDORSERVIDOR
  31. 31. Comunicação em Grupo• Um grupo é uma coleção de processos que atuamjuntos em um sistema– Para que o grupo funcione bem, é desejável garantir quequalquer mensagem enviada ao grupo seja conhecida portodos 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
  32. 32. Comunicação em Grupo• Outras características de grupos– É preciso haver algum tipo de estratégia de gestão degrupos– A existência de um grupo precisa ser transparente• Quando um processo envia uma mensagem para ogrupo, ele não precisa saber o tamanho do grupo enem a localização dos membros
  33. 33. Comunicação em Grupo:Estratégia de Comunicação• A comunicação em pares (um-para-um) não é o melhormodelo para comunicação de um processo com umgrupo– Para estes casos, o emprego da difusão seletiva (multicast) é asolução mais indicada– A adoção de multicast permite a implementação de sistemasdistribuí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 deredes• Melhor desempenho através da replicação de dados• Propagação de notificações de eventos
  34. 34. Comunicaçã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 enviarmensagem para o grupo todo• É uma abordagem usada tipicamente em casos dereplicação de serviços– Grupos fechados• Neste tipo de grupo, apenas os membros do grupo podemmandar mensagem para o grupo todo• E como alguém de fora fala com o grupo?– A mensagem é mandada para um único integrante dogrupo, que se encarrega de repassar aos demais• É uma abordagem usada tipicamente em processamentoparalelo
  35. 35. Comunicação em Grupo:Técnicas de implementação• Comunicação do grupo com outros processos:
  36. 36. Comunicaçã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 defalha, já que todos os processos são iguais e podem desempenhar asmesmas 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 degrupo consiste em um processo coordenador e outros processosdenominados trabalhadores– Quando uma requisição é feita, o coordenador decide qualtrabalhador é o mais apropriado para realizar a tarefa, ou define quetodos devem realizar a tarefa• Possui um ponto único de falha (geralmente, o coordenador)• A tomada de decisão neste tipo de grupo é mais simples
  37. 37. Comunicação em Grupo:Controle de Membros• É preciso realizar de alguma forma o controle de quais são os membrosdo 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 grupose seu conjunto exato de membros• É eficiente, direto e fácil de implementar, mas o servidor torna-se umavulnerabilidade da solução– Adotando um controle distribuído• Cada novo membro deve enviar mensagem a todos os membros atuaisanunciando a sua presença e, ao sair, deve avisar a todos os outrosmembros• É 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 demensagens
  38. 38. Comunicação em Grupo:Atomicidade• Quando uma mensagem é enviada para o grupo, ela deveráchegar corretamente para todos os membros ou paranenhum deles– Não são permitidas situações onde alguns membros recebem amensagem e outros não (entrega parcial da mensagem)– Isso torna a programação de aplicações mais fácil, pois quando umprocesso envia uma mensagem para o grupo não precisa se preocuparcom 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çõesnecessárias para recuperação da consistência do processamento
  39. 39. Comunicação em Grupo:Atomicidade• A implementação da atomicidade não é simples– A única forma de garantir a entrega da mensagem para todos osdestinos é através do envio de mensagens de reconhecimento• Tolerância a falhas– É essencial que a atomicidade seja mantida mesmo na presençade falhas– Exemplo de falha:• O emissor envia uma mensagem para todos os membros dogrupo 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 existepossibilidade de retransmissão da mensagem• Qual a ação do grupo?– Resposta: ignorar a mensagem
  40. 40. Comunicação em Grupo:Ordenação• Um mecanismo de comunicação em grupo precisa ter umasemântica bem definida com relação à ordem em que asmensagens serão entregues.• A melhor garantia para isto é fazer com que as mensagenssejam 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 quenormalmente estão implementadas nos mecanismos decomunicação de grupo:– Sem Ordem– Ordenamento FIFO– Ordenamento Causal– Ordenamento Total
  41. 41. Comunicaçã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 naordem 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” devesempre 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
  42. 42. Comunicação em Grupo:OrdenaçãoProblema doordenamento FIFO

×