Resumo do Capítulo 4 – Comunicação.

Prévia do material em texto

Resumo do Capítulo 4 – Comunicação.
Introdução – Comunicação.
Comunicação entre processos está no coração de todo sistema distribuído. É sempre baseada em troca de mensagem de baixo nível como a oferecida pela rede subjacente. Expressar comunicação por meio de troca de mensagem é mais difícil do que usar primitivas baseadas em memória compartilhada.
Sistemas distribuídos modernos frequentemente consistem em milhares ou até milhões de processos espalhados por uma rede cuja comunicação não é confiável, como a internet. A menos que o recurso de comunicação oferecidos pelas redes de computadores de computadores sejam distribuídos por alguma outra coisa, o desenvolvimento de aplicações distribuídas em grande escala é extremamente difícil.
Começaremos discutindo as regras as quais os processos comunicantes devem obedecer, conhecidos como protocolos, e nos concentraremos na estruturação desses protocolos na forma de camadas, seção 1 (um) deste resumo.
Nosso primeiro modelo para comunicação em sistemas distribuídos é a chamada de procedimento remoto (RPC). Uma RPC visa a ocultar grande parte das complexidades da troca de mensagens e é ideal para aplicações cliente-servidor. Será abordado no 2° (segundo) tópico deste resumo.
Em muitas aplicações distribuídas, a comunicação não segue o padrão bastante restrito da interação cliente-servidor. Nesses casos, verificamos que é mais adequado pensar em termos de mensagens. Contudo, em muitos aspectos, os recursos de comunicação de baixo nível das redes de computadores não são adequados devido a falta de transparência de distribuição. 
Middleware orientado a mensagem (MOM) é um assunto importante o suficiente para dedicarmos a seção 3 só para ele.
Na seção 4 (quatro) será discutido o Fluxo, suporte para comunicação de mídia, sequencia continua de mensagens, sujeito a várias restrições de temporização.
Por fim, os recursos Multicast, surgiram novas e agradáveis soluções para disseminação de dados. Daremos particular atenção a esse assunto na seção 5 (cinco) deste resumo e na seção 6 (seis) a conclusão.
Protocolos em Camadas
Devido à ausência de memória compartilhada, toda comunicação em sistemas distribuídos é baseada em envio e recebimento de mensagens. Quando o processo A quer se comunicar com o processo B, em primeiro lugar ele monta uma mensagem em seu próprio espaço de endereço. Depois, executa uma chamada de sistema que faz com que o sistema operacional envie a mensagem pela rede até B. embora essa ideia básica pareça bem simples, para evitar o caos, A e B tem de concordar com o significado dos bits que são enviados.
Vários acordos diferentes são necessários em uma variedade de níveis que vão de detalhes de baixo nível de transmissão de bits a detalhes de alto nível sobre como a informação deve ser expressa.
Para ficar mais fácil lidar com os vários níveis e questões envolvidas em comunicação, a International Organization for Standardization (ISO) desenvolveu um modelo de referência que identifica claramente os vários níveis envolvidos, dá-lhes nomes padronizados e indica qual nível deve fazer tal serviços. Esse modelo é denominado de modelo de referência para interconexão de sistemas abertos, ou simplesmente, modelo OSI.
O modelo OSI é projetado para permitir que sistemas abertos se comuniquem. Um sistema aberto é o que está preparado para se comunicar qualquer outro sistema aberto usando regras padronizadas que regem o formato, o conteúdo e o significado das mensagens recebidas. Se um grupo de computadores quiser se comunicar por uma rede, todos eles têm de concordar com os protocolos (regras formalizadas) que serão utilizados.
Protocolos Orientados a Conexão, antes de trocar dados, o remetente e o receptor primeiro estabelecem explicitamente uma conexão e possivelmente negociam o protocolo que usarão. Após concluírem, devem liberar a conexão. Quando o protocolo é sem conexão, não é preciso estabelecer nada antecipadamente. O remetente apenas transmite a primeira mensagem quando estiver pronta.
No modelo OSI, a comunicação é dividida em até sete níveis ou camadas, Figura 4.1. Cada camada lida com um aspecto especifico da comunicação. Desse modo, o problema pode ser dividido em porções gerenciáveis, a cada uma delas pode ser resolvida independentemente das outras. Cada camada fornece uma interface para a camada que está acima dela a interface consiste em um conjunto de operações que, juntas, definem o serviço que a camada está prepara para oferecer a seus usuários.
O conjunto de protocolos utilizados em determinado sistema é denominado suíte de protocolos ou pilhas de protocolos. É importante distinguir um modelo de referência de seus protocolos propriamente ditos.
Protocolos de níveis mais baixos
Camada Física
Se ocupa de transmitir os bits. Quantos volts usar para 0 e 1, quantos bits por segundo podem ser enviados e se a transmissão pode ocorrer em ambas as direções simultaneamente são questões fundamentais. Assim, como o tamanho e a forma do conector de rede (plug), bem como o número de pinos e o significado de cada um.
Trata da padronização das interfaces elétrica, mecânica e de sinalização, de modo que, quando uma máquina enviar um bit 0, este seja realmente recebido como um bit 0, e não como um bit 1. Foram desenvolvidos muitos padrões de camada física.
A camada física se limita a enviar bits. Contanto que não ocorra nenhum erro. Entretanto, redes de comunicação reais estão sujeitas a erros, por isso é necessário algum mecanismo para detecta-los e corrigir. Protocolos são dependentes do meio de transmissão do link.
Camada de Enlace
Agrupo os bits em unidades, as vezes denominadas quadros (frames), e providencia para que cada quadro seja corretamente recebido. Colocando um padrão especial de bits no início e no final de cada frame para marca-lo, bem como calcula uma soma de verificação somando todos os bits presentes no quadro de certa maneira. Quando o quadro chega, o receptor calcula novamente a soma de verificação dos dados e a comparara com a soma de verificação que acompanha o quadro. Se as duas combinarem, o frame é considerado correto e é aceito. Se as somas não combinarem, o receptor solicita ao remetente que retransmita o frame. Os frames recebem uma sequência de números no cabeçalho de modo que todos possam reconhecer qual é qual.
Camada de Rede
Uma rede de longa distância consiste em um grande número de maquinas, cada qual com algumas linhas para outras maquinas, cada qual com algumas linhas para outras maquinas. A questão de como escolher o melhor caminho é denominado roteamento e é, em essência, a tarefa primaria da camada de rede.
O problema é complicado pelo o fato de que a rota mais curta nem sempre é a melhor. O que realmente importa é o atraso total em determinada rota o qual, por sua vez, está relacionado com a quantidade de tráfego e com o número de mensagens enfileiradas para transmissão nas várias linhas. Assim, o atraso pode mudar ao longo do tempo. Alguns algoritmos de roteamento tentam se adaptar a cargas variáveis, enquanto outros se contentam em tomar decisões com base em medias de longo prazo.
Protocolo de Internet
É o protocolo de rede de mais ampla utilização do momento (Internet Protocol - IP), o protocolo de rede sem conexão que faz parte da pilha de protocolos de Internet. Um Pacote – termo técnico para uma mensagem de camada de rede – IP pode ser enviado sem nenhuma preparação antecipada. Cada pacote IP é roteado até seu destinatário, independentemente de todos os outros. Nenhum caminho interno é selecionado, tampouco lembrado.
Protocolo de Transporte
Camada De Transporte
Forma a última parte do que poderia ser denominada pilha básica de protocolos de rede. Em outras palavras, a camada de transporte transforma a rede subjacente em algo que um desenvolvedor de aplicação pode usar.
Pacotes podem ser perdidos no caminho entre o remetente e o receptor. Embora algumas aplicações possam manipular sua própria recuperação de erros, outras preferem uma conexão confiável.O trabalho da camada de transporte é fornecer esse serviço. A ideia é que a camada de aplicação deva ser capaz de entregar uma mensagem à camada de transporte com a expectativa de que ela será entregue sem se perder.
Conexão de transporte confiável
Podem ser construídas em cima de serviços de redes orientados a conexão e sem conexão. Cabe ao software de camada de transporte colocar tudo em ordem para manter a ilusão de que uma conexão de transporte é como um grande tubo.
Protocolo de transporte da Internet – TCP.
A combinação TCP/IP agora é usada como um padrão de facto para a combinação em rede. A pilha de protocolos da internet também suporta um protocolo sem conexão denominado protocolo universal de datagramas – UDP, que é em essência, apenas o IP com algumas pequenas adições. Programas de usuários que não precisam de um protocolo orientado a conexão normalmente usam UDP.
Protocolos De Transportes Em Tempo Real - RTP.
O RTP é um ambiente operacional no sentido de que especifica formatos de pacote para dados em tempo real sem fornecer os mecanismos propriamente dito para garantir a entrega de dados. Ademais, ele especifica um protocolo para monitorar e controlar transferência de dados de pacotes RTP.
Protocolos de Níveis Mais Altos
Acima da camada de transporte, o OSI distinguiu três camadas adicionais. Na pratica, somente a camada de aplicação é usada. Na verdade, na pilha de protocolos da Internet, tudo o que está acima da camada foi agrupado.
Camada de Sessão 
É em essência uma versão aprimorada da camada de transporte. Ela proporciona controle de diálogo para monitorar qual é a parte que está falando no momento considerado e fornece facilidades de sincronização. Essas ultimas são uteis para permitir que usuários insiram pontos de verificação em transferências longas de modo que, na eventualidade de uma queda, basta voltar até o último ponto de verificação, em vez de até o início. Poucas aplicações estão interessadas na camada de sessão e é raro que ela seja suportada. Ela não está presente nem mesmo na pilha de protocolos da Internet. Entretanto, no contexto de desenvolvimento de soluções de middleware, o conceito de uma sessão e seus protocolos relacionados mostrou ser bastante relevante, em especial na definição de protocolos de comunicação de níveis mais altos.
Camada de Apresentação
Se preocupa com o significado dos bits. A maioria das mensagens não consiste em correntes aleatórias de bits, mas em informações mais estruturadas como nomes de pessoas, endereços, quantias de dinheiro e assim por diante. Nesta camada é possível definir registros que contem campos como esses e então fazer com que o remetente avise o receptor que a mensagem contém determinado registro em certo formato. Isso facilita a comunicação entre maquinas que tenham representações internas diferentes.
Camada de Aplicação
A intenção original da camada de aplicação OSI era conter um conjunto de aplicações padronizadas de rede, como as de correio eletrônico, transferência de arquivos e emulação de terminal. Mas, agora, ela se tornou o repositório para todas as aplicações e protocolos que, de uma maneira ou de outra, não se ajustam a uma das camadas subjacentes. Da perspectiva do modelo de referencia OSI, praticamente todos os sistemas distribuídos são apenas aplicações.
Protocolos FTP e HTTP
Protocolo De Transferência De Arquivos FTP - (Internet) – define um protocolo para transferir arquivos entre uma máquina cliente e uma máquina servidora. O protocolo não deve ser confundido com o programa ftp, que é uma aplicação de usuário final para transferir arquivos e que também implementa o FTP da Internet.
Protocolo de transferência de hipertexto HTTP – é projetado para gerenciar e manipular remotamente a transferência de páginas na Web. O protocolo é implementado por aplicações como browsers Web e servidores Web. Contudo, hoje o HTTP também é usado por sistemas que não estão intrinsecamente vinculados à Web.
Também há muitos protocolos de uso geral que são uteis para muitas aplicações, mas que não podem ser qualificados como protocolos de transporte. Em muitos casos, esses protocolos entram na categoria de protocolos de middleware, que discutiremos a seguir.
Protocolos de Middleware (camada de middleware)
Camada de software que está situada logicamente entre uma camada de nível mais alto, mais que contém muitos protocolos de uso geral que justificam suas próprias camadas, independentemente de outras aplicações mais especificas. Pode-se fazer uma distinção entre protocolos de comunicação de alto nível e protocolos para estabelecer vários serviços de middleware.
Protocolos De Autenticação E De Autorização
Não estão fortemente vinculados a nenhuma aplicação especifica; em vez disso, podem ser integrados a um sistema de middleware como um serviço geral.
Os de Autorização, concedem a usuários e processos autenticados permissão de acesso somente a recursos para os quais tenham autorização tendem a ter uma natureza geral, independente da aplicação.
Protocolos De Comprometimento
Estabelecem que, em um grupo de processos, ou todos os processos executam determinada operação ou a operação não é executada de jeito nenhum. Denominado de atomicidade, tem ampla aplicação em transações.
Protocolo Distribuído De Bloqueio 
Um recurso pode ser protegido contra acesso simultâneo por um conjunto de processos que são distribuídos por várias maquinas. Os de comunicação de middleware suportam serviços de comunicação de alto nível.
Comunicação De Middleware
Alguns dos protocolos de comunicação de middleware poderiam, com igual propriedade, pertencer a camada de transporte, mas talvez haja razoes especificas para mantê-los em um nível mais alto. Por exemplo, serviços Multicasting confiáveis que garantem escalabilidade podem ser implementados somente se os requisitos da aplicação forem levados em conta. Por consequência, um sistema de middleware pode oferecer diferentes protocolos (adaptáveis), cada um, por sua vez, usando diferentes protocolos de transporte, mas oferecendo uma única interface.
A adoção dessa abordagem de camadas resulta em um modelo de referência para a comunicação ligeiramente adaptado, Figura 4.3. Em comparação com o modelo OSI, as camadas de sessão e apresentação foram substituídas por uma camada única de middleware que contem protocolos independentes de aplicação. Esses protocolos não pertencem às camadas mais baixas. Os serviços de transportes originais também podem ser oferecidos como um serviço de middleware, sem modificação. Essa abordagem é, de certo modo, análoga a oferecer UDP no nível de transporte. Da mesma maneira, serviços de comunicação de middleware podem incluir serviços de troca de mensagens comparáveis aos oferecidos pela camada de transporte.
Tipos de Comunicação (Middleware)
Para entender as várias alternativas de comunicação que o middleware pode oferecer a aplicações, vemos o middleware como um serviço adicional de cliente-servidor, Figura 4.3. Segue os tipos de comunicação de middleware. 
Comunicação persistente
Uma mensagem que foi apresentada para transmissão é armazenada pelo middleware de comunicação durante o tempo que for necessário para entrega-la ao receptor. Nesse caso, o middleware armazenara a mensagem em um ou em vários recursos de armazenamento, figura 4.4. Não é necessário que que a aplicação remetente continue em execução após apresentar a mensagem. Da mesma maneira, a aplicação receptora não precisa estar em execução no momento em que a mensagem é apresentada.
Comunicação transiente
Mensagem é armazenada somente durante o tempo em que a aplicação remetente e a aplicação receptora estiverem executando. Figura 4.4. Normalmente, todos os serviços de comunicação de nível de transporte oferecem somente comunicação transiente. Nesse caso, o sistema de comunicação consiste em repassadores tradicionais do tipo armazena e reenvia. Se um repassador não puder entregar uma mensagem ao próximo repassador, ou ao hospedeiro de destino ele apenas descarta a mensagem.
Comunicaçãoassíncrona
Remetente continua sua execução imediatamente após ter apresentado sua mensagem para transmissão. Isso significa que a mensagem é imediatamente armazenada, temporariamente, pelo middleware assim que apresentada.
Comunicação síncrona 
 Remetente é bloqueado até saber que sua requisição foi aceita. São três os pontos em que a sincronização pode ocorrer:
O remetente pode ser bloqueado até que o middleware avise que se encarregara da transmissão da requisição;
O remetente pode sincronizar até que sua requisição seja entregue ao receptor pretendido;
A sincronização pode ocorrer permitindo que o remetente espere até que sua requisição tenha sido totalmente processada.
Comunicação Discreta e por Fluxo
Discreta: Partes se comunicam por mensagens e cada mensagem forma uma unidade de informação completa.
Fluxo: Várias mensagens, sendo que as mensagens estão relacionadas umas com as outras pela ordem ou pela relação temporal.
Chamada de ProcedimentoRemoto – RPC. 
Birrell and Nelson (1984)
“Permite programas chamar procedimentos localizados em outras maquinas”. Informações podem ser transportadas do chamador para quem foi chamado nos parâmetros e podem voltar no resultado do procedimento. Absolutamente nada da troca de mensagens é visível para o programador. Esse método é conhecido como chamada de procedimento remoto (RPC). 
O procedimento chamador e o procedimento chamado rodam em máquinas diferentes, executam, em espaço de endereços diferentes, o que causa complicações. Também é preciso passar parâmetros e resultados o que pode ser complicado, em especial se as máquinas não forem idênticas. RPC é uma técnica de ampla utilização subjacentes a muitos sistemas distribuídos.
Operações básicas de RPC 
Chamadas de procedimentos convencional
Para entender como o RPC funciona, em primeiro lugar é importante entender completamente como funciona uma chamada de procedimentos convencional, isto é, em uma única máquina (fig. 4.5 a). Há várias coisas que merecem ser observadas, parâmetros podem ser chamados por valor ou por referência. Um parâmetro de valor é simplesmente copiado para pilha (fog 4.5 b). Para o procedimento chamado, um parâmetro de valor é apenas uma variável local com o valor definido. O procedimento chamado pode modifica-lo, mas tais alterações não alteram o valor original do lado do chamador. Um parâmetro de referência é um ponteiro para uma variável, isto é, o endereço da variável e não o valor da variável. 
Também existe um outro mecanismo de passagem de parâmetro denominado chamada por copiar/restaurar. Consiste em fazer um chamador copiar a variável para a pilha, como em chamada por valor, e então copiá-la de volta após a chamada, sobrescrevendo o valor original do chamador. O mecanismo chamado por copiar/restaurar não é usado em muitos lugares.
Apêndices de clientes e de servidor 
A ideia que fundamenta a RPC é fazer com que uma chamada de procedimento remoto parece o mais possível com chamada local. Em outras palavras queremos que RPC seja transparente – O procedimento de chamada não deve estar ciente de que o procedimento chamado está executando em uma máquina diferente ou vice-versa.
Em um sistema tradicional – monoprocessador, a rotina Read é extraída da biblioteca pelo ligado e inserida no programa objeto. É um procedimento curto que em geral é implementado chamando uma chamada de sistema read equivalente. O procedimento read é um tipo de interface entre o código do usuário e o sistema operacional local. Ainda que a read faça uma chamada de sistema, ela é chamada da maneira usual, passando os parâmetros para a pilha, (fig 4.5. b). Assim, o programador não sabe que na verdade read está fazendo algo suspeito.
A RPC consegue sua transparência de modo análogo. Quando read, é na verdade, um procedimento remoto, uma versão diferente de read denominada apêndice de cliente é colocada na biblioteca. Como a original, ela é chamada usando a sequência de chamadas da (figura 4.5 b). Também como a original, ela faz uma chamada ao sistema operacional local. Só que, diferentemente do original, ela não pede ao sistema operacional que lhe de dados. Em vez disso, empacota os parâmetros em uma mensagem e requisita que essa mensagem seja enviada para o servidor. (fig 4.6). Em seguida, a chamada para send o apêndice de cliente chama receive, bloqueando a si mesmo até que a resposta volte. 
Apêndice de servidor é o equivalente, no lado do servidor a um apêndice de cliente; é um pedaço de código que transforma aquisições que vem pela rede em chamadas de procedimentos locais. Normalmente o apêndice de servidor terá chamado receive e estará bloqueado esperando por mensagens que chegam. O apêndice de servidor desempacota os parâmetros da mensagem e então chama o procedimento do servidor da maneira usual.
Serviços remotos são acessados fazendo chamadas de procedimentos comuns, isto é, locais e não chamando send e receive.
As chamadas de procedimentos remotos – RPC ocorre nas seguintes etapas:
1. Procedimento do cliente chama Stub cliente de modo usual
2. Stub do cliente constrói uma msg e chama o SO
3. SO envia msg para SO remoto
4. SO remoto repassa msg para Stub do servidor
5. Stub do servidor desempacota parâmetros e chama procedimento servidor
6. Procedimento servidor executa e retorna o resultado
7. Stub do servidor empacota resultado em uma msg e chama SO
8. SO remoto envia msg para SO da máquina cliente
9. SO do cliente passa msg para Stub cliente
10. Stub cliente desempacota resultado, repassando-o para o cliente
 O efeito líquido de todas essas etapas é converter a chamada local pelo procedimento de cliente ao apêndice de cliente em uma chamada local para o procedimento de servidor sem que nem o cliente e nem o servidor fiquem cientes das etapas intermediárias ou da existência da rede.
Passagem de Parâmetro 
A função do apêndice de cliente é pegar seus parâmetros, empacota-los em uma mensagem e envia-los ao apêndice do servidor. Embora essa operação pareça direta, não é tão simples como parece à primeira vista.
RPC – Passagem de Parâmetros por valor
 A chamada de propriamente dita do apêndice para o servidor é parecida com a chamada original do cliente, exceto que os parâmetros são variáveis inicializadas com base na mensagem que entra. A chamada do procedimento remoto add somente funcionara se as maquinas do cliente e do servidor forem idênticas. Contudo em um sistema distribuído de grande porte, é comum estarem presentes vários tipos de maquinas. Cada máquina costuma ter sua própria representação para números, caracteres, e outros itens de dados.
Problemas semelhantes podem ocorrer com a representação de inteiros e de números flutuantes. Além disso, existe um problema ainda mais irritante porque algumas maquinas, como Intel Pentium, numeram seus bytes da direita para a esquerda, enquanto outras, como a Sun SPARC, os numeram ao contrário. O formato Intel é denominado little endian, e o formato SPARC é denominado big endian. Uma solução para tais problemáticas seria o Cliente dizer seu tipo e a Conversão feita pelo servidor se tipos forem diferentes.
RPC – Passagem de parâmetros por referência
Observando que um ponteiro é significativo somente dentro do espaço de endereço do processo no qual está sendo usado. Read (fd, buf, nbytes) 
(executado nó servidor de arquivos)
fd → inteiro que indica um arquivo
buf → endereço do vetor de caracteres
nbytes → total de bytes a serem lidos
As alterações que o servidor faz usando o ponteiro, afetam diretamente o buffer de mensagem dentro do apêndice de servidor. Quando o servidor termina, a mensagem original pode ser enviada de volta ao apêndice de cliente, que então à copia de volta para o cliente. Na verdade, chamar por referência foi substituída por copiar/restaurar. Embora isso nem sempre seja idêntico.
Uma otimização torna esse mecanismo duas vezes mais eficiente. Se os apêndices soubessem se o buffer é um parâmetro de entrada ou um parâmetro de saída para o servidor, uma das cópias pode ser eliminada. Se o vetor for entrada para o servidor, ele não precisa ser copiado de volta. Se for saída nem precisa ser enviado.
Especificação de parâmetros e geração de apêndices.
	Ocultar uma chamada de procedimento remoto requer que o chamador e o chamado concordem com o formato das mensagens que trocam, e sigam as mesmas etapas quando se tratar, por exemplo, passar estruturas de dados complexas. Em outras palavras, ambos os lados de uma RPC devem seguir o mesmo protocolo, ou a RPC não funcionará corretamente.
A única diferença entre apêndices para o mesmo protocolo, mas procedimentos diferentes, normalmente são suas interfaces com as aplicações. Uma Interface consiste em um conjunto de procedimentos que podem ser chamados por um cliente e que são implementados por um servidor. Em geral, uma interface está disponível na mesma linguagem de programação em que o cliente ou servidor é escrito, embora, em termos estritos, isso não seja necessário. Interfaces costumamser especificadas por meio de uma linguagem de programação de interface – IDL. Portanto, uma interface especificada em tal IDL é, na sequência, compilada para zerar um apêndice de cliente e um apêndice de servidor, junto com as interfaces adequadas em tempo de compilação e tempo de execução.
Usar uma linguagem de definição de interface simplifica consideravelmente aplicações cliente-servidor baseadas em RPCs. Como é fácil gerar completamente apêndices de cliente e de servidor, todos os sistemas de middleware baseados em RPC oferecem uma IDL para suportar desenvolvimento de aplicações. Em alguns casos, usar IDL é até obrigatório.
RPC assíncrona 
Como em chamadas de procedimento convencionais, quando um cliente chama um procedimento remoto, o cliente bloqueia até que uma resposta seja retornada. Esse comportamento estrito requisição/resposta é desnecessário quando não há nenhum resultado a retornar, e só leva ao bloqueio do cliente enquanto ele poderia ter continuado e realizado trabalho útil logo após requisitar o procedimento remoto a ser chamado. Um desses exemplos seria transferir dinheiro de uma conta para outra. Não há necessidade de esperar por uma resposta.
Para suportar essas situações, sistemas RPC podem fornecer facilidades para o que denominamos RPCs assíncronas, pelas quais um cliente continua imediatamente após emitira requisição RPC. Com RPCs assíncronas, o servidor envia imediatamente uma resposta de volta ao cliente no momento em que a requisição RPC é recebida e, depois disso, chama o procedimento requisitado. A resposta age como reconhecimento para o cliente de que o servidor vai processar a RPC. O cliente continuará sem mais bloqueio, tão logo tenha recebido o reconhecimento do servidor.
	RPCs assíncronas também podem ser úteis quando uma resposta vai ser retornada, mas o cliente não está preparado para esperar por ela e, enquanto espera, nada faz.
	RPCs assíncrona deferida, ou seja, combinação de duas RPCs assíncronas:
Na primeira, o cliente chama o servidor para lhe entregar uma lista de nomes de hospedeiros que devem ser consultados e continua quando o servidor reconhecer o recebimento desta lista.
A segunda chamada é feita pelo servidor, que chama o cliente para lhe entregar os endereços que encontrou.
RPCs de uma via: são RPCs assíncronas nas quais o cliente continua executando imediatamente após enviar a requisição ao servidor. O problema com essa abordagem é que, quando a confiabilidade não é 0garantida, o cliente não pode saber, com certeza, se a requisição será ou não processada. RPC assíncrona deferida, o cliente pode sondar o servidor para ver se os resultados estão disponíveis, em vez de deixar que o servidor chame o cliente de volta.
Exemplo: DCE RPC
Chamadas de procedimento remoto foram amplamente adotados como base de middleware e sistemas distribuídos em geral. O ambiente distribuído de computação – DCE, que foi desenvolvida pela Open Group, antiga Open Software. O DCE RPC não é tão popular como alguns outros sistemas RPC, em particular o Sun RPC. Contudo, ainda assim o DCE RPC é representativo de outros sistemas RPC e suas especificações foram adotadas no sistema básico da Microsoft para computação distribuídas, DCOM (Eddon e Eddon, 1998).
Introdução ao DCE
O DCE é um verdadeiro sistema middleware no sentido de que é projetado para executar como uma camada de abstração entre sistemas operacionais existentes (rede) e aplicações distribuídas. Inicialmente projetado para Unix, agora ele foi portado para todos os sistemas operacionais importantes, entre eles variantes de VMS e Windows, bem como para sistemas operacionais de computadores de mesa. A ideia é que o cliente possa pegar um conjunto de maquinas existentes, adicionar o software DCE e então possa executar aplicações distribuídas, tudo isso sem perturbar aplicações existentes (não distribuídas). Toda comunicação entre clientes e servidores ocorre por meio de RPCs.
Serviços que fazem parte do DCE em si:
Serviço de arquivo distribuído: é um sistema de arquivo de âmbito mudial que fornece um modo transparente de acessar qualquer arquivo no sistema do mesmo modo. Ele pode ser construído em cima dos sistemas nativos de arquivo do hospedeiro, ou usado no lugar desses sistemas.
Serviço de diretório: é usado para monitorar a localização de todos os recursos no sistema. Entre esses recursos estão maquinas, impressoras, servidores, dados e muito mais, e eles podem ser distribuídos geograficamente no mundo inteiro. O serviço de diretório permite que um processo solicite um recurso e não tenha de se preocupar com o lugar em que ele está, a menos que o processo se importe.
Serviço de segurança: permite que recursos de todos os tipos sejam protegidos, portanto o acesso pode ser restrito às pessoas autorizadas
Serviço distribuído de horário: é um serviço que tenta manter sincronizados globalmente os relatórios presentes nas diferentes maquinas, ter noção do horário global facilita muito na garantia da consistência em um sistema distribuído.
Objetivos do DCE RPC
Os objetivos do DCE RPC são relativamente tradicionais. O sistema RPC permite a um cliente o acesso a um serviço remoto por meio de uma simples chamada a um procedimento local. Essa interface possibilita que programas cliente, isto é, aplicações, sejam escritos de modo simples, familiar à maioria dos programadores. Ele também facilita a execução de grandes volumes de código em um ambiente distribuído com poucas alterações, se tanto.
 	 Vinculação: Cabe ao sistema RPC ocultar todos os detalhes dos clientes e, até certo ponto, também dos servidores. Para começar, o sistema RPC pode localizar automaticamente o servidor correto e, na sequência, estabelecer a comunicação entre cliente e software servidor. Também pode manipular o transporte de mensagens em ambas as direções, fragmentando e montando novamente essas mensagens conforme necessário. O sistema RPC pode manusear automaticamente conversões de tipos de dados entre o cliente e o servidor, ainda que eles executem em arquiteturas diferentes e que tenham ordenação de bytes diferente.
	Como consequência da capacidade de sistemas RPC para ocultar os detalhes, é alto o grau de independência entre clientes e servidores. Um cliente e um servidor podem rodar em diferentes plataformas de hardware e usar sistemas operacionais diferentes. Também é suportada uma variedade de protocolos de rede e representações de dados, tudo sem nenhuma intervenção do cliente ou do servidor.
Como escrever um cliente e um servidor
 	Linguagem de definição de interface – IDL: permite declarações de procedimento em uma forma muito parecida com o protótipo de função em ANSI C. Esses arquivos podem conter definições de tipos, declarações de constantes e outros parâmetros e desmontar resultados corretamente. A definição de interface apenas define a sintaxe das chamadas, e não sua semântica.
	Identificador global: elemento crucial em todo arquivo IDL, exclusivo para a interface especificada. Definições de interface e identificadores exclusivos são intimamente relacionados em DCE. RPCs não é totalmente transparente, mas as regras IDL impossibilitam expressar construções que não sejam suportadas.
	Quando o arquivo IDL estiver concluído, o compilador IDL é chamado para processa-lo. A saída do compilador consiste em três arquivos:
Um arquivo de cabeçalho;
O apêndice de cliente;
O apêndice do servidor.
Vinculação de um cliente a um servidor
Para permitir que um cliente chame um servidor, é necessário que o servidor seja registrado e esteja preparado para aceitar chamadas que chegam. O registro deum servidor possibilita que um cliente localize e se vincule a um servidor. A localização é feita em duas etapas:
Localizar a máquina do servidor.
Localizar o servidor naquela máquina.
Figura 4.13
Execução de uma RPC
A RPC é executada transparentemente e de maneira usual. O apêndice de cliente monta os parâmetros para abiblioteca de execução para transmissão usando o protocolo escolhidoem tempo de vinculação.
O DCE oferece várias opções de semântica. O padrão (default) é a operação no máximo uma vez, caso em que nenhuma chamada jamais é executada mais de uma vez, mesmo em face de queda do sistema.
Procedimento remoto idempotente: caso em que ele pode ser repetido várias vezes sem danos. 
Comunicação orientada a mensagem
Chamamos de procedimento remoto e invocação de objeto remoto contribuem para ocultar comunicação em sistemas distribuídos, isto é, aprimoram a transparência de acesso. Infelizmente nenhum dos dois mecanismos é sempre adequado, as vezes precisa ser substituído por alguma outra coisa. Que é a troca de mensagens, que veremos nos próximos tópicos.
Comunicação Transiente Orientada a Mensagem
Muitos sistemas distribuídos e aplicações são construídos diretamente em cima do modelo simples orientado a mensagem oferecido pela camada de transporte, mensagens por meio de portas de nível de transporte.
Interface Berkeley
 A padronização da interface da camada de transporte foi alvo de especial atenção para permitir que peroradores use todo o seu conjunto de protocolos por meio de um conjunto simples de primitivas.
 Soquete: terminal de comunicação para o qual uma aplicação pode escrever dados que devem ser enviados pela rede subjacente e do qual pode ler dados que chegam. Um soquete forma uma abstração sobre o terminal de comunicação propriamente dito que é usado pelo sistema operacional local para um protocolo de transporte especifico.
Primitivas de interface para TCP.
 	Em geral, servidores executam as quatro primeiras primitivas, normalmente na ordem dada, tabela 4.1:
Primitiva de socket – o chamador cria um novo terminal de comunicação para um protocolo de transporte especifico. Internamente, a criação de um terminal de comunicação significa que o sistema operacional local reserva recursos para atender ao envio e ao recebimento de mensagens de e para o protocolo.
Primitiva de Bind – associa um endereço local com o soquete recém-criado.
Primitiva de Listen - é chamada somente no caso da comunicação orientada a conexão. É uma chamada não bloqueadora que permite ao sistema operacional local reservar buffers suficientes para um número especificado de conexões que o chamador está disposto a aceitar. 
Primitiva de Accept – bloqueia o chamador até chegar uma requisição de conexão. Quando chega uma requisição, o sistema operacional local cria um novo soquete com as mesmas propriedades do original e o retorna ao chamador.
Primitiva de Connect – requer que o chamador especifique o endereço de nível de transporte para o qual uma requisição de conexão deve ser enviada.
Primitivas de Send e Receive – o cliente é bloqueado até que uma conexão seja estabelecida com sucesso e, depois disso, ambos os lados podem começar a trocar informações. 
Primitiva de Close – o fechamento de uma conexão é simétrico quando se usa uma interface Sockets, e é conseguido ao fazer com que ambos, cliente e servidor chamem a primitiva close.
Interface de troca de mensagens (MPI)
Com multicomputadores de alto desempenho, desenvolvedores começaram a procurar primitivas orientadas a mensagem que lhe permitissem escrever com facilidade aplicações de alta eficiência. Para tanto, os soquetes foram considerados insuficientes, por duas razões: 
Eles estavam no nível errado de abstração porque suportavam apenas primitivas simples send e receive;
A interface Sockets foi projetada para comunicação por redes que usam pilhas de protocolos de uso geral, tal como TCP/IP. Eles não eram considerados adequados para os protocolos proprietários desenvolvidos para redes de interconexões de alta velocidade, como as usadas em clusters de servidores de alto desempenho.
A necessidade de independência de hardware e de plataforma resultou na definição de um padrão de troca de mensagens para escrever programas paralelos a serem executados em clusters, denominado simplesmente Interface de Passagem de Mensagem – MPI. Projetada para comunicação transiente – mensagem é armazenada no sistema enquanto remetente e receptor estiverem ativos.
A MPI adota a premissa de que a comunicação ocorre dentro de um grupo conhecido de processos. Cada grupo recebe um identificador. Cada processo dentro de um grupo recebe um identificador (local). Em seguida um Par (groupID, processID) identifica exclusivamente a fonte ou destinatário de uma mensagem e é usado no lugar de um endereço de nível de transporte. Vários grupos de processos poderão estar envolvidos em um serviço de computação, podendo estar em execução ao mesmo tempo.
No cerne da MPI estão primitivas de mensagens para implementar comunicação transiente, as mais intuitivas estão resumidas na tabela 4.2. 
A semântica das primitivas de comunicação MPI nem sempre é direta e, às vezes, primitivas diferentes podem ser trocadas sem afetar a correção de um programa. A razão oficial porque são suportadas tantas formas diferentes de comunicação é que isso dá aos implementadores de sistema MPI possibilidades suficientes para otimizar desempenho. A MPI foi projetada para aplicações paralelas de alto desempenho, o que facilita entender sua diversidade em diferentes primitivas de comunicação. 
Há mais de 100 funções diferentes para troca de mensagens, algumas:
MPI_recv → recebimento de mensagens; bloqueia o chamador até chegar uma mensagem;
MPI_irecv → receptor pode verificar se a mensagem realmente chegou ou não;
MPI_ALLtoall → distribui igualmente os dados entre todos os nós participantes da computação
Middleware orientado a mensagem (MOM)
Conhecidos como sistemas de enfileiramento de mensagens proporcionam suporte para comunicação assíncrona persistente. A essência desses sistemas é que eles oferecem capacidade de armazenamento de médio prazo para as mensagens trocadas sem exigir que o remetente ou o receptor estejam ativos durante a transmissão.
Modelo de enfileiramento de mensagens
 Aplicações se comunicam retirando e colocando mensagens em filas especificas. Essas mensagens são repassadas por uma série de servidores de comunicação e, a certa altura, entregues ao destinatário, mesmo que ele não esteja em funcionamento quando a mensagem foi enviada. Em princípio, cada aplicação tem sua própria fila particular para a qual outras aplicações podem enviar mensagens. Uma fila só pode ser lida por sua aplicação associada, mas também é possível que várias aplicações compartilhem uma única fila.
Mensagem será eventualmente entregue ao receptor.
Em geral, um remetente só tem a garantia de que, a certa altura, sua mensagem será inserida na fila do receptor. Nenhuma garantia é dada sobre quando, nem ao menos se, a mensagem será realmente lida, o que é totalmente determinado pelo comportamento do receptor. Essa semântica permite comunicação fracamente acoplada em relação ao tempo. Remetente e Receptor podem executar em completa independência, figura 4.15.
Em princípio, mensagens podem conter qualquer tipo de dado. O único aspecto importante da perspectiva do middleware é que as mensagens devem ser adequadamente endereçadas. O endereçamento e feito com o fornecimento de um nome exclusivo da fila destinatária no âmbito do sistema da fila destinatária. Tabela 4.3
A primeira put é chamada por um remetente para passar uma mensagem ao sistema subjacente, mensagem essa que é anexada à fila especificada. A primitiva get é uma chamada bloqueadora pela qual um processo autorizado pode retirar a mensagem que está pendente há mais tempo na fila especificada. O processo é bloqueado somente se a fila estiver vazia. Variações dessa chamada permitem procurar uma mensagem especifica na fila. A variante não bloqueadora é dada pela primitiva poll, se a fila estiver vazia, ou se uma mensagem especifica não puder ser encontrada, o processo chamador simplesmente continua.
A maioria dos sistemas de enfileiramento também permite que um processo instale um manipulador como uma função de chamada de retorno, que é automaticamente invocada sempre que uma mensagem for colocada na fila. Chamadasde retorno também podem ser usadas para iniciar automaticamente.
Arquitetura Geral
É em geral, um sistema de enfileiramento de mensagens. Uma das primeiras restrições que fazemos é que mensagens só podem ser colocadas em filas locais do remetente. Tipos de fontes:
Fila de Fonte: Fila na qual o remetente envia a mensagem. Estas filas são filas locais do remetente;
Fila de Destino: Umas mensagens colocadas em uma fila contem a especificação de uma fila de destino para a qual ela deve ser transferida;
Gerenciadores de Fila: Um gerenciador de fila interage diretamente com a aplicação que está enviando ou recebendo uma mensagem, somente devem saber onde está o repassador mais próximo.
Repassadores: Repassam mensagens que chegam para outros gerenciadores de fila.
Sistema de enfileiramento de mensagens pode crescer até uma rede de sobreposição (overlay) completa de nivel de aplicação. Repassadores podem ajudar a construir sistemas escaláveis de gerenciamento de fila. Atualizações de remoção e adição de filas devem ser feitas somente nos repassadores. Também podem ser usados para finalidade de Multicasting.
Brokers de mensagens 
Em sistemas de enfileiramento de mensagens, conversões são manipuladas por nós especiais em uma rede de enfileiramento. Um broker age como um gateway de nível de aplicação em um sistema de enfileiramento de mensagens. Sua principal finalidade é converter mensagens que chegam de modo que elas sejam entendidas pela aplicação destinatária.
Um broker de mensagem pode ser tão simples como um reformatador para mensagens. Contudo, o mais comum é utilizar um broker de mensagem para integração avançada de aplicações empresariais – EIA. Nesse modelo, denominado publicar/sobrescrever, aplicações enviam mensagens na forma de publicar.
Observações Sobre Sistemas De Enfileiramento De Mensagens.
Sistemas de e-mails, geralmente são implementados por meio de um conjunto de servidores de correio que armazenam e repassam mensagens em nome de usuários em hospedeiros diretamente conectados ao servidor. Em geral, o roteamento é excluído, porque sistemas de e-mail podem uso direto dos serviços de transporte subjacente (SMTP).
O que torna os sistemas de e-mail especiais em comparação com os sistemas de enfileiramento de mensagens é que eles visam primeiramente a prover suporte direto a usuários finais. Sistemas de e-mail podem ter requisitos muito específicos como filtragem automática de mensagens, suporte para bancos de dados avançados de mensagens. 
Sistemas gerais de enfileiramento de mensagens não visam a suportar somente usuários finais, eles são montados para possibilitar comunicação persistente entre processos. Essa abordagem rodagem em um conjunto de requisitos para sistemas de enfileiramento de mensagens diferentes do conjunto de requisitos para sistemas de e-mail puros, sistemas de e-mail não precisam fornecer entrega garantida de mensagens, entre outros.
Sistemas de enfileiramento de mensagens de uso geral tem ampla faixa de aplicações, incluindo e-mail, fluxo de trabalho, Groupware e processamento em lotes. A área de aplicação mais importante é a integração de um conjunto de bancos de dados e aplicações. Tais sistemas, ajudam fornecendo meios básicos para empacotar cada subconsulta em uma mensagem e rateá-la até um banco de dados adequado.
Exemplo: sistema de enfileiramento de mensagens WebSphere da IBM
Visão geral e Canais
 
Tranferência de mensagens.
Comunicação Orientada a Fluxo 
O aspecto característico desse tipo de comunicação é que não importa em que ponto particular do tempo a comunicação ocorre. Embora o funcionamento de um sistema possa ser muito lento ou mais rápido, a temporização não tem efeito sobre a correção.
Suporte para mídia continua
Mídias se refere aos meios pelos quais a informação é transmitida, nos quais estão incluídos meios de armazenamento e transmissão. Um tipo importante de meio é o modo como a informação é representada.
Em mídia continua (de representação), as relações temporais entre diferentes itens de dados são fundamentais para interpretar corretamente o que os dados realmente significam.
Ao contrário da mídia continua, a mídia discreta (de representação) é caracterizada pelo fato de que as relações temporais entre itens de dados não são fundamentais para interpretar corretamente os dados.
Fluxo de dados
Nada mais é do que uma sequencia da unidade de dados podem ser aplicadas à mídia discreta, bem como a mídia contínua.
A temporização é crucial para fluxos contínuos de dados. Para capturar aspectos da temporização, costuma-se fazer uma distinção entre diferentes modos de transmissão:
- Modo de transmissão assíncrona – os itens de dados em um fluxo são transmitidos um após o outro, mas não há nenhuma restrição de temporização sobre quando a transmissão de itens deve ocorrer. Esse é o caso típico de fluxos discretos de dados.
- Modo de transmissão síncrona – há um atraso fim a fim máximo definido para cada unidade em um fluxo de dados.
- Modo de transmissão isócrona – é necessário que as unidades de dados estão sujeitas a um atraso fim a fim quer tem um valor máximo e um valor mínimo, também denominado variações de atraso delimitado. É particularmente interessante para sistemas distribuídos de multimídia, porque ele desempenha papel crucial na representação de áudio e vídeo.
Fluxos Simples – Consiste em uma única sequência de dados
Sequencia simples de dados.
Fluxos “Complexos” - Consiste em vários fluxos simples relacionados denominados subfluxos. Relação temporal entre os subfluxos, unidades de dados de cada fluxo devem ser comunicadas aos pares para garantir o efeito estéreo.
Fluxo e Qualidade de Serviço (QoS)
- Requisito de temporização – geralmente são expressos como requisitos de qualidade de serviços QoS, descrevem o que é necessário para garantir que as relações temporais em um fluxo possam ser preservadas QoS´s para fluxo contínuo de dados referem-se principalmente:
Pontualidade
Volume
Confiabilidade
Propriedades importantes:
1º A taxa de bits requerida a qual os dados devem ser transportadas.
2º O máximo atrasa até p estabelecimento de uma sessão, isto é, quando uma aplicação pode começar a enviar dados;
3º O máximo atraso fim a fim, isto é quanto tempo levará ate que uma unidade de dados chegue a um receptor;
4º A máxima variância de atraso, ou vibração.
5º máximo atraso de viagem de ida e volta.
Quando se trata de comunicação orientada a fluxo baseada na pilha de protocolos da internet, temos apenas de aceitar viver com o fato de que a base de comunicação é formada por um serviço de datagramas, de melhor esforço extremamente simples: IP.
O IP fornece algum suporte de QoS, mas ele raramente é implementado.
4.2.1 Imposição de QoS
Dado que o sistema subjacente oferece apenas um serviço de entrega de melhor esforço, um sistema distribuído pode tentar ocultar o máximo possível a falta de qualidade de serviço. 
Serviço diferenciado - a internet proporciona meios para diferenciar classes de dados.
Repasse acelerado – Hospedeiro remetente que marca pacotes da saída como pertencentes a uma de várias classes, basicamente específico que um pacote deve ser repassado pelo repassador corrente com absoluta prioridade.
Repasse garantido – o tráfego é dividido em quatro subclasses, aliadas a três modos de descartar pacotes, se a rede ficar congestionada. Define efetivamente uma faixa de prioridades que podem ser designadas a pacotes e, por isso, permite que as aplicações diferenciem pacotes sensíveis ao tempo de pacotes não críticos.
Um sistema distribuído também pode ajudar a levar dados até os receptores. Uma ferramenta que é particularmente útil é usar buffers para reduzir variâncias de atraso. 
Pacotes podem ser perdidos, para compensar essa perda na qualidade de serviços precisamos aplicar técnicas de correção de erros de envio – FEC.
Técnica bem conhecida para qualificar os pacotes de saída de modo tal que K de n pacotes recebidos, seja suficiente, para construir k pacotes corretosSincronização de fluxos
Uma questão importante em sistemas de multimídias é que fluxos diferentes, possivelmente na forma de um fluxo complexo são mutuamente sincronizados. A sincronização de fluxo trata de manter a relação temporais de fluxo. Ocorre em dois tipos de sincronização. A forma mais simples entre fluxos discretos de dados e fluxo contínuo de dados. Um tipo mais exigente de sincronização é entre fluxo contínuo de dados.
A sincronização ocorre no nível de dados das unidades de dados que compõe o fluxo. Podemos sincronizar dois fluxos somente entre unidades de dados. A escolha do que é exatamente uma unidade de dados depende muito do nível de abstração no qual o fluxo de dados é visto.
Mecanismos de sincronização
É preciso distinguir duas questões:
1º os mecanismos básicos para sincronizar dois fluxos;
2º a distribuição desse mecanismo em um ambiente de rede.
 Mecanismos de sincronização podem ser vistos em diferentes níveis de abstração. No nível mais baixo a sincronização é feita explicitamente por operações sobre unidades de dados de fluxos simples. Há um processo que simplesmente executa operação de leitura e escrita em vários processos simples, assegurando que essas operações obedeçam as restrições especificas de temporização e sincronização. 
A desvantagens dessa abordagem é que a aplicação fica totalmente responsável por implementar sincronização, embora só tenha à disposição facilidade de baixo nível. Uma abordagem mais apropriada é oferecer a uma aplicação uma interface que lhe permita um controle mais fácil de fluxo e dispositivos. Com essas interfaces de controle, um desenvolvedor de aplicação pode descrever um programa monitor padrão simples que consiste em dois manipuladores, um para cada fluxo, que, em conjunto, verificam se os fluxos de vídeo e áudio estão suficientemente sincronizados, se necessário, ajustam a taxa com que são apresentados às unidades de vídeo ou áudio. 
O lado receptor de um fluxo complexo, que consiste em subfluxos que requer sincronização precisa saber exatamente o que fazer. Ele deve ter uma especificação de sincronização completa disponível no local. Na sequencia, esse fluxos são multiplexados em fluxos de programas que consiste em pacotes de comprimentos variados, mas que tem algo em comum: todos eles tem a mesma base de tempo, o lado do executor demutiplexa o fluxo, usando as marcas de tempo de cada pacote como mecanismo básicos para sincronização entre fluxos. 
Uma outra questão é que a sincronização deve ocorrer ao lado remetente ou no lado receptor. Se o remetente manipular a sincronização pode ser possível fundir fluxo em um único fluxo, com tipos diferentes de dados. Uma possibilidade é transferir cada fluxo independentemente ao receptor e deixar que este sincronize as amostras par a par. Uma abordagem mais apropriada é fundir os dois subfluxos no remetente. O fluxo resultante consiste em unidades de dados compostas de pares de amostra, uma para cada canal. Basta apenas o receptor ler uma unidade de dados e subdividi-las em uma amostra direita e outra esquerda. Nessas circunstancias, os atrasos para ambos os canais são idênticos.
Comunicação Multicast
Com o advento da tecnologia peer to peer e, principalmente do gerenciamento estruturado de sobreposição, ficou mais fácil estabelecer caminhos de comunicação. Como soluções peer to peer costumam ser disponibilizadas em camadas de aplicação, várias técnicas de Multicast de nível de aplicação foram apresentadas. 
Multicasting de Nível de Aplicação (MNA)
Ideia básica: Nós se organizam em uma rede de sobreposição que é usada para disseminar informações para seus membros. Os passadores da rede não estão envolvidos na associação ao grupo. Por consequência as conexões entre nos na rede de sobre podem cruzar vários enlaces físicos e por isso o roteamento de mensagens dentro da rede de sobreposição pode não ser ótimo em comparação quanto ao que poderia ser conseguido por roteamento em nível de rede. 
Uma construção crucial de projeto é a construção da rede de sobreposição (overlay). Há duas abordagens: 
Na primeira os nós podem se organizar diretamente em uma árvore, o que significa que há um único caminho de sobreposição (entre cada par de nós). Na segunda os nós se organizam em uma rede em malha em que cada nó terá vários vizinhos, em geral, existem vários caminhos entre cada par de nos. A principal diferença entre as duas é que em geral a ultima oferece mais robustez e no caso da estrutura em arvore, o problema é construir uma arvore eficiente.
Disseminação de Dados – Protocolos Epidêmicos.
O objetivo principal dos protocolos epidêmicos propagar informações rapidamente entre um grande conjunto de nós usando somente informações locais. Não ha nenhum componente central que coordena a disseminação de informações.
Modelos de Disseminação de Dados
Algoritmos epidêmicos propagam informações. Os projetistas de algoritmos para sistemas epidêmicos para sistemas distribuídos tentaram “infectar” todos os nós com as novas informações mais rapidamente possível. Usando a terminologia das epidemias, o nó que é parte de um sistema distribuído é denominado infectado se contiver dados que estiver disposto a espalhar para os outros nós. Um nó que ainda não tenha visto esses dados é denominado suscetível. Por fim, o nó atualizado que não está disposto ou capacitado para propagar os dados é denominado removível. Sob essa luz, diz-se também que nós propagam atualizações.
Um modelo popular de propagação é o da Antientropia
Ideia Básica: Um nó P escolhe aleatoriamente um outro nó Q :
Push: P envia suas próprias atualizações a Q
Pull: P recebe novas atualizações de Q
Push-Pull: P e Q enviam atualizações um ao outro, (abordagem enviar-receber)
Rodada – abrange um período no qual todo nó terá tomado, no mínimo uma vez a iniciativa de trocar atualizações como outro nó escolhido aleatoriamente.
Gossiping
Se um nó P acabou de ser atualizado com o item de dado x, ele contata um nó arbitrário Q e tenta enviar a atualização a Q. Contudo, é possível que Q já tenha sido atualizado por um outro no. Nesse caso, P pode perder o interesse em levar adiante a propagação da atualização, com probabilidade 1/k, ele se torna removível.
Modelo excelente de espalhar notícias rapidamente. Contudo, ele não pode garantir que todos nós realmente serão atualizados (nós poderão não receber atualizações)
Uma das principais vantagem de algoritmos epidêmicos é sua escalabilidade, devido ao fato de que o número de sincronização entre processos é relativamente pequena em comparação com outros métodos de propagação. Para sistemas de longa distância, nós que estão conectados há apenas alguns outros nós, são contatados com a probabilidade relativamente alta. A premissa subjacente é que tais nós formam uma ponte com outras partes remotas da rede; por conseguinte, devem ser contatados tão logos seja possível. Essa abordagem é denominada gossiping direcional e tem diferentes variantes.
remoção de dados
Algoritmos são extremamente bons para propagar atualizações. Contudo, eles tem um estranho efeito colateral: propagar remoção de itens de dados é difícil.
A essência do problema encontra-se no fato de que a remoção de um item de dados destrói todas as informações naquele item.
Solução: o jeito é gravar a remoção de um item de dados como apenas mais uma atualização e manter um registro dessa remoção. Tal registro é feito pela propagação de certificado de óbito.
Para dar garantia certa de que as remoções serão realmente propagadas para todos os nós, alguns poucos nós mantém certificados de óbitos dormentes (quando certificados de óbitos recebem uma marca de tempo quando criados) que nunca são jogados fora.
Aplicações
Agregar informações, a velocidade de propagação é exponencial. Só essa informação já basta para ser usada a fim de ajustar dinamicamente vários parâmetros. Por exemplo, o tamanho da visão parcial – isto é número de vizinhos que cada nó monitora- deve ser dependente do número total de nósparticipantes. Conhecer esse número permitirá que o nó ajuste dinamicamente o tamanho de sua visão parcial. Na realidade, isso pode ser visto como uma propriedade de alto gerenciamento. 
Calcular a média pode ser difícil quando nós, entram e saem do sistema periodicamente. Uma solução prática para esse problema é introduz ir épocas. Considerando que o nó um seja estável, ele simplesmente inicia uma nova época de vez enquanto. Quando o nó i vir uma nova época pela primeira vez, ele reajustará sua própria variável x, para zero e começa a calcular a média novamente.
Conclusão
Dispor de facilidades poderosas e flexíveis para comunicação entre processos é essencial para qualquer sistema distribuído em aplicações tradicionais de rede a comunicação costuma ser baseada nas primitivas de troca de mensagens de baixo nível oferecidas pela camada de transporte. Uma questão importante em sistemas de middleware é oferecer um nível mais alto de abstração que facilitará expressar comunicação entre processos mais do que o suporte oferecido pela interface com a camada de transporte.
Uma das abstrações mais amplamente utilizadas é a chamada de procedimento remoto (RPC). A essência de uma RPC é que um serviço é implementado por meio de um procedimento cujo corpo é executado em um servidor. O cliente recebe apenas uma assinatura do procedimento, isto é, o nome do procedimento junto com seus parâmetros. Quando o cliente chama o procedimento, a implementação do lado do cliente, denominada apêndice, fica encarregada de embrulhar os valores dos parâmetros em uma mensagem enviá-la ao servidor. Este chama o procedimento propriamente dito e retorna os resultados, mais uma vez em uma mensagem. O apêndice do cliente extrai os valores do resultado da mensagem de retorno e a passa de volta à aplicação cliente chamador.
RPCs oferecem facilidades de comunicação síncrona, pelas quais um cliente é bloqueado até que o servidor tenha enviado uma resposta. Embora exista varias de qualquer um dos mecanismos pelas quais esse modelo síncrono estrito é amenizado, ocorre que os modelos de uso em geral de alto nível orientados a mensagens muitas vezes são mais convenientes.
Em modelos orientados a mensagem, as questões giram em torno de se uma comunicação é ou não persistente e se uma comunicação é ou não síncrona. A essência da comunicação persistente é uma mensagem apresentada para transmissão é armazenada pelo sistema de comunicação pelo tempo que for necessário para entrega-la. Em outras palavras, nem o remetente nem o receptor precisam estar ligados e funcionando para que a transmissão da mensagem ocorra. Em comunicação transiente, nenhuma facilidade de armazenamento é oferecida, de modo que o receptor deve estar preparado para aceitar a mensagem quando ela for enviada.
Em comunicação assíncrona, o remetente tem permissão de continuar imediatamente após a mensagem ter sido enviada. Em comunicação síncrona, o remetente é bloqueado no mínimo até que uma mensagem seja recebida. Alternativamente, o remetente pode ser bloqueado até ocorrer a entrega da mensagem ou mesmo até que o receptor tenha respondido, como acontece com as RPCs.
Modelos de middleware orientado a mensagem em geral oferecem comunicação assíncrona persistente e são usados onde RPCs não são adequadas. Esses sistemas costumam ser utilizados para ajudar na integração de conjunto de banco de dados (amplamente dispersos) a sistemas de informações de grande escala. Entre outras aplicações estão e-mail e fluxo de trabalho.
Uma forma muito diferente de comunicação é a comunicação por fluxos, na qual a questão é que se duas mensagens sucessivas têm ou não uma relação temporal. Em fluxos contínuos de dados, um atraso fim-a-fim máximo é especificado para cada mensagem. Além disso, também é requerido que as mensagens sejam enviadas sujeitas a um atraso fim-a-fim. Exemplos típicos desses fluxos continuo de dados são fluxos de áudio e vídeo. Em geral é difícil especificar e implementar quais são, exatamente, as relações temporais ou o que se espera do subsistema de comunicação subjacente em termos de qualidade de serviço. Um fator complicado é o papel da variância de atraso. Ainda que o desempenho médio seja aceitável, variações substanciais no tempo de entrega podem resultar em desempenho inaceitável.
Por fim, uma importante classe de protocolos de comunicação em sistemas distribuídos é o Multicasting. A ideia básica é disseminar informações de um remetente para vários receptores. Discutimos duas abordagens diferentes. Na primeira, o Multicasting pode ser conseguido com o estabelecimento de uma arvore entre o remetente e os receptores. Considerando que agora já entendemos como os nós se auto organizam em sistemas peer-to-peer, também apareceram soluções para estabelecer arvores dinamicamente de modo descentralizado.
Uma outra classe importante de soluções de disseminação utiliza protocolos epidêmicos. Esses protocolos mostraram ser muito simples, porém extremamente robustos. Exceto a simples propagação de mensagens, protocolos epidêmicos também podem ser utilizados com eficiência para agregar informações por toda a extensão de um sistema distribuído de grande porte.
Boa Vista – RR, 09 de maio de 16.