Cap. 04 – Comunicação - Faculdade de Computaçãofaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch04.pdf ·...

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


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


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/

http://www.cs.vu.nl/


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.


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. ??!!



… 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.




● EBCDIC “Extended Binary Coded Decimal Interchange Code”




● Equivalência ASCII e EBCDIC:

Luís F. Faina - 2013 Pg. 10/100




Luís F. Faina - 2013 Pg. 11/100




Luís F. Faina - 2013 Pg. 12/100




Luís F. Faina - 2013 Pg. 13/100


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.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



● ... 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



● ... formato de uma típica mensagem na rede (Fig. 4.2).

Luís F. Faina - 2013 Pg. 17/100



● “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


… 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


… 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


… 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



● “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



● “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



● Fig. 4.3 – Adaptive Reference Model

Luís F. Faina - 2013 Pg. 25/100


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.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



● “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



● “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



● “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.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.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



● ... 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



● [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



● 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



● 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



● 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



● 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.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.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



● 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



● “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



● 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



● ... 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



● ... 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.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.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



● 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



● 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



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.3.1 Comunicação Transiente

● Muitas aplicações em sistemas distribuídos são concebidos diretamente 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.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



● 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



● 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



● 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 é armazenada 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



● 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.3.2 Comunicação Persistente

● essência - oferecer capacidade de armazenamento de mensagens 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.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 executando no momento em que o receptor recolhe a mensagem.

Luís F. Faina - 2013 Pg. 60/100



● 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



● 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



● “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



● 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



● “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



● 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



● ... 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



● 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



● “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.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.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



● 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



● 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.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.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 extremamente simples e de melhor esforço – IP.

Luís F. Faina - 2013 Pg. 76/100



● 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



● 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



● 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



● 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.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.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.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



● 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



● 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



● “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



● 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 protocolos 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.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.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



● 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



● … 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 disseminar a informação para todos os nós ao custo mínimo.

Luís F. Faina - 2013 Pg. 92/100



● “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.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.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



● 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



● “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



● 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



● 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



● 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



● “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.

Cap. 04 – Comunicação - Faculdade de Computaçãofaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch04.pdf ·...

Documents

Transcript of Cap. 04 – Comunicação - Faculdade de Computaçãofaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch04.pdf ·...