WIXLIB

SISTEMAS iskMemoeyComunicação em Sistemas DistribuídosSumárioModelo Cliente e ServidorTroca de MensagensRemote Procedure CallComunicação GrupalObjetos DistribuídosOutros Mecanismo de ComunicaçãoSistemas Distribuídos 2007Prof. Carlos Paes21

Comunicação em SistemasDistribuídosQuando múltiplos processos fazem umtrabalho conjunto, eles devem interagir“Comunicação interprocesso” (IPC): forma deinteração ou comunicação entre processosSistemas distribuídos possuem mecanismo decomunicação entre processos em diferentesmáquinas (remotas), pois não hácompartilhamento de memória físicaSistemas Distribuídos 2007Prof. Carlos Paes3Modelo Cliente/ServidorBase para um sistema distribuídosÉ um processamento cooperativo derequisições submetidas por um cliente a umservidor que as processa e retorna umresultadoÉ uma forma especial de processamentodistribuído em que os recursos estãoespalhados em mais de um computador.Sistemas Distribuídos 2007Prof. Carlos Paes42

Modelo Cliente/ServidorProtocoloRequest (Requisição)Reply (Resposta)Simples e diretoRequisiçãoServidorClienteResposta à requisiçãoSistemas Distribuídos 2007Prof. Carlos Paes5Modelo Cliente/ServidorCliente/Servidor – Primeira GeraçãoModelo de processamento para compartilhamentode dispositivosModelo de processamento cliente/servidorProcessamento Peer-to-Peer (Igualitário ou pontoa-ponto)Cliente/Servidor – Segunda GeraçãoEvolução do sistema duas camadas para umsistema com várias camadas, altamentedistribuído e cooperativo;Sistemas Distribuídos 2007Prof. Carlos Paes63

Implementação Cliente/ServidorBaseada no protocolo de Request(Requisição) e Reply (Resposta)Utiliza troca de mensagens através da redeQuestões a tratar:EndereçamentoPrimitivas empregadasBufferizaçãoConfiabilidadeSistemas Distribuídos 2007Prof. Carlos Paes7Implementação Cliente/Servidor(Endereçamento)Um cliente para mandar uma mensagem aum servidor precisa saber o endereçoExistem várias formas de endereçamentoPrincipais destacados:Endereçamento por número de máquinaEndereçamento por processoEndereçamento por nomes ASCII obtidos de umservidor de nomes (name server)Sistemas Distribuídos 2007Prof. Carlos Paes84

Implementação Cliente/Servidor(Endereçamento)Endereçamento por número demáquinaSistemas Distribuídos 2007Prof. Carlos Paes9Implementação Cliente/Servidor(Endereçamento)Endereçamento por número demáquinaPode-se utilizar uma combinação entrenúmero da máquina e número do processoSistemas Distribuídos 2007Prof. Carlos Paes105

Implementação Cliente/Servidor(Endereçamento)Endereçamento por processoAssociar a cada processo um endereço únicoque não contém o número da máquinaDuas alternativas para escolha do número doprocesso: Processo centralizado responsável pela alocação deendereços. (Contador incrementado a cada requisição) Cada processo pega seu próprio endereçoaleatoriamente de um grande espaço de dados.Sistemas Distribuídos 2007Prof. Carlos Paes11Implementação Cliente/Servidor(Endereçamento)o cliente pode fazer broadcast de um pacoteespecial para localização (locate packet)o kernel que contém o processo devolve umamensagem do tipo here I amSistemas Distribuídos 2007Prof. Carlos Paes126

Implementação Cliente/Servidor(Endereçamento)Endereçamento por name serverUtiliza uma máquina extra para mapearnomes de serviços em endereços demáquinasservidores são referidos como strings eestas são embutidas nos programasSistemas Distribuídos 2007Prof. Carlos Paes13Implementação Cliente/Servidor(Endereçamento)Endereçamento por name serverSistemas Distribuídos 2007Prof. Carlos Paes147

Implementação Cliente/Servidor(Primitivas Bloqueantes ou Não-Bloqueantes)Primitivas Bloqueantes (síncronas)no send, enquanto a mensagem está sendo enviada, oprocesso fica bloqueadoo receive fica bloqueado até que alguma mensagem chegueou até um timeoutPrimitivas Não-Bloqueantes (assíncronas)o send retorna o controle imediatamente, antes damensagem ser realmente enviadao receive passa para o kernel o ponteiro para o buffer eretorna imediatamente, antes de receber a mensagem em algumas abordagens o receive não-bloqueante éaquele que só recebe quando já existem mensagens efica bloqueado até completar a recepçãoSistemas Distribuídos 2007Prof. Carlos Paes15Implementação Cliente/Servidor(Primitivas Bloqueantes)processo fica bloqueado durante atransferência de mensagemMelhor opção para envio de mensagensem condições normaisSistemas Distribuídos 2007Prof. Carlos Paes168

Implementação Cliente/Servidor(Primitivas Não-Bloqueantes)Primitivas não-bloqueantes com cópiao kernel copia a mensagem para um bufferinterno e então libera o processo paracontinuarPrimitivas não-bloqueantes cominterrupçãointerrompe o processo que enviou amensagem quando o buffer estiver livrepara reutilizaçãoSistemas Distribuídos 2007Prof. Carlos Paes17Implementação Cliente/Servidor(Primitivas Não-Bloqueantes)TanenbaumA diferença essencial entre uma primitiva síncrona e umaassíncrona é se o processo que envia a mensagem podereutilizar o buffer imediatamente após o comando sendpreferida por projetistas de sistemas operacionaisAndrewsUma primitiva síncrona é aquela em que o processo queenvia fica bloqueado até que o receptor aceite a mensageme mande um ack. Qualquer outra alternativa é consideradaassíncronapreferida por projetistas de linguagens de programaçãoSistemas Distribuídos 2007Prof. Carlos Paes189

Implementação Cliente/ServidorBufferizaçãoPrimitivas não-bufferizadasO buffer para armazenar a mensagem deve ser especificadopelo programadorExistem duas estratégias a serem empregadas no caso deum send do cliente, sem um receive do servidor: discartar mensagens inesperadas temporariamente manter mensagens inesperadasPrimitivas bufferizadasExiste um buffer para armazenar mensagens inesperadas(Kernel)A primitiva de bufferização mais empregada defineestruturas de dados chamadas mailboxSistemas Distribuídos 2007Prof. Carlos Paes19Implementação Cliente/ServidorConfiabilidadeTrês diferentes alternativas podem ser utilizadas:assumir que as primitivas não são confiáveis, alterando asemântica do send o sistema não garante que as mensagens são enviadas o usuário fica responsável por implementar comunicaçãoconfiávelprimitivas confiáveis com mecanismos de acknowledgmentdo tipo: Request - Ack - Reply - Ackprimitivas confiáveis com mecanismos de acknowledgmentdo tipo: Request - Reply - Ackcombinações podem ser obtidas entre os mecanismosconfiáveisSistemas Distribuídos 2007Prof. Carlos Paes2010

Implementação Cliente/ServidorConfiabilidadeRequest - Ack - Reply - Acksomente quando o Ack é recebido, o processo é liberadoo acknowledgement é feito entre kernels (transparente para ocliente ou servidor)um request/reply com este mecanismo necessita de quatromensagensSistemas Distribuídos 2007Prof. Carlos Paes21Implementação Cliente/ServidorConfiabilidadeRequest - Reply - AckO Reply serve como um ack o cliente fica bloqueado até a mensagen de reply se a mensagem de reply demorar, o cliente reenvia arequisição em alguns kernels não é necessário o ackSistemas Distribuídos 2007Prof. Carlos Paes2211

Implementação Cliente/ServidorOutras QuestõesAs redes têm um tamanho máximo depacote, mensagens maiores devem serquebradasO acknowledgment pode ser utilizadopor pacote ou por mensagem,dependendo da taxa de erros da redeSistemas Distribuídos 2007Prof. Carlos Paes23Implementação Cliente/ServidorExemplo de ProtocoloPacotes normalmente empregados noprotocolo de comunicação:Sistemas Distribuídos 2007Prof. Carlos Paes2412

Implementação Cliente/ServidorComunicação usando o protocoloAlguns exemplos de comunicação:Sistemas Distribuídos 2007Prof. Carlos Paes25Troca de MensagensEnvio de dados e controle pela rede para umou mais participantes.Forma mais primitiva e comum, próxima àredeMensagem é uma estrutura de dadosPrimitivas básicas são usadas aos pares:envio: send(msg) ou send(destino, msg)recepção: recv(&msg) ou recv(origem, &msg)identificação de destino (endereçamento)?processo, CP, IP/porta.Sistemas Distribuídos 2007Prof. Carlos Paes2613

Troca de MensagensServiço de envio:processo P solicita envio de mensagem à Qprocesso Q solicita recebimento demensagem de P,ou um procedimento em Qé executado quando chega a mensagemSistemas Distribuídos 2007Prof. Carlos Paes27Troca de MensagensTransmissão síncrona x assíncrona: quando oremetente é desbloqueado?após a mensagem ter sido processada peloreceptorapós a mensagem ter sido entregue ao receptorapós a mensagem ter chegado ao nó receptorapós a mensagem ter partido do nó transmissorapós a mensagem ter sido copiada para os buffersdo nó transmissor imediatamenteSistemas Distribuídos 2007Prof. Carlos Paes2814

Troca de MensagensTransmissão confiável x não confiável:que garantias?ok apenas se não houver nenhum tipode falha (omissão,atraso.)ok se houver perdas de mensagens e seo remetente ou receptor(es) morrerem?Sistemas Distribuídos 2007Prof. Carlos Paes29Troca de MensagensTransmissão com x sem conexãocom conexão, remetente e receptorconversam para estabelecer uma conexãoentre dois pontos (“endpoints”)o que representa exatamente umaconexão? informações de estado emambas as parteso que é “stateless”?Sistemas Distribuídos 2007Prof. Carlos Paes3015

Troca de MensagensModelos (Os mecanismos tradicionaisde transmissão de pacotes são) :unicastbroadcastmulticastanycastconcastSistemas Distribuídos 2007Prof. Carlos Paes31Chamada Remota deProcedimento (RPC)Desviando o fluxo de execução para umamáquina remota, passando argumentos erecebendo valores de resposta.Permite a um processo executar uma“subrotina” em um outro processo,possivelmente remotoPor exemplo, processo P executa funçãopow() que faz parte do Processo QSistemas Distribuídos 2007Prof. Carlos Paes3216

Chamada Remota deProcedimento (RPC)Sistemas Distribuídos 2007Prof. Carlos Paes33Chamada Remota deProcedimento (RPC)Sistemas Distribuídos 2007Prof. Carlos Paes3417

Chamada Remota deProcedimento (RPC)Justificativa para criação de RPC foi que“passagem de mensagens” era ummecanismo complexo e dificultavadesenvolvimento de aplicações distribuídasRPC “esconde” troca de mensagens emchamadas de procedimentos sintaxe próximaa chamadas em linguagens tradicionaisfacilitou conversão de aplicações legadas emdistribuídasSistemas Distribuídos 2007Prof. Carlos Paes35Chamada Remota deProcedimento (RPC)Segue modelo cliente/servidor, emgeral com interações síncronasQuestão: mas como poderiam serassíncronas?Sistemas Distribuídos 2007Prof. Carlos Paes3618

Chamada Remota deProcedimento (RPC)Lado cliente:aplicativo, lado cliente, que solicita serviço“stub cliente”, gerado automaticamente“RPC runtime” do lado do clienteLado servidor:aplicativo, lado servidor, que recebe solicitação eprocessa“stub servidor”, gerado automaticamente“RPC runtime” do lado do servidorCódigo do stub cliente e servidor sãoSistemas Distribuídos 2007compiladosProf. Carlos Paes37Chamada Remota deProcedimento (RPC)Problemas e Limitações:Obter com RPC mesma semântica dechamada local é difícil, por diversas razões,conforme explicado a seguir.Necessário fase de binding (amarração): stub precisa primeiro localizar função (máquinae porta associadas) uma solução é uma base de dados comlocalização das subrotinas, base de dadospossui endereço fixo e conhecidoSistemas Distribuídos 2007Prof. Carlos Paes3819