estratégia de trabalho - departamento de ciência da ... · escondem absolutamente nada da...
TRANSCRIPT
2
- Comunicação Remota
Comunicação entre processos está no coração de todo sistema distribuído.
Não tem sentido estudar sistemas distribuídos sem examinar cuidadosamente os modos pelos quais processos em máquinas diferentes podem trocar informações.
A comunicação em sistemas distribuídos é sempre baseada em troca de mensagens de baixo nível como a oferecida pela rede subjacente.
Sistemas distribuídos modernos frequentemente consistem em milhares ou até milhões de processos espalhados por uma rede cuja comunicação não é confiável, como a Internet.
Existem três modelos de comunicação de ampla utilização:
Chamada de procedimento remoto (Remote Procedure Call - RPC)
Middleware orientado a mensagem (Message-Oriented Middleware - MOM)
Fluxo de dados.
3
- Comunicação Remota
Chamada de procedimento remoto
Muitos sistemas são baseados em troca explícita de mensagens entre processos.
Contudo, os procedimentos send e receive não escondem absolutamente nada da comunicação, o que é importante para obter transparência de acesso em sistemas distribuídos.
Proposta diferente de manipular comunicação por Birrell e Nelson (1984).
4
- Comunicação Remota
Chamada de procedimento remoto
A sugestão é permitir que programas chamassem procedimentos localizados em outras máquinas.
Quando um processo na máquina A chama um procedimento na máquina B, o processo chamador A é suspenso, e a execução do procedimento chamado ocorre em B.
Informações podem ser transportadas do chamador para quem foi chamado nos parâmetros e podem voltar no resultado do procedimento (a semântica de uma chamada remota deve ser idêntica à de uma chamada local: passa parâmetros e retorna resultados).
6
- Comunicação Remota
Chamada de procedimento remoto
O cliente que acessa um serviço inclui um procedimento stub para cada procedimento da interface de serviço.
A função de um procedimento stub é semelhante à de um método proxy. Ele se comporta como um procedimento local para o cliente, mas em vez de executar a chamada, ela empacota o identificador de procedimento e os argumentos em uma mensagem de requisição e a envia para o servidor por meio de seu módulo de comunicação.
7
- Comunicação Remota
Chamada de procedimento remoto
Quando a mensagem de resposta chega, ela desempacota os resultados.
O processo servidor contém um despachante junto com um procedimento stub de servidor e um procedimento de serviço, para cada procedimento na interface de serviço.
O despachante seleciona um dos procedimentos stub de servidor, de acordo com o identificador de procedimento presente na mensagem de requisição.
8
- Comunicação Remota
Chamada de procedimento remoto
Um procedimento stub de servidor é como um método esqueleto, pois ele desempacota os argumentos presentes na mensagem de requisição, chama o procedimento de serviço correspondente e empacota os valores de retorno para a mensagem de resposta.
Os procedimentos de serviço implementam os procedimentos da interface de serviço.
9
- Comunicação Remota
RMI Java
A RMI Java estende o modelo de objeto Java para dar suporte para objetos distribuídos na linguagem Java.
Em particular, ela permite que os objetos invoquem métodos em objetos remotos usando a mesma sintaxe das invocações locais.
Além disso, a verificação de tipo se aplica igualmente às invocações remotas e às locais.
Entretanto, um objeto que faz uma invocação remota sabe que seu destino é remoto, pois precisa tratar exceções RemoteException; e o implementador de um objeto remoto sabe que é remoto porque precisa implementar a interface Remote.
15
- Comunicação Remota
RMI Java
Passagem de parâmetros e resultados Na RMI Java, supõe-se que os parâmetros de um método são
parâmetros de entrada e o resultado de um método é um único parâmetro de saída.
Qualquer objeto que seja serializável – isto é, que implemente a interface Serializable – pode ser passado como argumento ou ser resultado na RMI Java.
Todos os tipos primitivos e objetos remotos são serializáveis. As classes de argumentos e valores de resultado são
carregadas por download no destino pelo sistema RMI, quando necessário.
16
- Comunicação Remota
RMI Java
Download de classes A linguagem Java é projetada para permitir que as
classes sejam carregadas por download de uma máquina virtual a outra.
Isso é particularmente relevante para objetos distribuídos que se comunicam por meio de invocação remota.
Se o destino ainda não possuir a classe de um objeto passado por valor, seu código será carregado por download automaticamente.
17
- Comunicação Remota
RMI Java
RMIregistry O RMIregistry é o vinculador da RMI Java. Uma instância de RMIregistry deve ser executada em cada
computador servidor que contenha objetos remotos. Ele mantém uma tabela mapeando nomes textuais no estilo
dos URLs, em referências para objetos remotos contidos nesse computador.
Ele é acessado por métodos da classe Naming, cujos métodos recebem como argumento uma string no formato como URL, na forma:
• //nomeComputador:porta/nomeObjeto
20
- Comunicação Remota
Comunicação orientada a mensagem
RPC e invocações de objeto remoto ocultam comunicação em sistemas distribuídos (transparência)
Mas quando não se pode garantir que o receptor esteja em execução no momento em que uma requisição é emitida, são necessários mecanismos alternativos de comunicação
No RPC a comunicação síncrona pode ser feita com o bloqueio do cliente até que suas requisições tenham sido processadas pelo receptor
21
- Comunicação Remota
Comunicação orientada a mensagem
Outra solução é a troca de mensagens
Permite o enfileiramento de mensagens mesmo ainda que as partes não estejam executando no momento em que a comunicação é iniciada
Comunicação assíncrona
22
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação transiente orientada a mensagem Interface Berkeley: interface Sockets proposta na
década de 70 para o Unix Berkeley
23
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação transiente orientada a mensagem Interface Berkeley: interface Sockets proposta na
década de 70 para o Unix Berkeley
24
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação transiente orientada a mensagem Interface de troca de mensagem (MPI):
necessidade de interconexão em redes de alta velocidade (como as usadas por clusters) e uma interface que manipule características avançadas como diferentes formas de buffer e sincronização
Projetada para aplicações paralelas e independente de hardware e plataforma
25
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação transiente orientada a mensagem
26
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Objetivo: comparado a interface de Sockets e
MPI, o MOM normalmente visa o suporte de transferências de mensagens que têm a permissão de durar minutos em vez de segundos ou milissegundos
Conhecido como Middleware Oritentado a Mensagem (MOM)
27
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Modelo de enfileiramento de mensagens
• Comunicação através da inserção de mensagens em filas específicas
• Um aspecto importante de sistemas de enfileiramento é que, em geral, um remetente só tem a garantia de que, a certa altura, sua mensagem será inserida na fila do receptor.
• Nenhuma garantia é dada sobre quando, nem ao menos se a mensagem será realmente lida, o que é totalmente determinado pelo comportamento do receptor
28
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Modelo de enfileiramento de mensagens
29
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Modelo de enfileiramento de mensagens
30
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Brokers de Mensagens
• Uma importante área da aplicação de sistemas de enfileiramento é a integração de novas aplicações em um único e coerente sistema distribuído
• Desta forma as mensagens necessitam ter o mesmo formato para entendimento das aplicações
• Problema: para cada aplicação adicionada ao sistema que requer um formato diferente de mensagem, cada receptor potencial terá de ser ajustado de modo a produzir aquele formato
31
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Brokers de Mensagens
• Solução possível: formato comum, como é feito nos protocolos tradicionais de redes. Mas os processos que usam este formato devem ser muito em comum
• A abordagem geral é aprender a viver com diferentes formatos e tentar providenciar os meios para simplificar ao máximo as conversões
32
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Brokers de Mensagens
• Solução: uso de nós especiais, conhecidos como brokers de mensagens, para manipular as conversões de mensagens.
33
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Brokers de Mensagens
34
- Comunicação Remota
Comunicação orientada a mensagem
Comunicação persistente orientada a mensagem Exemplo de
sistema de
enfileiramento de
mensagens
35
- Comunicação Remota
Comunicação orientada a fluxo
Visto até agora: troca de informações completas e independentes. Ex.: RPC e troca de mensagens
Comunicação característica que não importa em que ponto particular do tempo a comunicação ocorra
Independente da comunicação ser muito lenta ou muito rápida
36
- Comunicação Remota
Comunicação orientada a fluxo
Em comunicação orientada a fluxo a temporização desempenha um papel crucial
Questão: quais são as facilidades que um sistema distribuído deve oferecer para trocar informações dependentes de tempo como fluxos de áudio e vídeo
37
- Comunicação Remota
Comunicação orientada a fluxo
Aplicação
file transfere-mail
Web documentsreal-time áudio/vídeo
stored áudio/videojogos interativos
Perdas
sem perdassem perdastolerantetolerante
tolerantetolerante
Banda
elásticaelásticaelásticaaúdio: 5 Kb-1 Mbvídeo:10 Kb-5 Mbigual à anterior kbps
Sensível ao atraso
nãonãonãosim, décimo de segundo
sim, alguns segundossim, décimo de segundo
Requisitos de transporte de aplicações comuns
38
- Comunicação Remota
Comunicação orientada a fluxo
Para capturar troca de informações dependentes do tempo, em geral os sistemas distribuídos fornecem suporte para fluxos de dados
Fluxo de dados: sequencia de de unidades de dados
Para capturar aspectos de temporização, costuma-se fazer uma distinção entre diferentes modos de trasmissão
39
- Comunicação Remota
Comunicação orientada a fluxo
Transmissão assíncrona: os itens de dados são transmitidos um após o outro mas não há restrição alguma de temporização. Ex.: fluxos discretos (textos, imagens estáticas)
Transmissão síncrona: há uma traso fim-a-fim máximo definido para cada unidade em um fluxo de dados. Não importa se uma unidade de dados for transferida com muito mais rapidez do que o atraso máximo tolerado
Transmissão isócrona: é necessário que as unidades de dados sejam transferidas no tempo certo. Deve haver atraso máximo e mínimo (variações de atraso delimitado). Interessante para sistemas distribuídos de multimídia
40
- Comunicação Remota
Comunicação orientada a fluxo
Fluxos (transmissão isócrona) podem ser simples ou complexos
Fluxo simples: consiste em uma única sequência de dados
Fluxo complexo: consiste em vários fluxos simples relacionados. Ex.: transmissão de filme, composto por um fluxo simples de vídeo, dois fluxos simples para transmitir o som estéreo e um fluxo contendo uma legenda. Tudo de forma síncronizada
42
- Comunicação Remota
Comunicação orientada a fluxo
Essa arquitetura geral revela algumas questões importantes:
Compressão dos dados de modo a reduzir o armazenamento requerido e em especial a capacidade da rede
Controle da qualidade da transmissão e questões de sincronização
43
- Comunicação Remota
Comunicação orientada a fluxo
Fluxos e qualidade de serviço Requisitos de temporização geralmente são expressos
como requisitos de Qualidade de Serviço (Quality of Service – QoS)
Assegura que as relações temporais em um fluxo possam ser preservadas
Refere-se à pontualidade, ao volume e à confiabilidade
44
- Comunicação Remota
Comunicação orientada a fluxo
Fluxos e qualidade de serviço Propriedades importantes
• A taxa de bits requerida à qual os dados devem ser transportados
• O máximo atraso até o estabelecimento de uma sessão, isto é, quando uma aplicação pode começar a enviar dados
• O máximo atraso fim-a-fim, isto é, quanto tempo levará até que uma unidade de dados chegue a um receptor
• A máxima variância de atraso, ou vibração• O máximo atraso de viagem de ida e volta
45
- Comunicação Remota
Comunicação orientada a fluxo
Fluxos e qualidade de serviço Dado que o sistema subjacente oferece apenas um serviço de
entrega de melhor esforço, um sistema distribuído pode tentar ocultar o máximo possível a falta de qualidade de serviço
Serviços diferenciados: diferenciar classe de dados (marcação de pacotes)
• Repasse acelerado: prioridade no repasse• Repasse garantido: dividido em quatro subclasses aliadas a
três modos de descartar pacotes se a rede ficar congestionada. Diferencia pacotes sensíveis ao tempo de pacotes não críticos
46
- Comunicação Remota
Comunicação orientada a fluxo
Fluxos e qualidade de serviço Outra solução é fazer uso de buffer
47
- Comunicação Remota
Comunicação orientada a fluxo
Sincronização de fluxos Manter relações temporais entre fluxos Duas formas de sincronização
• Sincronização entre fluxo discreto e contínuos. Ex.: Exibição de slides na Web
• Sincronização entre fluxos contínuos. Ex.: reprodução de vídeo e áudio, sincronização de lábios (lipsync)
48
- Comunicação Remota
Comunicação orientada a fluxo
Ex. sistema orientado ao fluxo (TV Digital)
Transporte dos dados
49
- Comunicação Remota
Comunicação orientada a fluxo
Ex. sistema orientado ao fluxo (TV Digital)
Visão geral do sistema de TV Digital
50
- Comunicação Remota
Comunicação multicast
Estabelecer caminhos de comunicação para a disseminação de informações
Várias soluções, por muitos anos, no nível de transporte e de redes
Envolve imenso esforço de gerenciamento, em muitos casos, exigia intervenção humanal
Com o advento do peer-to-peer e do gerenciamento estruturado de sobreposição, ficou mais fácil estabelecer caminhos de comunicação
51
- Comunicação Remota
Comunicação multicast
Multicasting de nível de aplicação Objetivo: organização dos nós através de uma rede de
sobreposição para disseminar informações entre os nós desta rede
Problema: os dados podem cruzar vários enlaces físicos e o roteamento das mensagens dentro da rede de sobreposição pode não ser o ótimo em comparação com o roteamento da rede física
Duas soluções:• Organização em árvore → possui um único caminho• Organização em malha → cada nó terá vários vizinhos
52
- Comunicação Remota
Comunicação multicast
Multicasting de nível de aplicação Ex. Árvore Multicast Chord
• Nó inicia sessão multicast gerando um identificador (mid) aleatório
• Consulta o nó responsável pelo identificador [succ(mid)]• Promoção do nó responsável pelo mid como raiz da
árvore• Para se juntar a árvore um nó P executa operação
lookup(mid)• Esta msg será roteada até ao nó raiz
53
- Comunicação Remota
Comunicação multicast
Multicasting de nível de aplicação Ex. Árvore Multicast Chord
• Caso a msg passe pelo nó Q e este não pertence a árvore, o nó se tornará um repassador para o grupo, enquanto o nó Q envia a msg de pesquisa até a raiz
• P se tornará filho de Q• Caso o nó Q já pertence a árvore este será um
repassador e não terá a necessidade de enviar a pesquisa de associação para o nó raiz
• O nó P, que requisitou a associação a árvore multicast, por definição, também é repassador
54
- Comunicação Remota
Comunicação multicast
Multicasting de nível de aplicação Ex. Árvore Multicast Chord
• A partir deste momento a comunicação é feita através do envio de uma msg multicast em direção à raiz da árvore simplesmente executando o comando lookup(mid), após a qual a msg pode ser enviada ao longo da árvore
55
- Comunicação Remota
Comunicação multicast
Multicasting de nível de aplicação Construção da sobreposição
• Embora construir uma árvore seja um processo relativamente fácil, construir uma árvore eficiente pode ser uma histório bem diferente
56
- Comunicação Remota
Comunicação multicast
Multicasting de nível de aplicação Construção da sobreposição
• Qualidade da árvore multicast medida em três parâmetros:– Estresse de enlace: definido por enlace e conta
quantas vezes um pacote cruza o mesmo enlace– Alongamento: razão entre o atraso entre dois nós na
sobreposição e o atraso que esses dois nós sofreriam na rede subjacente
– Custo da árvore: está relacionado com a minimização dos custos agregados de enlaces. Ex.: encontrar a spanning tree mínima
57
- Comunicação Remota
Comunicação multicast
Disseminação de dados baseada em gossiping Disseminar informações através de um
comportamento epidêmico Espalhar informações em larga escala semelhante ao
espalhamento de enfermidades através de pessoas Objetivo: propagar informações rapidamente entre
entre um grande conjunto de nós usando somente informações locais, sem a necessidade de um componente central que coordena a disseminação de informações
58
- Comunicação Remota
Comunicação multicast
Disseminação de dados baseada em gossiping Um nó que é parte do sistema distribuído é
denominado:• Infectado: se contiver dados que está disposto
a espalhar para os outros nós• Suscetível: nó que ainda não tenha visto esses
dados• Removido: nó atualizado que não está disposto
ou capacitado para propagar os dados
59
- Comunicação Remota
Comunicação multicast
Disseminação de dados baseada em gossiping Um modelo popular de propagação é o da
antientropia onde um nó P escolhe aleatoriamente um outro nó Q e na sequencia troca atualizações com este último
• Três abordagens para a troca de atualizações:– P só troca suas próprias atualizações com Q– P só recebe novas atualizações de Q– P e Q enviam atualizações um ao outro
60
- Comunicação Remota
Comunicação multicast
Disseminação de dados baseada em gossiping Funcionamento do gossiping
• Se o nó P acabou de ser atualizado com o item de dado x, ele contata um outro nó arbitrário Q e tenta enviar a atualização a Q
• Contudo, é possível uqe Q já tenha sido atualizado por um outro nó
• Nesse caso, P pode perder o interesse em levar adiante a propagação da atualização, tornando-se nó removido
• Gossiping mostrou ser um modo excelente de espalhar notícias rapidamente, porém não garante que todos os nós realmente serão atualizados
Combinar antientropia com gossiping resolve o problema
61
- Comunicação Remota
Comunicação multicast
Disseminação de dados baseada em gossiping Remoção dos dados
• Algoritmos epidêmicos são bons para propagar atualizações
• Contudo propagar remoção de um item de dado é difícil
• Remover um item significa destruição de todas as informações deste item. Com isso o nó que destruiu este item pode receber cópia antiga deste e interpretar como uma atualização
• Solução: propagação de certificados de óbito
62
- Comunicação Remota
Comunicação multicast (camada de Rede)
Entrega de pacotes a apenas um subgrupo na rede
Alguns questionamentos: Como identificar os destinatários de um pacote (subgrupo)? Como um grupo multicast começa e termina? Como os nós da rede interagem para entregar um
datagrama de grupo a todos os membros desse grupo? Como é escolhido o endereço?
Para a Internet as respostas para estas perguntas envolve o Protocolo de Gerenciamento de Grupo da Internet (IGMP)
63
- Comunicação Remota
Comunicação multicast (camada de Rede)
Entrega de pacotes aos membros do grupo multicast
64
- Comunicação Remota
Comunicação multicast (camada de Rede)
Internet Group Management Protocol Oferece meios para um nó informar ao roteador
conectado a ele que uma aplicação que está funcionando nele quer se juntar a um grupo específico
Como a intereção do IGMP é limitada a um nó e ao roteador diretamente conectado, é necessário um protocolo responsável pelo roteamento dos datagramas aos destinos finais
Assim, o serviço de grupo na camada de rede da Internet consiste em dois componentes complementares: IGMP e protocolos de roteamento de grupo
66
- Comunicação Remota
Comunicação multicast (camada de Rede)
Funcionamento IGMP O roteador envia msg membership_query a uma rede local para
todos os nós desta rede para determinar o conjunto de todos os grupos aos quais se ligaram os nós naquela interface.
Os nós respondem com uma msg membership_report. Esta msg pode ser gerada pelo nó sem esperar por uma msg membership_query caso a aplicação deste nó queira se juntar a um determinado grupo multicast
Uma msg leave_group (opcional) pode ser enviada por um nó ao roteador informando seu desligamento no grupo. Mas de tempo em tempo caso um nó não responda a uma msg membership_query enviada pelo roteador, este deduz que o nó não pertence mais ao grupo
67
- Comunicação Remota
Comunicação multicast (camada de Rede)
Algoritmos de roteamento para grupos Duas abordagens adotadas para determinar a
árvore de roteamento para um grupo• Árvore compartilhada → baseado na construção
de uma árvore que inclui todos os roteadores de borda cujos nós a ele conectados pertencem ao grupo (spanning tree)
• Árvore baseada na origem → construção de uma árvore de roteamento para um grupo para cada origem do grupo