cap. 04 – comunicação - faculdade de computaçãofaina/bcc_crs/gsi028-2014-1s/dl/ds-ch04.pdf ·...
TRANSCRIPT
Luís F. Faina - 2013 Pg. 1/100
Cap. 04 – Comunicação
4.1 – Fundamentos4.1.1 Protocolo em Camadas
4.1.2 Tipos de Comunicação
4.2 – Remote Procedure Call4.2.1 Operação Básica RPC
4.2.2 Passando Parâmetros
4.2.3 RPC Assíncrono
4.3 – Comunicação Orientada a Mensagem4.3.1 Comunicação Transiente
4.3.2 Comunicação Persistente
Luís F. Faina - 2013 Pg. 2/100
Cap. 03 – Processos
4.3 - … …
4.4 – Comunicação Orientada por Fluxo4.4.1 Suporte para Mídia Contínua
4.4.2 Fluxos e Qualidade de Serviço
4.4.3 Sincronização de Mídia
4.5 – Comunicação Multicast4.5.1 Multicasting no Nível de Aplicação
4.5.2 Migração e Recursos Locais
4.5.3 Disseminação de Dados baseado no Gossip
Luís F. Faina - 2013 Pg. 3/100
Referências Bibliográficas
● Andrew S. Tanenbaum; Maarten van Steen - Distributed Systems: Principles and Paradigms, Prentice-Hall, 2007, ISBN-10: 0132392275, ISBN-13: 9780132392273
… Lectures dos autores Andrew S. Tanenbaum e Maarteen van Steen (“www.cs.vu.nl” e “www.distributed-systems.net/”)
● George Coulouris; Jean Dollimore; Tim Kindberg – Sistemas Distribuídos: Conceitos e Projeto, Bookman, 4th Edition, 2007, ISBN 9788560031498
● Notas de Aula do Prof. Ricardo Anido do Instituto de Computação (IC) da UNICAMP - www.ic.unicamp.br/~ranido/
Luís F. Faina - 2013 Pg. 4/100
4 - Comunicação
4 - Comunicação
● comunicação – coração de todo e qualquer sistema distribuído, assim não faz sentido estudarmos sistemas distribuídos sem examinar em detalhes como máquinas trocam informações.
● ... comunicação em sistemas distribuídos é baseada na de troca de mensagens oferecida pela rede subjacente.
● Sistemas Distribuídos Modernos frequentemente são compostos de milhares de máquinas ou até mesmo milhões de processos dispersos na rede com comunicação não confiável !!
● ... a menos que tais primitivas de comunicação sejam substi- tuídas por algo melhor, o desenvolvimento de aplicações distribuídas de larga escala tornar-se-á extremamente difícil.
Luís F. Faina - 2013 Pg. 5/100
4 Comunicação – 4.1 Fundamentos
4.1 - Fundamentos
● ... antes de discutirmos o tópico principal deste capítulo, iremos recapitular algumas questões fundamentais relacionadas aos protocolos de comunicação em rede.
● fato - toda comunicação em sistemas distribuídos tem por base o envio e recepção de mensagens no nível mais baixo da pilha de comunicação em razão da ausência de memória compartilhada;
● ... embora esta idéia básica pareça simples, os processos que desejam trocar informações devem acordar a forma como os bits/bytes serão enviados – protocolo.
● e.g., A envia informações escritas em Francês e codificadas em Código EBCDIC, enquanto B aguarda as informações em Inglês e codificada em Código ASCII. ??!!
Luís F. Faina - 2013 Pg. 6/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● EBCDIC “Extended Binary Coded Decimal Interchange Code” -codificação de caracteres 8 bits descendente do Código BCD (6 bits) criado pela IBM no início dos anos 1960 e usado no IBM 360.
● ... nas transmissões de dados é necessário utilizar muito caracteres de controle para manipulação das mensagens e realização de funções.
Luís F. Faina - 2013 Pg. 7/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● EBCDIC “Extended Binary Coded Decimal Interchange Code”
Luís F. Faina - 2013 Pg. 8/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● Equivalência ASCII e EBCDIC:
Luís F. Faina - 2013 Pg. 9/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● Equivalência ASCII e EBCDIC:
Luís F. Faina - 2013 Pg. 10/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● Equivalência ASCII e EBCDIC:
Luís F. Faina - 2013 Pg. 11/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● Equivalência ASCII e EBCDIC:
Luís F. Faina - 2013 Pg. 12/100
4 Comunicação – 4.1 Fundamentos
… 4.1 - Fundamentos
● Equivalência ASCII e EBCDIC:
Luís F. Faina - 2013 Pg. 13/100
4 Comunicação – 4.1 Fundamentos
4.1.1 – Protocolos em Camadas
● ... processos que desejam trocar informações devem acordar na forma como os bits/bytes serão enviados.
● Modelo OSI – propõe um modelo de referência que claramente identifica os vários níveis/camadas bem como nomes e serviços que devem oferecer;
● ... OSI (Open System Interconnection) - foi proposto para permitir que sistemas abertos se comuniquem;
● “open systems” - sistema preparado para comunicar-se com outro sistema aberto utilizando as regras padrões que governam o formato, conteúdo e significado das mensagens;
● ... tais regras são formalizadas e chamadas de “protocols”.
Luís F. Faina - 2013 Pg. 14/100
4 Comunicação – 4.1 Fundamentos
… 4.1.1 – Protocolos em Camadas
● No Modelo OSI (Fig. 4.1) - comunicação é dividida em 07 camadas, cada qual responsável por serviços específicos.
Luís F. Faina - 2013 Pg. 15/100
4 Comunicação – 4.1 Fundamentos
… 4.1.1 – Protocolos em Camadas
● ... tais regras são formalizadas e chamadas de “protocols”.
● Obs.: ... para permitir que computadores troquem informações pela rede, é necessário acordar quais protocolos usar.
● Podemos distinguir 02 tipos gerais de protocolos:
● “connection oriented - necessário estabelecer uma conexão e possivel- ̈mente negociar que protocolo será utilizado e, somente depois, efetuar a troca de mensagens pela conexão.
● “connectionless” - não é necessário estabelecimento de conexão, assim o transmissor simplesmente transmite a mensagem quando estiver pronto.
Luís F. Faina - 2013 Pg. 16/100
4 Comunicação – 4.1 Fundamentos
… 4.1.1 – Protocolos em Camadas
● ... formato de uma típica mensagem na rede (Fig. 4.2).
Luís F. Faina - 2013 Pg. 17/100
4 Comunicação – 4.1 Fundamentos
… 4.1.1 – Protocolos em Camadas
● “protocol suite” ou “protocol stack” - coleção de protocolos usados em um sistema em particular;
● ... é importante distinguir o modelo de referência dos protocolos comumente utilizados nos sistemas de comunicação disponíveis.
● Nas próximas seções, discutiremos cada uma das Camadas do Modelo OSI, iniciando pelas camadas inferiores:
● Protocolos das Camadas de Nível Baixo
● Protocolos de Transporte
● Protocolos de Camadas Superiores
● Protocolos de Middleware
Luís F. Faina - 2013 Pg. 18/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
Protocolos das Camadas de Baixo Nível
● “physical layer” - contém a especificação e implementação dos bits e da transmissão entre transmissor e receptor;
● “data link layer” - prescreve a transmissão como uma série de bits no frame para permitir o controle de fluxo e de erros;
● “network layer” - descreve como pacotes em uma rede de computadores serão roteados e/ou encaminhados.
● Obs.: ... para muitos sistemas distribuídos, a interface da camada mais baixa é aquele da camada de rede - “network layer”.
Luís F. Faina - 2013 Pg. 19/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
… Protocolos de Transporte
● “transport layer” - provê as facilidades de comunicação que possibilitam a troca de mensagens entre os processos – base para a maioria dos sistemas distribuídos;
● ... último elemento do que podemos chamar “basic network protocol stack” no sentido que contempla todos os serviços que não são contemplados na camada de rede mas que são necessários para a concepção das aplicações de rede.
● Protocolos da Internet (Padrões “de facto”):
● Transmission Control Protocol (TCP) – orientado a conexão, confiável e comunicação orientada por “stream” (fluxo de bytes);
● User Datagram Protocol (UDP) – comunicação de não confiável;
● Real-time Transport Protocol (RTP) – especifica formato de pacotes para tempo real sem prover mecanismo que garanta a entrega do dado.
Luís F. Faina - 2013 Pg. 20/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
… Protocolos das Camadas Superiores
● Modelo OSI propõe 03 camadas sobre a Camada de Transporte, mas na prática somente a Camada de Aplicação é usada (Arquitetura Internet ou TCP/IP);
● “session layer” - versão melhorada da camada de transporte tem por função oferecer controle de sessão e facilidades de sincronização;
● “presentation layer” - se preocupa com a representação canônica dos dados bem como com a estruturação dos mesmos;
● “application layer” - aplicação que provê um ou uma coleção de serviços.
● Modelo OSI – originalmente proposto para acomodar um coleção de aplicações padrões de rede tais como email, transferência de arquivo e emulação de terminal;
● ... !? ou seja, deste ponto de vista todos os sistemas distribuídos são virtualmente apenas aplicações de rede ?!
Luís F. Faina - 2013 Pg. 21/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
… Protocolos de Middleware
● “middleware protocol” - proposto para prover serviços comuns e protocolos a serem utilizados por diferentes aplicações;
● ... é uma aplicação que está presente em muitas camadas de aplicação, mas que contém protocolos de propósito geral que garantem suas próprias camadas.
● Obs.: ... necessário distinguir entre protocolos de comunicação de alto nível de protocolos para suportar os serviços de middleware.
● e.g., “authentication protocols” - não deveriam ser contemplados na aplicação propriamente dita mas podem ser integrados ao “middleware” com um serviço de propósito geral.
Luís F. Faina - 2013 Pg. 22/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
… Protocolos de Middleware
● “middleware protocols” - devem suportar serviços de comunicação de alto nível de forma transparente;
● e.g., serviços de comunicação de alto nível para estabelecer e sincronizar streams para transferência de dados em tempo real.
● e.g., processo que invoca um procedimento ou um objeto em um processo remoto com o máximo de transparência.
● solução – manter os protocolos de middleware nas camadas superiores de modo que possam oferecer diferentes protocolos (sintonizáveis) através de uma interface única.
● ... esta abordagem pressupõe uma pequena adaptação do modelo de referência para comunicação (Fig. 4.3).
Luís F. Faina - 2013 Pg. 23/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
… Protocolos de Middleware
● “middleware protocols” - suporte para serviços de comuni- cação de alto nível de forma transparente:
● “data (un)marshaling” - necessário para sistemas integrados;
● “naming protocols” - facilitar o compartilhamento de recursos;
● “security protocols” - para segurança de comunicação;
● “scaling mechanisms” - para replicação e salvaguarda.
● Obs.: ... assim, o que resta são protocolos verdadeiramente específicos e dependentes da aplicação.
Luís F. Faina - 2013 Pg. 24/100
4 Comunicação – 4.1 Fundamentos – 4.1.1 Protocolos em Camadas
… Protocolos de Middleware
● Fig. 4.3 – Adaptive Reference Model
Luís F. Faina - 2013 Pg. 25/100
4 Comunicação – 4.1 Fundamentos
4.1.2 Tipos de Comunicação
● Para melhor entender as várias alternativas de comunicação que o middleware pode ofererecer para as aplicações, podemos ver o middleware como um serviço adicional no modelo cliente/servidor.
● … e.g., considere um sistema de correio eletrônico, cujo núcleo do sistema de entrega de mensagens pode ser visto como um serviço de comunicação do “middleware”;
● … cliente é representado pelo agente do usuário que permite ao mesmo a composição, envio e recepção de emails;
● … um agente transmissor repassa este email para o sistema de entrega de mensagens – responsável pela entrega da mensagem ao sistema de entrega de mensagens do destinatário.
Luís F. Faina - 2013 Pg. 26/100
4 Comunicação – 4.1 Fundamentos
… 4.1.2 Tipos de Comunicação
● Para melhor entender as várias alternativas de comunicação que o middleware pode ofererecer para as aplicações, podemos ver o middleware como um serviço adicional no modelo cliente/servidor.
Luís F. Faina - 2013 Pg. 27/100
4 Comunicação – 4.1 Fundamentos
… 4.1.2 Tipos de Comunicação
● “transient communication” - servidor de comunicação descarta mensagens quando não podem ser entregues no próximo servidor ou mesmo no solicitante da requisição.
● “persistent communication” - mensagem é armazenada no servidor de comunicação pelo tempo que for necessário de modo que a entrega da mensagem seja garantida.
Luís F. Faina - 2013 Pg. 28/100
4 Comunicação – 4.1 Fundamentos
… 4.1.2 Tipos de Comunicação
● “assynchronous communication” - remetente continua o seu processamento imediatamente após submeter a mensagem;
● “synchronous communication” - remetente é bloqueado até que sua requisição seja enviada/processada pelo receptor.
Luís F. Faina - 2013 Pg. 29/100
4 Comunicação – 4.1 Fundamentos
… 4.1.2 Tipos de Comunicação
● “assynchronous communication” - remetente continua o seu processamento imediatamente após submeter a mensagem;
● “synchronous communication” - remetente é bloqueado até que sua requisição seja enviada ou processada pelo receptor.
● ... há vários pontos nos quais a sincronização é completada:
● “request submission” - remetente é bloqueado até o middleware notificá-lo que irá assumir o controle da transmissão da requisição;
● “request delivery” - remetente é bloqueado até que a requisição seja entregue ao receptor, mas ainda assim cabe ao middleware notificar;
● “request processing” - remetente é bloqueado até que a requisição seja recebida e processada pelo receptor – middleware notifica remetente.
Luís F. Faina - 2013 Pg. 30/100
4 Comunicação – 4.2 Remote Procedure Call
4.2 Remote Procedure Call
● Birrell & Nelson (1984) – quando um processo em uma máquina “A” chama um procedimento em um processo em uma máquina “B”, processo “A” é suspenso e a chamada é executada em “B”;
● ... informações podem ser passadas do remetente para o desti- natário como parâmetros assim como do destinatário para o remetente como resultado do procedimento.
● ... este método é conhecido como Remote Procedure Call (RPC).
Luís F. Faina - 2013 Pg. 31/100
4 Comunicação – 4.2 Remote Procedure Call
4.2.1 Operação Básica do RPC
● Para entender como o RPC funciona é importante primeiro conhecer como uma chamada de procedimento local funciona;
● e.g., count = read( fd, buf, nbytes);
● fd – inteiro que indica o descritor do arquivo;
● buf – array de caracteres no qual dados são armazenados;
● nbytes – inteiro que informa quantos bytes devem ser lidos;
● count – inteiro que informa quanto bytes foram lidos.
● ... após executar o procedimento, armazena-se o valor a ser retornado em um registrador, remove-se o endereço de retorno e transfere-se o controle de volta para o remetente.
Luís F. Faina - 2013 Pg. 32/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● ... durante uma chamada de procedimento local, a figura ilustra a pilha antes da chamada (Fig. a) e a pilha após a chamada ser iniciada - enquanto o procedimento está ativo (Fig. b).
Luís F. Faina - 2013 Pg. 33/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● ... alguns pontos dignos de nota - parâmetros podem ser passados por “call-by-value” (e.g., “fd” e “nbytes”) ou “call-by-reference” (e.g., “buf” é uma referência e não valor).
● ... embora não presente na Ling. C, parâmetros podem ser passados pelo mecanismo “call-by-copy/restore” - ... remetente copia uma variável para a pilha no início do procedimento;
● ... ao final do procedimento o remetente copia novamente a variável de volta já sobrescrita pela execução do procedimento.
● [Wikipedia] - “call-by-copy-restore” is a special case of “call-by- reference” where the provided reference is unique to the caller.
Luís F. Faina - 2013 Pg. 34/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● [Wikipedia] - … this variant has gained attention in multiprocessing contexts and Remote Procedure Call (RPC);
● … if a parameter to a function call is a reference that might be accessible by another thread of execution, its contents may be copied to a new reference that is not;
● … when the function call returns, the updated contents of this new reference are copied back to the original reference ("restored").
● Obs.: em muitas situações esta forma propicia o mesmo resultado que a chamada por referência (“call-by-reference”), mas em algumas situações a semântica pode ser diferente.
Luís F. Faina - 2013 Pg. 35/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● Idéia Básica do RPC – fazer com que a Chamada RPC se pareça tanto quanto possível com uma “chamada local”, ou seja, queremos uma chamada remota que seja transparente.
● RPC – comunicação entre remetente e destinatário pode ser escondida utilizando o mecanismo de chamada de procedimento.
Luís F. Faina - 2013 Pg. 36/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● Idéia Básica do RPC – fazer com que a Chamada RPC se pareça tanto quanto possível com uma “chamada local”, ou seja, queremos uma chamada remota que seja transparente.
● RPC – cabe ao sistema operacional empacotar os dados em uma mensagem e enviá-la para o servidor e aguardar a resposta.
Luís F. Faina - 2013 Pg. 37/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● Resumidamente, Chamada RPC ocorre da seguinte forma:
● procedimento cliente invoca o “stub” do cliente;
● “stub” cliente compõe uma mensagem e invoca o SO do cliente;
● SO do cliente envia a mensagem para o SO remoto;
● SO remoto entrega a mensagem para o “stub” do servidor;
● “stub” do servidor desempacota os dados e invoca a chamada no servidor;
● servidor processa a chamada e retorna valor ao “stub”;
● “stub” do servidor empacota a mensagem e chama o SO do servidor;
● SO do servidor envia a mensagem para o SO do cliente;
● SO do cliente recebe a mensagem e entrega ao “stub” cliente;
● “stub” cliente desempacota a mensagem e repassa ao cliente.
Luís F. Faina - 2013 Pg. 38/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.1 Operação Básica do RPC
● O efeito na rede de todos estes passos é a conversão da chamada local pelo “stub” cliente do procedimento cliente para uma chamada remota no servidor;
● Obs.: nem o cliente e nem o servidor estão cientes dos passos intermediários ou da existência da rede na comunicação.
● ... cabe ao sistema operacional empacotar os dados em uma mensagem e enviá-la para o servidor e aguardar a resposta, portanto, para o cliente a chamada de procedimento é local;
● “client stub” - recebe os parâmetros, empacota-os em uma mensagem e envia para o “stub servidor”;
● ... para o servidor vale o mesmo que para o cliente.
Luís F. Faina - 2013 Pg. 39/100
4 Comunicação – 4.2 Remote Procedure Call
4.2.2 Passagem de Parâmetros no RPC
● “parameter marshaling / unmarshaling” - empacotamento / desempacotamento dos parâmetros / valor em uma mensagem;
● e.g., seja o procedimento remoto add( i, j) que recebe 02 parâme- tros “i” e “j” e retorna a soma aritmétrica como resultado.
Luís F. Faina - 2013 Pg. 40/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.2 Passagem de Parâmetros no RPC
● ... na verdade há mais do que empacotamento de parâmetros em uma mensagem - “parameter marshaling”:
● máquinas cliente e servidor podem trabalhar com diferentes represen- tações de dados (e.g., ordenação de bytes na memória);
● empacotar parâmetros significa transformar um valor em uma sequência de bytes, ou seja, pressupõe ordenação de bytes e parâmetros;
● cliente e servidor precisam concordar com a codificação dos dados, ou seja, representação dos dados básicos e complexos;
● cliente e servidor precisam acordar as regras e procedimentos que governam a troca de informações (protocolo).
Luís F. Faina - 2013 Pg. 41/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.2 Passagem de Parâmetros no RPC
● e.g., ordenação de bytes na memória >> Fig. (a) – mensagem original no Pentium; Fig. (b) – mensagem após ser recebida na SPARC; Fig. (c) – mensagem invertida.
Luís F. Faina - 2013 Pg. 42/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.2 Passagem de Parâmetros no RPC
● “parameter marshaling” - máquinas cliente e servidor podem trabalhar com diferentes representações de dados (e.g., ordenação de bytes na memória);
1 main() {
2 int a = 0x12345678;
3 unsigned char *c = (unsigned char*)(&a);
4 if( *c == 0x78 ) printf("little-endian\n");
5 else printf("big-endian\n");
6 }
Luís F. Faina - 2013 Pg. 43/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.2 Passagem de Parâmetros no RPC
● Passagem de Parâmetros RPC – algumas suposições:
● semântica “copy in / copy out” - enquanto o procedimento é executado, nada pode ser assumido sobre os valores dos parâmetros;
● parâmetros – todos os dados a serem tratados deverão ser passados como parâmetros, ou seja, não há passagem de referência de dados.
● conclusão: transparência de acesso completa não é possível !?
● Nota: ... mecanismo de passagem por referência remota melhora a transparência de acesso em razão:
● referência remota oferece acesso unificado a dados remotos;
● referência remota pode ser passada como parâmetro no RPC.
Luís F. Faina - 2013 Pg. 44/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.2 Passagem de Parâmetros no RPC
● ... ambos os lados no contexto RPC devem acordar no uso do mesmo protocolo, ou o RCP não irá funcionar;
● e.g., considere o procedimento “foobar( char x, float y, int z[5] )” e a regra de formação da mensagem que descreve como os parâmetros são passados entre os “stubs” cliente e servidor.
● ... definir o formato da mensagem é um dos aspectos do RCP, mas não é suficiente apenas definir o formato ?!
● ... necessário também que o cliente e servidor acordem a representação de dados simples (e.g., inteiro, caracter, etc.) e complexos de modo que as mensagens não sejam interpretadas de forma ambígua.
● ... uma vez que o protocolo tenha sido definido, “stubs” cliente e servidor podem ser implementados.
Luís F. Faina - 2013 Pg. 45/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.2 Passagem de Parâmetros no RPC
● ... ambos os lados no contexto RPC devem acordar no uso do mesmo protocolo, ou o RCP não irá funcionar.
foobar( char x; float y; int z[5] ) {
…
}
Luís F. Faina - 2013 Pg. 46/100
4 Comunicação – 4.2 Remote Procedure Call
4.2.3 RPC Assíncrono
● Chamada RPC Tradicional – cliente invoca procedimento remoto e é bloqueado até a resposta retornar;
● ... este comportamento “request / replay” não é necessário quando não há o que retornar ao remetente.
Luís F. Faina - 2013 Pg. 47/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.3 RPC Assíncrono
● Interação Cliente/Servidor usando RPC Assíncrono – cliente continua após invocar uma requisição RPC, ou seja, servidor envia imediatamente uma resposta de volta ao cliente.
Luís F. Faina - 2013 Pg. 48/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.3 RPC Assíncrono
● RPC Assíncrono também é útil quando o cliente não está pronto para receber a resposta de uma requisição;
● e.g., cliente deseja obter endereços de rede de um conjunto de hosts que espera contactar, mas enquanto esta requisição é processada o cliente está realizando outras tarefas.
Luís F. Faina - 2013 Pg. 49/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.3 RPC Assíncrono
● Combinação de 02 Chamadas RPCs Assíncronas é também referenciado como “Deferred Synchronous RPC”;
● Obs.: Em muitos casos há variações do RPC Assíncrono:
● ... quando o Cliente não aguarda o reconhecimento do Servidor quanto ao aceite da requisição anteriormente encaminhada;
● ... nestes casos são chamadas “One-Way RPCs”.
Luís F. Faina - 2013 Pg. 50/100
4 Comunicação – 4.2 Remote Procedure Call
… 4.2.3 RPC Assíncrono
Luís F. Faina - 2013 Pg. 51/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
4.3 Comunicação Orientada a Mensagem
● Mecanismos como RPC e ROI (“Remote Object Invocation”) contribuem para esconder a comunicação em sist. distribuídos pois proporcionam a transparência de acesso;
● “access transparency” - “hides differences in data representation and invocation mechanisms”;
● ... mas ambos não são apropriados, pois em ambos a suposição é de que cliente e servidor estão ativos simultaneamente.
● ... na verdade a razão de ambos não serem apropriados está no fato de na comunicação síncrona alguns tipos de transparência não são passíveis de serem alcançados.
Luís F. Faina - 2013 Pg. 52/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
4.3.1 Comunicação Transiente
● Muitas aplicações em sistemas distribuídos são concebidos direta- mente sobre um simples modelo orientado por mensagem;
● ... que normalmente são suportadas pela camada de transporte para permitir que programadores utilizem os protocolos através de um conjunto simples de primitivas.
● e.g., “sockets interface” introduzida em 1970 pelo “Berkeley UNIX”
● “socket” - ponto final de comunicação através do qual uma aplicação escreve dados que serão enviados pela camada subjacente e do qual podem receber dados para serem lidos;
● ... criar um ponto final de comunicação significa que o sistema operacional de rede reserva recursos para acomodar o envio e recepção de mensagens para um protocolo específico.
Luís F. Faina - 2013 Pg. 53/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.1 Comunicação Transiente
● Primitivas do Socket para o TCP:
● “socket” – create a new communication end point;
● “bind” – attach a local address to a socket;
● “listen” – announce willingness to accept communication;
● “accept” – block caller until a connection request arrives;
● “connect” – actively attempt to establish a connection;
● “send” – send some data over the connection;
● “receive” – receive some data over the connection;
● “close” – release the connection
● ... servidores geralmente executam as 04 primeiras primitivas, iniciando pela invocação da primitiva “socket”;
Luís F. Faina - 2013 Pg. 54/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.1 Comunicação Transiente
● Padrão geral seguido por cliente e servidor para comunicação orientado por conexão utilizando “sockets”:
Luís F. Faina - 2013 Pg. 55/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.1 Comunicação Transiente
● No entanto, “sockets” apresentam algumas desvantagens:
● suportam apenas 02 primitivas (“send” e “receive”), ou seja, se situam em um nível de abstração distante da semântica do usuário;
● são projetados para trabalhar sobre redes com protocolos de propósito geral como Arquitetura TCP/IP (TCP ou UDP).
● “sockets” não são adequados para protocolos proprietários desenvolvidos para interconexão de redes de alta velocidade.
● Obs.: ... muitas redes de interconexão e multicomputadores de alto desempenho são disponibilizados com bibliotecas de protocolos proprietários tornando incompatível o uso de “sockets”.
Luís F. Faina - 2013 Pg. 56/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.1 Comunicação Transiente
● Necessidade de independência de hardware e plataforma conduz a definição de um padrão para passagem de mensagem conven- cionalmente chamado de “Message-Passing Interface” – MPI;
● ... MPI é projetado para aplicações paralelas, assim é adaptado para comunicação transiente, ou seja, a mensagem é armaze- nada somente se remetente e receptor estão executando.
● ... MPI assume que a comunicação esta restrita a um grupos de processos com identificação para cada grupo e processo;
● ... par (“groupID”, “processID”) identifica univocamente a fonte e o destino da mensagem e é usado no lugar do endereço da camada de transporte (e.g., “port” no TCP).
Luís F. Faina - 2013 Pg. 57/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.1 Comunicação Transiente
● Primitivas mais intuitivas para “Message-Passing Interface”:
● MPI_bsend – append outgoing message to a local send buffer;
● MPI_send – send a message and wait until copied to local ou remote buffer;
● MPI_ssend – send a message and wait until receipt starts;
● MPI_sendrecv – send a message and wait for reply;
● MPI_isend – pass reference to outgoing message, and continue;
● MPI_issend – pass reference to outgoing message, and wait until receipt starts;
● MPI_recv – receive a messge; block if there is none;
● MPI_irecv – check if there is an incoming message, but do not block;
● Obs.: ... como pode ser constatado há o suporte para comunicação transiente assíncrona - “MPI_bsend”.
Luís F. Faina - 2013 Pg. 58/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
4.3.2 Comunicação Persistente
● essência - oferecer capacidade de armazenamento de mensa- gens sem exigir que o remetente e receptor estejam ativos durante a transmissão da mensagem;
● ... tais sistemas provêem suporte para comunicação persistente assíncrona, ou seja, “message queuing systems” ou apenas “Message-Oriented Middleware” (MOM).
● ... discutiremos este tópico apresentando:
● modelo de fila de mensagens - “message-queuing model”;
● arquitetura geral de sistema - “message-queuing”;
● interceptadores de mensagens - “message brokers”
Luís F. Faina - 2013 Pg. 59/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● “Message-Queuing Model” - aplicações se comunicam inserindo mensagens em filas específicas sem a necessidade de que ambos estejam simultaneamente sendo executados.
● ... um aspecto importante de sistemas de fila de mensagens é que o remetente tem a garantia de que a mensagem enviada foi apenas inserida na fila do receptor.
● ... esta semântica possibilita a comunicação fracamente acoplada no tempo, assim, mensagens podem ser enviadas para a fila do receptor sem que ele esteja executando;
● ... igualmente, não é necessário que o remetente esteja execu- tando no momento em que o receptor recolhe a mensagem.
Luís F. Faina - 2013 Pg. 60/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● Fig. 4.17 - 04 combinações de comunicação fracamente acoplada no tempo utilizando fila de mensagens - “message queuing”.
Luís F. Faina - 2013 Pg. 61/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● Interface básica (Fig. 4.18) em um sistema “message-queuing”:
● “put” – invocada pelo servidor para passar uma mensagem para o sistema subjacente que será adicionado a uma fila específica;
● “get” – chamada bloqueiante através da qual um processo com autorização remove a mensagem pendente em uma fila específica; processo é bloqueado somente se a fila estiver vazia;
● “poll” – variante do “get” na qual um processo simplesmente continua se a fila estiver vazia ou se uma mensagem específica não é encontrada;
● “notify” – função de “callback” é invocada quando uma mensagem é colocada em uma fila específica
Luís F. Faina - 2013 Pg. 62/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● “General Architeture” - vejamos agora com mais detalhes um sistema geral/genérico de fila de mensagens.
● ... uma das restrições é que mensagens sejam colocadas em filas locais do remetente - “source queue”, ou seja, filas na mesma máquina ou no pior caso na mesma rede;
● ... igualmente, mensagens podem ser lidas pelo receptor apenas de filas locais - “destination queue”;
● ... naturalmente que mensagens colocadas em um fila fonte - “source queue” e endereçadas a uma fila destino - “destination queue” são tranferidas de alguma forma pela rede.
Luís F. Faina - 2013 Pg. 63/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● Fig 4.19 – Relacionamento entre endereçamento no nível de fila e endereçamento no nível de rede;
● ... para transferir uma mensagem é necessário mapear filas para endereços de rede como mostrado abaixo.
Luís F. Faina - 2013 Pg. 64/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● “queue managers” - interagem diretamente com a aplicação que por sua vez envia e recebe mensagens;
● ... no entanto, há gerenciadores especiais que operam como roteadores (“routers”) ou retransmissores (“relays”).
● Retransmissores são convenientes pelo fato de que em muitos sistemas de fila de mensagens não há um serviço de nomes disponível que possa manter o mapeamento “queue-to-location”;
● ... neste contexto a topologia da rede de filas é estática e cada gerenciador mantém a cópia do mapeamento “queue-to-location”.
● ... não é necessário dizer que o sistema de filas de mensagens em larga escala conduz a problemas de gerenciamento de rede.
Luís F. Faina - 2013 Pg. 65/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● Fig. 4.20 – Organizaçao Geral de um Sistema de Fila de Mensagens funcionando como um roteador.
Luís F. Faina - 2013 Pg. 66/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● ... uma área importante de aplicação de sistemas de fila de mensagens é a integração de aplicações legadas com aplicações existentes para sistemas distribuídos de informação;
● “Message Brokers” - responsável pela conversão de mensagens recebidas para outros formatos de outras aplicações como resultado da integração de novas aplicações.
● ... surge assim a necessidade de conversores/corretores de formatos de mensagens que possibilitem esta integração.
● Obs.: Neste contexto, a concordância em um único formato de mensagens não funciona bem em “message-queuing systems”.
Luís F. Faina - 2013 Pg. 67/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● Fig. 4.21 – Organização geral para um Conversor de Mensagens em um Sistema de Filas de Mensagens.
Luís F. Faina - 2013 Pg. 68/100
4 Comunicação – 4.3 Comunicação Orientada a Mensagem
… 4.3.2 Comunicação Persistente
● “message broker” - pode ser tão simples como um conversor de mensagens para um formato esperado pelo destinatário;
● ... mas também pode atuar como um “gateway” no nível de aplicação, de modo a coordenar a conversão entre 02 (duas) diferentes aplicações de banco de dados.
● Obs.: ... essência do “message broker” repousa no repositório de regras e programas capazes de transformar uma mensagem do tipo T1 em uma mensagem do tipo T2;
● ... maior desafio é a definição das regras e dos programas que realizam a conversão segundo as regras.
Luís F. Faina - 2013 Pg. 69/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
4.4 Comunicação Orientada por Fluxo
● Nesta seção trataremos das facilidades em sistemas distribuídos que possibilitam suporte à troca de informações contínuas e dependentes do tempo tais como áudio e vídeo;
● e.g., considere um stream de áudio amostrado em 44100 Hz.
● ... para reproduzí-lo é necessário que as amostras de áudio sejam repetidas na ordem e na cadência que foram geradas, ou seja, exatamente a cada 1 / 44100 segundo = 22,68 micro segundos;
● ... reprodução das amostras de áudio em um outra taxa diferente daquela de amostragem irá produzir versões incorretas.
Luís F. Faina - 2013 Pg. 70/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
4.4.1 Suporte para Mídia Contínua
● No contexto de “continuous media” as relações temporais entre os diferentes tipos de dados são fundamentais para a interpretação correta do que cada dado representa;
● e.g., considere um sinal de vídeo amostrado a uma taxa de um quadro a cada 30 ou 40 ms (T - Período);
● ... reprodução correta requer apresentação das imagens na ordem correta bem como em uma frequência constante de 1/T quadros por segundo => (25 a 33,33 quadros por segundo)
● Já no contexto de “discrete media” as relações temporais entre os diferentes tipos de dados não são fundamentais.
● e.g., texto, imagens, gráficos, código objeto, código executável.
Luís F. Faina - 2013 Pg. 71/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.1 Suporte para Mídia Contínua
● “data streams” - mecanismo pelo qual sistemas distribuídos capturam a sequência de unidades de dados, seja “continuous media” ou “discrete media”;
● e.g., UNIX “pipe” ou conexão TCP são típicos exemplos “streams” de dados discretos (“discrete media”) como uma sequência de bytes.
● “Streams” podem ser agrupadas em simples ou complexos:
● “simple stream” - consiste somente de um única sequência de dados;
● “complex stream” - consiste de várias “simple streams”, ou “substreams”, relacionadas e dependentes entre si no tempo.
Luís F. Faina - 2013 Pg. 72/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.1 Suporte para Mídia Contínua
● Pelo fato do tempo ser crucial em “streams” de dados contínuos, é necessário distinguir o modo de transmissão:
● “assynchronous transmission mode” - dados são transmitidos um após o outro sem restrição quanto quando são transmitidos;
● “synchronous transmission mode” - há um máximo de “delay” fim-a-fim definido para cada unidade de dado no “stream”;
● “isochrounous transmission mode” - necessário transmitir as unidades de dados em tempo, ou seja, há um máximo e um mínimo na variação do atraso fim-a-fim (“bounded jitter”).
Luís F. Faina - 2013 Pg. 73/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.1 Suporte para Mídia Contínua
● Fig. 4.26 - ... descreve uma proposta de arquitetura para dados de multimídia armazenados em streams na rede.
● ... necessidade de compressão dos dados para exigir menos no armazenamento bem como da capacidade da rede.
Luís F. Faina - 2013 Pg. 74/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
4.4.2 Fluxos e Qualidade de Serviço
● Requisitos de Qualidade de Serviço – descrevem o que é neces- sário pelo sistema distribuído ou de rede subjacente para garantir relações temporais ou até mesmo não funcionais;
● … “requisitos não-funcionais” [wikipedia] - relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade e tecnologias envolvidas.
● ... para fluxos de dados estes requisitos estão principalmente relacionados ao tempo de entrega, volume e confiabilidade.
Luís F. Faina - 2013 Pg. 75/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.2 Fluxos e Qualidade de Serviço
● Do ponto de vista da aplicação, tudo se resume na especificação de algumas propriedades importantes:
● taxa de bits na qual os dados serão transportados;
● máximo atraso até a sessão ser estabelecida;
● máximo atraso fim-a-fim, ou seja, tempo decorrido para que a unidade de dado seja entregue ao receptor.
● máxima variância de atraso, ou “jitter”;
● máximo atraso de ida e volta.
● ... entretanto, quando se trata de comunicação orientada por fluxo sobre a pilha TCP/IP, nos deparamos com um serviço extrema- mente simples e de melhor esforço – IP.
Luís F. Faina - 2013 Pg. 76/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.2 Fluxos e Qualidade de Serviço
● Portanto, cabe ao Sistema Distribuído esconder tanto quanto possível a falta de qualidade de serviço;
● ... como colocado anteriormente e para corrigir o cenário, há ferramentas no nível de rede que provêem classe de dados diferenciadas conhecidas como “differentiated services”;
● ... o “host” remetente pode marcar os pacotes a serem enviados como pertencentes a uma das 03 classes de serviço:
● “expedited forwarding” - pacotes devem ser encaminhados para o roteador com absoluta prioridade – não há descarte;
● “assured forwarding” - acomoda 04 subclasses dentro das quais pacotes podem ser descartados de três maneiras diferentes em caso de congestionamento da rede – há descarte;
● “best effort” - encaminhamento padrão sem nenhuma garantia.
Luís F. Faina - 2013 Pg. 77/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.2 Fluxos e Qualidade de Serviço
● Além das soluções no nível de rede, sistemas distribuídos podem auxiliar na obtenção de dados para os destinatários, e.g., uso de “buffers” para reduzir o “jitter” (Fig. 4.27).
Luís F. Faina - 2013 Pg. 78/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.2 Fluxos e Qualidade de Serviço
● Além da “bufferização”, técnicas de correção de erros se aplicam:
● técnica na qual o envio de pacotes se dá de modo que “k” de “n” pacotes recebidos são suficientes para reconstruir “k” pacotes corretos;
● ... o problema ocorre quando um simples pacote contém quadros de áudio e vídeo, pois, se o pacote se perder o receptor poderá perceber lacunas na apresentação do fluxo de dados;
● ... técnicas como entrelaçamento de quadros de áudio e vídeo podem ser usados para minimizar este problema (Fig. 4.28).
Luís F. Faina - 2013 Pg. 79/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.2 Fluxos e Qualidade de Serviço
● Fig. 4.28 – ... efeito da perda de pacote(s) em transmissão não entrelaçada e transmissão entrelaçada.
Luís F. Faina - 2013 Pg. 80/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
4.4.3 Sincronização de Fluxo
● e.g. “hamming code” - … em uma mensagem de “n” bits, inclui-se “k” bits de verificação => “n + k” bits na mensagem;
● … para “k” bits de verificação, temos: “n = 2^k -1”, assim o nro máximo de bits na mensagem será “n = 2^k – k – 1”;
● … e.g., para “n = 4” e “k = 3” (bits de paridade) => 7 bits na msg; para “n = 11” e “k = 4” (bits de paridade) => 15 bits na msg.
Luís F. Faina - 2013 Pg. 81/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
4.4.3 Sincronização de Fluxo
● “synchronization of streams” - responsável por manter as relações temporais entre fluxos de dados (streams);
● ... forma mais simples de sincronização é entre fluxo de dados discretos e fluxo de dados contínuos;
● e.g., conjunto de “slides” de uma dada apresentação e o fluxo de dados de áudio para cada um dos slides;
● ... neste exemplo os “slides” constituem o fluxo de dados discretos e o áudio o fluxo de dados contínuo.
Luís F. Faina - 2013 Pg. 82/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.3 Sincronização de Fluxo
● “lip synchronization” - tipo de sincronização mais exigente para fluxos de dados contínuos, e.g., áudio e vídeo:
● quadros de vídeo – devem ser apresentados a uma taxa >= 25Hz;
● amostras de áudio - Padrão NTSC (National Television System Committee) é 29,97 Hz, assim, podemos agrupar amostras em unidades lógicas que durassem tanto quanto a apresentação de um quadro de vídeo (33 mseg);
● ... assim, com frequência de amostragem de 44100 Hz, o tamanho da unidade de dados de áudio será de até 1470 amostras, ou 2940 bytes considerando que cada amostra tenha 16 bits.
● ... como discutido, a idéia é a de agrupar os fluxos de dados que compõem o fluxo como um todo de modo que em um pacote de dados se acomode a sincronização.
Luís F. Faina - 2013 Pg. 83/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.3 Sincronização de Fluxo
● Fig. 4.29 – ... princípio da sincronização explícita no nível de unidade de dados - responsabilidade da aplicação.
Luís F. Faina - 2013 Pg. 84/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.3 Sincronização de Fluxo
● e.g., considere um fluxo de vídeo contendo imagens de baixa qualidade (320 x 240 pixels codificado em 1 byte/pixel);
● ... teremos (328 * 240 * 1) = 76.800 bytes para cada quadro e assumindo que foram geradas a 30 Hz, cada quadro de vídeo será apresentado a um taxa de 33 milisegundos;
● ... para o fluxo de áudio assume-se que cada amostra contenha 11760 bytes, cada qual correspondendo a 33 mseg de áudio;
● ... se o processo for capaz de processar 2,5 MB/s, a sincroni- zação de lábios poderá ser alcançada simplesmente lendo um quadro de áudio e de vídeo a cada 33 mseg.
● “problema” – aplicação é responsável pela implementação da sincronização pois as facilidades são de baixo nível.
Luís F. Faina - 2013 Pg. 85/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.3 Sincronização de Fluxo
● “multimedia middleware” - oferece uma coleção de interfaces para controle de fluxos de áudio e vídeo, incluindo interfaces para controle de dispositivos tais como monitor, câmeras e microfone;
● ... para cada dispositivo e fluxo há interfaces de alto nível, incluindo interfaces para notificar a aplicação quando da ocorrência de certos eventos.
● ... para distribuição de mecanismos de sincronização, uma prática comum consiste em prover informação de sincronização implícita multiplexada com os fluxos de dados em um único fluxo.
Luís F. Faina - 2013 Pg. 86/100
4 Comunicação – 4.4 Comunicação Orientada por Fluxo
… 4.4.3 Sincronização de Fluxo
● Fig. 4.30 – ... princípio da sincronização suportada por interfaces de alto nível
Luís F. Faina - 2013 Pg. 87/100
4 Comunicação – 4.5 Comunicação Multicast
4.5 Comunicação Multicast
● “multicast communication” - permite que um processo envie a mesma mensagem para um grupo de processos;
● ... por muitos anos este tópico pertenceu ao domínio dos protoco- los de rede, onde soluções na camada de rede e de transporte foram propostas e implementadas;
● ... no entanto, este tópico vem tomando espaço como tópico em comunicação em sistemas distribuídos.
Luís F. Faina - 2013 Pg. 88/100
4 Comunicação – 4.5 Comunicação Multicast
4.5.1 Multicast no Nível de Aplicação
● “idéia” - nós são organizados em uma rede de sobreposição utilizada para disseminar a informação para os membros;
● ... roteadores da rede não estão envolvidos nesta rede, assim o roteamento de mensagens na rede não é ótimo em comparação com o roteamento na camada de rede.
● Assim, o aspecto de projeto é essencial no suporte a multicast na aplicação é a construção da rede de sobreposição:
● nós se organizam em uma árvore de modo que tenhamos um único caminho entre cada par de nós;
● nós se organizam de modo que tenham múltiplos vizinhos - “mesh network” assim, em geral existem múltiplos caminhos entre cada par de nós.
Luís F. Faina - 2013 Pg. 89/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.1 Multicast no Nível de Aplicação
● Fig. 4.31 - Normalmente quando se organiza um conjunto de nós em uma rede de sobreposição, os nós não levam em conta métri- cas de performance para estabelecer a rede de sobreposição.
Luís F. Faina - 2013 Pg. 90/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.1 Multicast no Nível de Aplicação
● e.g., considere o nó A enviando uma mensagem “multicast” para os outros nós (B, C e D) como mostrado na Fig. 4.31.
● ... quando A envia a mensagem para os outros nós, os “links” <B, Rb), <Ra,Rb>, <Rc,Rd>, <D,Rd> serão percorridos 02 vezes;
● ... rede de sobreposição poderia ser mais eficiente se substituirmos o “link” <B,D> por um de <A,C>;
● ... esta configuração irá economizar trajetos duplos nos “links” <Ra,Rb> e <Rc,Rd> tornando a rede sobreposição mais eficiente.
Luís F. Faina - 2013 Pg. 91/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.1 Multicast no Nível de Aplicação
● … assim, qualidade de uma árvore “multicast” no nível de aplicação pode ser medida através de 03 métricas: “link stress ”; “stretch” e o custo da árvore - “tree cost”.
● “Link Stress” - definido por “link”, contabiliza com que frequência um pacote cruza o mesmo “link”;
● ... “link stress” maior que 1 significa que um pacote pode ser encaminhado por 02 conexões diferentes, mas parte destas conexões correspondem ao mesmo “link” físico (Fig. 4.31).
● “Tree Cost” - métrica global associada à minimização do custo para “links” agregados, ou seja, árvores que possibilitem disse- minar a informação para todos os nós ao custo mínimo.
Luís F. Faina - 2013 Pg. 92/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.1 Multicast no Nível de Aplicação
● “Stretch” - mede a razão no atraso entre nós na rede de sobre- posição e o atraso nos mesmos nós na rede subjacente;
● e.g., mensagens de B para C seguem a rota <B,Rb>, <Rb,Ra>, <Ra,Rc>, <Rc,C> há um custo total de 59 “units”/;
● ... mensagens podem ser roteadas na camada subjacente por <B,Rb>, <Rb,Rd>, <Rd,Rc>, <Rc,C> a um custo de 47 “units”;
● ... “stretch” = 59/49 = 1,255
● Assim, ao se construir um rede de sobreposição é importante minimizar o “stretch” agregado/global ou a média dos valores obtidos para todos os pares de nós.
Luís F. Faina - 2013 Pg. 93/100
4 Comunicação – 4.5 Comunicação Multicast
4.5.2 Disseminação de Dados (Gossip-Based)
● “gossip-based dissemination information” - técnica de disseminação de informação que usa protocolos epidêmicos;
● ... protocolos epidêmicos propagam rapidamente a informação entre uma grande coleção de nós usando informação local, ou seja, não há um elemento central que coordena a propagação.
● Para explicar os princípios gerais, assumiremos que todas as atualizações para itens de dados são iniciadas por um único nó;
● ... neste contexto, iremos simplesmente evitar concorrência de operações de escrita entre os vários nós.
Luís F. Faina - 2013 Pg. 94/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● “epidemic algorithms” - baseados na teoria de epidemias, estudam a propagação de doenças infecciosas;
● ... quando aplicados a sistemas distribuídos, são responsáveis pela programação de informações para o maior número de nós (se possível todos os nós) tão rápido quanto possível.
● Terminologia para nós em Sistema Distribuídos:
● “infected node” - nó que mantém dados que ele espera propagar para outros nós do sistema distribuído;
● “susceptible node” - nó que ainda não possui estes dados;
● “removed node” - nó que não mais dissemina ou não é capaz de propagar os seus dados para outros nós.
Luís F. Faina - 2013 Pg. 95/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● Modelo popular de propagação é o modelo de anti-entropia no qual P pega outro nó Q aleatoriamente e na sequência troca dados com Q segundo 03 abordagens diferentes:
● P somente empurra suas atualizações para Q - “push approach”;
● P somente puxa novas atualizações de Q - “pull approach”
● P e Q enviam atualizações um para o outro - “push-pull approach”.
● Interessante avaliar as abordagens de propagação e disseminção em cenários onde muitos nós estão infectados, ou seja, o resultado das abordagens “push-based” e “pull-based”.
Luís F. Faina - 2013 Pg. 96/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● “push-based approach” - não é um boa escolha quando as atualizações são disseminadas rapidamente;
● ... neste cenário temos muitos nós infectados, assim a probabilidade de cada nó infectado selecionar um nó suscetível é relativamente baixa;
● ... probabilidade de um nó suscetível permanecer suscetível por um longo período é grande em razão de ele não ser selecionado.
● “pull-based approach” - funciona melhor quando vários nós estão infectados pois o gatilho das atualizações é dos nós suscetíveis.
Luís F. Faina - 2013 Pg. 97/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● Pode ser mostrado que o nro. de rodadas para propagar uma simples atualização para todos os nós será O(log N) rodadas, onde N é o número de nós no sistema;
● ... isto indica que a propagação é rápida, mas acima de tudo escalável - cada dobra de nós acrescenta-se uma rodada.
● “Rumor Spreading” ou “gossiping” -
● funciona de modo que um nó P, que acabou de ser infectado, contacta um nó arbitrário Q e tenta repassar suas atualizações;
● ... mas se Q já está infectado, P perde o interesse em propagar sua atualização para outros, ou seja, se torna um nó removido.
● ... “gossiping” - excelente para rapidamente propagar notícias, embora não garante que todos os nós sejam de fato infectados.
Luís F. Faina - 2013 Pg. 98/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● Pode ser mostrado que a fração de nós “s” que não serão infectadas ao participarem de sistema epidêmico é:
● s = e ^ [ - (k + 1) * (1 – s) ]
● Fig. 4.32 mostra o ln(s) como um função de “k”, ou seja, para “k” = 4 e ln(s) = -4.97, então “s” é menor que 0.007, ou seja, 0,7% dos nós permanecem suscetíveis a uma atualização.
● ... uma das vantagens de algoritmos epidêmicos é a escalabili- dade, devido ao fato do nro de sincronização entre os processos ser relativamente baixa com outros métodos de propagação.
Luís F. Faina - 2013 Pg. 99/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● Fig. 4.32 mostra o ln(s) como um função de k, ou seja, para k = 4 e ln(s) = -4.97, então s é menor que 0.007, ou seja, 0,7% dos nóspermanecem suscetíveis a uma atualização.
Luís F. Faina - 2013 Pg. 100/100
4 Comunicação – 4.5 Comunicação Multicast
… 4.5.2 Disseminação de Dados (Gossip-Based)
● “directional gossiping” - nós que estão conectados a outros poucos nós são contactados com uma probabilidade maior com base na suposição que formam uma ponte para partes remotas;
● ... por se constituirem em uma “bridge” para partes remotas dos sistema, devem ser contactados tão rápido quanto possível.
● ... esta abordagem traz a tona uma questão importante conside- rada por muitas soluções epidêmicas, na qual um nó pode aleatoriamente selecionar um outro nó para com ele “fofocar”;
● ... isto implica que cada nó deve conhecer cada membro, mas em sistemas grandes esta suposição não pode ser mantida.