Notas de Aula - Sistemas distribuidos

Prévia do material em texto

Sistemas Distribuídos
Introdução
Definição
 Um sistema distribuído é 
um conjunto de computadores
independentes, interligados por 
uma rede de conexão, 
executando um software 
distribuído.
 Processos
● Executados concorrentemente
● Interagem para alcançar um objetivo comum
●Coordenação feita através de troca de mensagens, 
utilizando a rede de conexão
Evolução Computacional
● Invenção de redes de computadores de alta 
velocidade (anos 70):
● Rede local (Local Area Network - LAN)
● Rede global (Wide Area Network - WAN)
● Desenvolvimento de microprocessadores 
potentes (anos 80).
Sistemas Distribuídos
● É relativamente fácil agrupar um grande número 
de CPUs, conectando-as por uma rede de alta 
velocidade.
● O software para sistemas distribuídos é 
completamente diferente do software para 
sistemas centralizados
Por quê SDs?
 Vantagens:
● Cooperação e compartilhamento de
recursos
Benefícios:
● Redução de custos, aumento da confiabilidade,
disponibilidade e desempenho
Qual é a Importância?
Problemas!!!!
 No pain, no gain!
Mas como lidar com sistemas 
heterogêneos?
● Sistemas distribuídos costumam ser organizados
 por meio de uma camada de software
 
MIDLLEWARE
● Situado logicamente entre uma camada de nível
mais alto, composta de usuários e aplicações, 
e uma camada adjacente (SOs e comunicação)
Middleware (1/3)
●Oculta a distribuição, isto é, o fato que
a aplicação está sendo executada em diferentes
máquinas distribuídas geograficamente
●Oculta a heterogenidade: diferentes
sistemas operacionais, diferentes protocolos
de comunicação
Middleware (2/3)
Middleware (3/3)
Exemplos:
● RPC: chamada de procedimento remoto
● Comunicação orientada a mensagens: WebShere 
(IBM)
Meta I – Acesso a recursos
Facilitar aos usuários e aplicações acesso 
a recursos remotos e o compartilhamento 
de maneira controlada e eficiente
● Razão óbvia: Economia
● Impressoras, computadores, dados, página Web
● Conectividade e compartilhamento de 
informações
Problema: Segurança
Meta II – Transparência da 
Distribuição (1/5)
Consiste em ocultar o fato de que os
processos e recursos estão fisicamente
distribuídos por vários computadores
Tipos:
● Acesso
● Localização
● Migração
● Replicação
● Concorrência
● Falha
Meta II – Transparência da 
Distribuição (2/5)
Acesso:
● Ocultar diferenças em representação de dados,
e o modo como os recursos podem ser acessados
por usuários
● Exemplo: representação de inteiros little endian,
big endian
Localização:
●Usuários não podem dizer a localização física do
 recurso. Nomeação!
●Exemplo: www.google.com (??????)
Meta II – Transparência da 
Distribuição (3/5)
Migração:
● Recursos podem ser movimentados sem afetar
o modo como podem ser acessados
● Exemplo: Mudança de um servidor WEB
Relocação:
●Recursos podem ser relocados enquanto estão sendo
acessados
●Exemplo: uso móvel de laptops (redes wireless)
Meta II – Transparência da 
Distribuição (4/5)
Replicação:
● Ocultar o fato de que existem várias cópias de um 
recurso
● Aumentar a disponibilidade ou melhorar 
 o desempenho
Concorrência:
●Ocutar o fato que 2 ou mais usuários estejam
acessando um recurso no mesmo instante
●Consistência?
Meta II – Transparência da 
Distribuição (4/5)
Falha:
● Ocultar do usuário que um recurso deixou de
funcionar bem e que o sistema se recuperou
da falha
Transparência é sempre
requerida?
Bela meta no projeto e na implementação
de sistemas distribuídos, mas deve ser 
considerada em conjunto com outras questões, 
como desempenho e facilidade de compreensão
Exemplos??
Meta III – Abertura (1/2)
Um SD aberto é um sistema que oferece serviços
de acordo com regras padronizadas que descrevem
a sintaxe e a semântica desses serviços
 
Em redes de computadores: Protocolos
 Em SDs: Linguagem de definição de interface (IDL)
● Funções disponíveis, parâmetros, valores de 
 retorno
Meta III – Abertura (2/2)
Interoperabilidade:
● Caracteriza até que ponto duas implementações
de sistemas ou componentes de fornecedores
diferentes devem coexistir e trabalhar 
em conjunto
Portabilidade
● Caracteriza até que ponto uma aplicação desenvolvida 
para uma sistema distribuído A pode ser executada, 
sem modificação, em um sistema distribuído diferente B
que implementa as mesmas interfaces que A
Meta IV – Escalabilidade (1a/7)
Três Dimensões:
● Tamanho: Facilidade em adicionar mais usuários
e recursos ao sistema
● Geográfico: Usuários e recursos podem estar 
longes uns dos outros
● Administrativo: Facilidade de 
gerenciamento, mesmo que abranja muitas 
organizações administrativas diferentes
Meta IV – Escalabilidade (1b/7)
Meta IV – Escalabilidade (2/7)
Tamanho - Problemas:
● Limitações de serviços centralizados, dados,
algoritmos
● Servidores centralizados: Gargalo!!
● Dados: Novamente, Gargalo!!
● Algoritmos: - Sobrecarga na rede com todas
 mensagens enviadas a um nó
 - Falha de um nó não arruina
 o algoritmo
Meta IV – Escalabilidade (3a/7)
Tamanho - Soluções:
● Servidores centralizados Replicação →
● Dados Distribuição (DNS,Web)→
● Algoritmos: Roteamento (distance-vector)
 Exclusão Mútua (Ricart e Agrawala)
Meta IV – Escalabilidade(3b/7)
Meta IV – Escalabilidade (4/7)
Geográfico - Problemas:
● Retardo para propagação das informações
● Não confiabilidade da rede de conexão
● LANs Sistemas 'espalhados'geograficamente →
● Como localizar um serviço
● Comunicação síncrona
Meta IV – Escalabilidade (5/7)
Geográfico - Soluções:
● LANs Sistemas 'espalhados'→
● Comunicação assíncrona
● Evitar comunicação global (applets Java,
Javascripts)
● Retardo Replicar e posicionar servidores→
em posições estratégicas
● Não confiabilidade Algoritmos com →
mecanismo de ACKs e retransmissões
Meta IV – Escalabilidade (6/7)
Administrativo - Problemas:
● Políticas de utilização e pagamento dos recursos
● Gerenciamento
● Segurança
Meta IV – Escalabilidade (7/7)
Adminstrativo- Soluções:
● Mais difícil de todas! 
● Envolve $$$$, leis locais
● Peer-to-peer: ok: controle feito pelos
usuários finais; no entanto: nocivo para os
ISPs! 
Ciladas!!!
Premissas que podem ser adotadas ao
se desenvolver uma aplicação distribuída
● A rede é confiável
● A rede é segura
● A rede é homogênea
● A topologia não muda
● A latência é zero
● A largura de banda é infinita
● O custo de transporte é zero
● Há somente um administrador
Tipos de SDs
Classificação relacionada com a função principal
do sistema
● Computação Distribuída: oferecer
computação de alto desempenho 
● Cluster versus Grade
● Simulação de fenômenos físicos
● Teste de novos protocos, aplicações
distribuídas (PlanetLab, e.x)
● Sistemas de Informação: banco de dados
● Sistemas Pervasivos: Redes de Sensores,
Redes Celulares
Exemplos
● Internet
Redes de redes interconectadas, que se
comunicam através dos protocolos IP
● Intranet
Rede com uma única administração, com políticas
de segurança próprias
● Redes Móveis e Sistemas Pervasivos
Laptops, PDAs, celulares
● Web
Disponibilização de serviços e informações via 
Internet
Internet (1/2)
Internet (2/2)
● Rede Heterogênea (pela própria definição)
● Serviços: email,www,VoIP,tranferência de\
arquivos
Intranet (1/2)
Intranet (2/2)
● Diversas LANs ligadas por um backbone
● Serviços: impressoras, emails
● Geralmente conecta a Internet via roteadores
● Controle de fluxo de entrada e saída feito
por um firewall
Redes Móveis (1/2)
Redes Móveis (2/2)
● WLANs
● Conectividade para dispositivos portáteis 
(laptops, celulares, PDAs)WWW (1/2)
WWW (2/2)
● Compartilhamento de informação 
● Baseado em tecnologias como:
● HTTP
● URL
● Arquitetura cliente-servidor
● Sistema aberto
Resumo
● Sistemas Distribuídos
● Altamente difundidos atualmente
● Baseado em um conjunto de diferentes
 tecnologias
● Entendimento dos conceitos e principiais
problemas extremamente importantes 
para gerenciamento, implementação e 
programação
Sistemas Distribuídos –
Capítulo 2 - Aula 2
Aula de hoje
Estilos 
Arquitetônicos
Arquitetura de 
Sistemas
Arquiteturas e 
Middleware
Aula passada
Introdução, metas e 
tipos de Sistemas 
Distribuídos, 
Exemplos
Por quê definir uma 
arquitetura?
● SDs são complexas peças de software
● Componentes estão espalhados por diversas 
máquinas
● Sistemas devem ser organizados adequadamente!
● Organização lógica do conjunto de componentes
● Como organizar os componentes fisicamente?
Estilos Arquitetônicos (1/3)
 
Um componente é uma unidade modular com 
interfaces requeridas e fornecidas bem
definidas que é substituível dentro
do seu ambiente 
Estilo Arquitetônico (2/3)
● É formulado em termos de componentes
● Modo como os componentes estão conectados
● Dados trocados entre componentes
● Maneira como os componentes são configurados
 em conjunto para formar um sistema
Estilo Arquitetônico (3/3)
● Arquiteturas em Camadas
● Arquiteturas baseadas em objetos
● Arquiteturas centradas em dados
● Arquiteturas baseadas em eventos
Arquiteturas em Camadas
● Idéia Básica: um componente na camada L
i
tem permissão de chamar componentes na camada 
subjacente L
i-1 
Arquiteturas baseadas em 
objetos (1/2)
● Idéia Básica: Cada objeto corresponde ao que
definimos como componente, e esses componentes
são conectados por meio de chamada de 
procedimento (remota), p. ex., Java RMI
●Exemplo: Aplicação distribuída de uma rede de
locadoras, onde clientes podem alugar DVDs em 
diversas filiais. 
Arquiteturas baseadas em 
objetos (2/2)
Arquiteturas centradas em 
dados (1/2)
● Idéia Básica: Processos se comunicam por meio
de um repositório comum. 
●Exemplo: Grande conjunto de aplicações em rede
que dependem de um sistema distribuído de 
arquivos compartilhados o qual praticamente toda
a comunicação ocorre por meio de arquivos: Web
Arquiteturas centradas em 
dados (2/2)
Arquiteturas centradas em 
eventos (1/3)
● Idéia Básica: Nesta arquitetura, processos
demonstram o interesse por um evento ou 
conjunto de eventos (processo se subscreve)
e esperam pela notificação de qualquer um 
desses eventos, gerados por um processo
notificador. Em outras palavras, o produtor publica
uma informação em um gerenciador de eventos 
(middleware),e os consumidores 
se subescrevem para receber as
 informações deste gerenciador. Eventos e notificações.
●Exemplo: Consultas em vários bancos de dados
Arquiteturas centradas em 
eventos (2/3)
The Many Faces of Publish/Subscribe – Eugster 
et al. ACM Comput. Surv. (35)2:114-131 
Arquiteturas centradas em 
eventos (3/3)
The Many Faces of Publish/Subscribe – Eugster 
et al. ACM Comput. Surv. (35)2:114-131 
Arquiteturas de Sistemas (1/2)
Como diversos sistemas 
distribuídos são 
realmente organizados?
Onde são colocados os
componentes de software?
 Como é estabelecida a 
interação entre as peças de 
software?
Arquiteturas de Sistemas (2/2)
● Arquiteturas Centralizadas
● Cliente-Servidor: vídeo sob demanda,
terminais bancários
● Arquiteturas Descentralizadas
● Peer-to-peer (P2P): Chord
● Arquiteturas Híbridas
● Peer-to-peer (P2P): BitTorrent, PPLive
Arquiteturas Centralizadas 
(1/14)
Modelo Cliente-Servidor
● Processos são divididos em dois grupos 
(possível sobreposição)
● Servidor: processo que implementa um serviço
específico
● Cliente: processo que requisita um serviço ao
servidor. Requisição Resposta→
Arquiteturas Centralizadas 
(2/14)
Arquiteturas Centralizadas 
(3/14)
Arquiteturas Centralizadas 
(4/14)
●Modelo Cliente-Servidor: questões, questões!!
● Clientes e Servidores multithreads? 
● Comunicação???
● Qual o tipo de aplicação?
● Sem conexão, não confiável (UDP)?
● Com conexão, confiável (TCP)?
Arquiteturas Centralizadas 
(5/14)
Camadas de Aplicação (estilo arquitetônico)
● Considerando aplicações 
cliente-servidor que visam dar suporte ao 
acesso de usuários a banco de dados:
● Nível de interface
● Nível de processamento
● Nível de dados
Arquiteturas Centralizadas 
(6/14)
Camadas de Aplicação
● Exemplo: Google
Usuário Processamento
 
 Dados
Arquiteturas Centralizadas 
(7/14)
Camadas de Aplicação
● Exemplo: Suporte à decisão (corretora de
valores)
Usuário Processamento
 
 Dados
Arquiteturas Centralizadas 
(8/14)
Com a distinção entre três níveis lógicos, como
distribuir fisicamente uma aplicação 
cliente-servidor por várias máquinas?
● Arquitetura de duas divisões físicas
● Arquitetura de três divisões físicas
Arquiteturas Centralizadas 
(9/14)
●Arquitetura de duas divisões físicas
● Parte da interface é dependente
de terminal
● Aplicações controlam
remotamente a apresentação 
dos dados
 
25
Arquiteturas Centralizadas 
(10/14)
●Arquitetura de duas divisões físicas
● Nesse modelo, o software
cliente não faz nenhum 
processamento exceto 
o necessário para apresentar
a interface da aplicação
Arquiteturas Centralizadas 
(11/14)
●Arquitetura de duas divisões físicas
● Formulário que precise
ser completamente preenchido
antes do processamento.
Cliente pode verificar a correção
e consistência
● Editor de texto com funções 
básicas no cliente e ferramentas 
avançadas no servidor
Arquiteturas Centralizadas 
(12/14)
●Arquitetura de duas divisões físicas
● Pcs conectados por meio de uma
rede a um sistema de arquivos
distribuídos ou a um banco de 
dados
Arquiteturas Centralizadas 
(13/14)
●Arquitetura de duas divisões físicas
● Consulta a Web, com browser
um cliente pode construir 
gradativamente uma enorme
cache em disco local com as
páginas Web mais recentemente
consultadas
Arquiteturas Centralizadas 
(14/14)
Arquiteturas de três divisões físicas
Arquiteturas Descentralizadas 
(1/8)
Clientes e servidores são fisicamente 
subdivididos em partes logicamente equivalentes,
mas cada parte está operando em sua própria
porção do conjunto completo de dados, 
o que equilibra a carga!!!!
Interação entre os processos é simétrica: cada
processo agirá como um cliente e um servidor ao
mesmo tempo
Arquiteturas Descentralizadas
(2/8)
Sistemas P2P – questões, questões, questões!!
● Como organizar os peers em uma rede de 
sobreposição (overlay)?
● Como difundir o conteúdo?
● Como incentivar os peers
a colaborarem?
Arquiteturas Descentralizadas 
(3/8)
Considerando o overlay e modo de construção
● Redes Estruturadas procedimento →
determinístico para definição do overlay,
p.ex, tabela de hash distribuída (DHT)
● Redes Não-estruturadas algoritmos aleatórios→
para construção da rede de sobreposição, 
gerando um grafo aleatório
Arquiteturas Descentralizadas 
(4/8)
Arquiteturas P2P estruturadas
●Sistema Chord 
(Stoica et al, 2003)
●Nós estão logicamente 
organizados em um anel
●Item de dado com chave k
é mapeado para o nó com id >= k
●LOOKUP(k)
Arquiteturas Descentralizadas 
(5/8)
Arquiteturas P2P não-estruturadas
●Algoritmos aleatórios
● Cada peer possui
uma lista de vizinhos(visão parcial)
● Para encontrar dados,
inundar a rede (no pior
caso)
●Importante atualizar
a lista de vizinhos
● Mas como?
Arquiteturas Descentralizadas 
(6/8)
Arquiteturas P2P não-estruturadas
●Threads que solicitam
aos vizinhos a visão parcial (pull) ou que empurram
(push) a visão a seus vizinhos
● Algoritmos que atualizem a 
vizinhança a cada x unidades de informação 
enviadas 
Arquiteturas Descentralizadas 
(7/8)
Arquiteturas P2P não-estruturadas
●Um dos problemas: como encontrar os 
dados de maneira eficiente
● Muitos sistemas utilizam nós especiais, que
possuem um índice de itens de dados → Superpeers
● Características especiais?
● Como associar peers comuns a estes superpeers?
● Como escolher estes peers?
Arquiteturas Descentralizadas 
(7b/8)
Arquiteturas Descentralizadas (8/8)
Arquiteturas Híbridas
BitTorrent(Cohenm, 2003)
peer
Tracker
Torrent
Arquiteturas Descentralizadas 
Arquiteturas Híbridas
BitTorrent(Cohenm, 2003)
C
Arquiteturas versus 
Middleware
 Cada middleware possui um estilo arquitetônico 
 específico, com o objetivo de simplificar o projeto
 de aplicações
● Como fazer com que um middleware genérico se 
adapte a aplicação?
● Middleware “inchado”
● Interceptores podem ser usados para 
interromper o fluxo de execução para que uma 
procedimento específico da aplicação possa ser
executado
Arquiteturas versus 
Middleware
Autogerenciamento em SDs
 Sistemas distribuídos devem ser capazes de reagir
 a mudanças em seu ambiente
● Ex: Troca dinâmica de políticas de alocação
de recursos; Troca de codificação voz/vídeo
para se adequar a condições de
congestionamento na rede
Desafio: Deixar que o comportamento reativo 
ocorra sem intervenção humana!
Autogerenciamento em SDs
 Idéia: Através de observações do comportamento
 do SD, componentes de estimativa de medições e de
 análise coletam dados e realimentam o sistema, 
 modificando parâmetros controláveis.
Autogerenciamento em SDs
 Alguns Exemplos:
● Astrolabe: ferramenta para observação
de Sds. Resultados podem ser usados para
alimentar um componente de análise para
possíveis ações corretivas
 
Resumo
● SDs podem ser organizados de diferentes 
 maneiras.
● Software: Estilos arquitetônicos
● Físico: Arquitetura de sistemas
● O projeto de sistemas autogerenciadores visa
a adaptação do SD ao ambiente em que está 
sendo executado, obtendo um maior desempenho
do mesmo
Sistemas Distribuídos –
Capítulo 3 - Aula 3
Aula de hoje
Threads
Threads em SDs
Processos Clientes
Processos 
Servidores
Aula passada
Arquitetura de SDs
 Estilo Arquitetônico
 Arquitetura de Sistemas
Sistemas 
Autogerenciáveis
 Processos
Um processo é um programa em execução, ou melhor,
 um ambiente onde se executa um programa.
Programa
Contexto de
Software
Contexto de
Hardware
Espaço de
Endereçamento
Revisitando Processos e 
Threads 
Programa
Contexto de
Software
prioridade de
execução reg istrador PC
data/hora
de criação
tempo de
processador
reg istrador SP
quotas
privilég ios
endereços de memória
principal alocados
reg istrador
de status
owner (UID)
PID
nome
reg istradores
gerais
Contexto de
Hardware
Espaço de
Endereçamento
Informações referentes a um processo
Revisitando Processos e 
Threads
Quando um processo é interrompido para que outro processo 
utilize a CPU, é realizada a Troca de Contexto.
Processo A
Salva BCP de PA
Salva BCP de PB
Carrega BCP de PB
Carrega BCP de PA
executando
Revisitando Processos e 
Threads
 Num sistema multithread, cada thread do processo
possui o seu contexto de hardware e software 
(pois uma thread “disputa” a CPU com as
 outras threads e processos).
 A diferença com os sub processos é que
 todas as threads de um processo compartilham 
o mesmo espaço de endereçamento 
(gerando concorrência entre as threads).
Revisitando Processos e 
Threads
Contexto
de hardware
Contexto
de hardware
Contexto
de hardware
Espaço de
endereçamento
Co
nt
ex
to
 d
e
so
ftw
ar
e
Thread 3Thread 2Thread 1
Revisitando Processos e 
Threads
Espaço de
endereçamento
Processo
Programa Principal
Co
nt
ex
to
 d
e
Ha
rd
w
ar
e
Co
nt
ex
to
 d
e
Ha
rd
w
ar
e
Co
nt
ex
to
 d
e
Ha
rd
w
ar
e
Call Sub_1
Call Sub_2
Thread_1
Thread_2
Thread_3
PC
SP
PC
SP
PC
SP
Fim
Sub_2
Variáveis
Ret
Sub_1
Ret
...
...
Threads em Sistemas não 
Distribuídos
● Evitar que, ao se executar uma chamada 
bloqueadora, o processo seja bloqueado como
um todo!
E/S
CPU
tempo
E/S
CPU
tempo
Threads em Sistemas não 
Distribuídos
Exemplos????
Threads em SDs
● Em sistemas distribuídos, a utilização de 
threads é atrativa dado que facilitam muito a 
comunicação possibilidade de manter →
múltiplas conexões lógicas ao mesmo tempo
● Exemplo: Uma aplicação P2P, onde é 
necessário receber informações dos vizinhos, 
processar algum algoritmo de decisão de 
mudança de topologia e atender novas 
requisições
Threads em SDs
Ilustração através da Arquitetura 
Cliente-Servidor
 
Clientes Multithreads
● Conforme vimos, sistemas distribuídos que 
operam em redes de grandes distância, devem 
buscar algum mecanismo de ocultar a latência 
de obtenção de informações → Transparência!
● Consideremos um cliente Web...
Como implementar multithreading?
Clientes Multithreads
● Em um browser Web...
● Um documento Web consiste em um grande 
número de objetos 
● A busca de cada objeto de uma página HTML 
será feita após estabelecimento de uma 
conexão TCP
● Estabelecimento e leitura de dados são 
operações bloqueadoras
Clientes Multithreads
● Em um browser Web...
● Com uma conexão persistente com 
paralelismo:
● Requisições são feitas sem que os objetos 
precedentes tenham chegados no cliente
● Cliente é capaz de manipular diversos 
fluxos em paralelo → Threads
Clientes Multithreads
● Caso os dados estejam espalhados por 
diversas réplicas de servidores ...
● A utilização de threads possibilita os 
clientes estabelecerem diversas conexões, 
em paralelo, com o objetivo de disponibilizar 
um único documento
Servidores Multithreads
● Servidor Multithread no modelo despachante/operário
Servidores MultithreadsServidores Multithreads
● Para suportar e possibilitar um melhor 
desempenho de clientes WEB multithreading, 
servidores WEB devem ser implementados para 
suportar múltiplas conexões de diferentes (ou 
dos mesmos) usuários.
Clientes
● Proporcionar aos usuários meios de interagir 
com servidores remotos
● Cliente possui uma aplicação sendo 
executada para cada serviço remoto
● Cliente possui acesso direto a serviços 
remotos usando apenas uma interface de 
usuário
Clientes
Clientes
Cliente possui uma aplicação sendo executada 
para cada serviço remoto
 Exemplo: Agenda sendo executada no PDA de 
um usuário e que precisa entrar em sincronia 
com uma agenda remota, possivelmente 
compartilhada
Clientes
Cliente possui acesso direto a serviços remotos 
usando apenas uma interface de usuário
 
Exemplo: Máquina cliente não possui nenhuma 
informação para processamento, tornando-a 
independente da aplicação clientes →
minimizados facilidade de gerenciamento do →
sistema
Clientes – Sistema X Window (1/4)
● Desenvolvido em 1984 no MIT, é uma das 
interfaces de usuário em rede mais utilizadas
● Usado para controlar terminais mapeados em 
bits
● Servidor distribui as ações de entrada do 
usuário (mouse e teclado) e aceita pedidos desaída através de vários programas clientes
Clientes – Sistema X Window 
(2/4)
● Pode ser visto como a parte de um SO que controla o 
terminal
● Oferece uma interface de nível relativamente baixo, 
para controlar a tela e para capturar os eventos do 
teclado e do mouse biblioteca Xlib→
● Arquitetura Cliente-Servidor: núcleo X recebe 
requisições vindas de diversas aplicações sendo 
executadas.
●Gerenciador de janelas: determina a aparência geral 
do visor
Clientes – Sistema X Window 
(3/4)
● Clientes podem rodar de forma transparente em 
máquinas diferentes → protocolo X de comunicação
● Uma instância de Xlib pode trocar dados e eventos 
com o núcleo X
● Xlib pode enviar requisições ao núcleo X para criar
ou encerrar uma janela, estabelecer cores 
●O núcleo X reagirá a eventos locais (entrada de 
teclado e mouse)
Clientes – Sistema X Window 
(4/4)
Servidores
 Questões gerais de projeto
● Iterativo ou Concorrente?
● Para onde os clientes enviam requisições?
● Como encerrar um serviço?
●Manter ou não o estado de um cliente?
Servidores
● Iterativo ou Concorrente?
● Iterativo: O servidor é implementado através de 
um processo único, retirando a requisição do 
cliente e tratando-a
● Concorrente: O ´processo servidor´ não manipula 
a requisição propriamente dita, mas a passa para 
uma thread separada ou um outro processo.
Servidores
● Para onde os clientes enviam requisições?
● Requisições são enviadas a um processo servidor 
através de uma porta
● Para alguns serviços, são atribuídas portas 
padrão: HTTP 80, FTP 21, SSH 22
● Em alguns casos, pode-se implementar um 
daemon, que ´escuta´ uma porta conhecida e 
redirecina a requisição para a porta do serviço
● No caso Unix, inetd
Servidores
● Para onde os clientes enviam requisições?
Servidores
● Como encerrar um serviço?
● Considere um usuário transmitindo um arquivo via 
ftp e que decide interromper o servidor para 
cancelar a transferência
● Servidor encerra, após um tempo, a conexão
● Servidor possui uma conexão de controle
● Servidor trata, em uma mesma conexão, dados 
urgentes
Servidores
● Manter ou não o estado de um cliente?
● Servidor sem estado: Não mantém informações 
sobre os estados de seus clientes e pode mudar o 
seu estado sem ter que informar a nenhum 
cliente
● Exemplos: Servidor Web, Servidor de 
arquivos
Servidores
● Manter ou não o estado de um cliente?
● Servidor sem estado: Em alguns casos, servidores 
Web podem guardar informações dos clientes
Podemos ter um servidor sem estado, que 
guarde informações de clientes, MAS ESTAS 
INFORMAÇÕES NÃO SÃO ESSENCIAIS PARA 
O FUNCIONAMENTO!!!
Servidores
● Manter ou não o estado de um cliente?
● Servidor com estado: Mantém informações 
persistentes sobre os seus clientes.
● Exemplo: servidor de arquivos que permite um 
cliente manter cópia local de um arquivo →
servidor guarda os clientes que têm permissão 
de mudanças no arquivo antes de atualizá-lo no 
localmente
 1
Sistemas Distribuídos –
Capítulos 3 e 4 - Aula 4
Aula de hoje
Clusters de 
Servidores
Migração de Código
Comunicação (Cap. 
4)
Fundamentos
Aula passada
Threads
Threads em SDs
Processos Clientes
Processos 
Servidores
 
Clusters de Servidores
 Conjunto de máquinas conectadas 
por uma rede, no qual cada máquina 
executa um ou mais servidores. Estas 
máquinas estão conectadas por uma 
rede local, com alta largura de banda 
e baixa latência.
 
Clusters de Servidores
 
Clusters de Servidores - 
Comutador
 Forma o ponto de entrada para o cluster de 
servidores, oferecendo um único endereço de 
rede.
 Considerando TCP, o comutador aceita 
requisições e as transfere a um dos servidores
 Identifica o melhor servidor a tratar a 
requisição
 
Clusters de Servidores - 
Comutador
 
Clusters de Servidores 
Distribuídos
Conjunto de máquinas que possivelmente muda 
dinamicamente, com vários pontos de acesso 
também possivelmente variáveis, mas se 
apresenta ao mundo externo como um única e 
poderosa máquina.
 
Clusters de Servidores 
Distribuídos 
 Vários pontos de acesso
 Estabilidade no acesso
 Alto desempenho 
 Flexibilidade
 
Migração de Código
Em alguns casos é importante migrar código de 
uma máquina para outra
Problema: como fazer esta tarefa em sistemas 
heterogêneos!
 
Por que Migrar Código?
Principal razão: Aumento de 
Desempenho
 
Migração de Código - 
Desempenho 
 Envio de processos de máquinas 
sobrecarregadas para máquinas com cargas 
mais leves
 Evitar grande quantidade de mensagens 
trocadas entre aplicações cliente-servidor:
● Ex.1: operações de banco de dados que 
envolvem uma grande quantidade de 
dados(aplicação cliente servidor)→
● Ex.2: formulários enviados do servidor →
cliente (applets)
 
Modelos para Migração de 
Código
 Migração de código é algo muito mais 
amplo: podemos também migrar status de 
um programa, sinais pendentes e outras 
partes do ambiente 
 
Modelos para Migração de 
Código
 Processo consiste em três segmentos[Fuggeta 
et al 1998]:
● Segmento de código: contém o conjunto de 
instruções que compõem o programa que está 
em execução
● Segmento de recursos: contém referências a 
recursos externos (arquivos, 
impressoras,outros processos, bibliotecas)
● Segmento de execução: armazenar o estado 
em execução de um processo no momento da 
migração (dados privados, pilha,contador de 
programa)
 
Modelos para Migração de 
Código
 Mobilidade pode ser de dois tipos:
● Mobilidade Fraca: possível transferir somente 
o segmento de código, junto com alguns dados 
de inicialização. Requer somente que a 
máquina-alvo possa executar o código 
(portabilidade). Ex: applets Java
● Mobilidade Forte: segmento de execução 
também pode ser transferido. O processo em 
execução pode ser parado e movido para uma 
outra máquina e retomar a execução no ponto 
original. Mais geral, porém mais difícil de ser 
implementada
 
Modelos para Migração de 
Código
 Em relação do ponto de ínicio da migração:
Iniciada pelo remetente: a migração é iniciada 
na máquina em que o código está em execução no 
momento em questão. Ex: enviar programa de 
busca pela Internet a um servidor de banco de 
dados para realização de pesquisas agente →
móvel que passa de site para site
Iniciada pelo destinatário: Iniciativa da 
migração de código é tomada pela máquina-alvo. 
Ex: Applets java
 
Modelos para Migração de 
Código
 
Migração e recursos locais
 Segmentos de recursos requerem uma atenção 
especial O segmento de recurso nem sempre →
pode ser transferido junto com outros 
segmentos sem ser trocado
 Ex.: Comunicação de um processo sendo feita 
através de uma porta TCP. Ao mudar de 
localização, este processo deverá devolver a 
porta e requisitar uma nova no destino
 
Migração e recursos locais
 Três tipos de vinculações processo-recurso 
[Fuggetta et al, 1998]:
● Vinculação por identificador 
● Processo requer exatamente o recurso 
referenciado (URL de um site)
● Vinculação por valor
● É necessário somente um valor
● Se outro recurso fornece o mesmo valor, 
execução não é afetada (bibliotecas 
padronizadas)
● Vinculação por tipo
● Processo requer um recurso de um tipo 
específico (monitores, impressoras)
 
Migração e recursos locais
 Três tipos de vinculações recurso-máquina:
● Recursos não ligados: recursos podem ser 
movidos com facilidade entre máquinas 
diferentes(arquivos de dados)
● Recursos amarrados: recursos podem ser 
movidos ou copiados, mas só a custo 
relativamente alto ( banco de dados locais)
● Recurso fixos: recursos estãointimamente 
vinculados a uma máquina ou ambiente 
especifico e não podem ser movidos →
dispositivos locais
 
Migração em Sistemas 
Heterogêneos
 Migração em sistemas heterogêneos requer
● Que o segmento de código possa ser 
executado em cada plataforma
● Que o segmento de execução possa ser 
adequadamente representado em cada 
plataforma
● Efeito global: Migrar sistema operacional 
inteiro, em vez de migrar processos
 
Comunicação entre Processos
 “Coração” de qualquer Sistema Distribuído
 Como processos em diferentes máquinas 
trocam informações?
● Não é uma tarefa trivial!
 Desejável obter modelos onde a complexidade 
da comunicação seja transparente para o 
desenvolvedor
 
Modelo Cliente-Servidor
 Participantes são divididos em:
● Servidores: implementam um serviço específico
● Clientes: solicitam ao servidor um determinado 
serviço e espera pela resposta
 Comportamento requisição-resposta
 
Protocolos em Camadas
 
Protocolos em Camadas
 
Camada Física
 Responsável pelo envio de bits
 Trata da padronização das interfaces 
elétrica, mecânica e de sinalização
 Protocolos são dependentes do meio de 
transmissão do link
 
Camada Enlace
 Responsável pelo envio de frames entre os 
links
 Característica importante: um datagrama 
pode ser manipulado por diferentes tipos de 
protocolos da camada de enlace: Ethernet 
(CSMA/CD), PPP
 Cada protocolo diferente pode ou não 
implementar um conjunto de serviços. Ex.: 
entrega confiável da informação
 
Camada Rede
 Redes de longa distância são constituídas de 
muitos nós com diferente caminhos entre eles.
 Como definir um caminho entre um par 
origem-destino?
 Roteamento é a principal tarefa da camada de 
rede
 Internet Protocol: protocolo sem conexão, 
onde pacotes são roteados de forma 
independente – best-effort service
 
Camada de Transporte
 Responsável pela comunicação lógica entre 
diferentes processos sendo executados em 
diferentes hosts (fim-a-fim)
 Protocolos da camada de transporte não estão 
implementados nos roteadores
 Pode fornecer os seguintes serviços:
● multiplexing/demultiplexing
● transmissão confiável
● garantias de banda, retardo
 
Protocolos de Transporte na 
Internet
 Transmission Control Protocol (TCP)
● Orientado a Conexão
● Confiável, porém “lento”
 User Datagram Protocol (UDP)
● Sem conexão
● “Rápido”, porém não confiável
Escolha está ligada as caracteristicas da aplicação!
 
Camada de Aplicação
 Distinção entre aplicação para redes e protocolos da 
camada de aplicação
● Protocolo: pequena (talvez grande) peça de uma 
aplicação
● Ex.1: Aplicação WEB HTTP→
● Ex.2: Aplicação Email SMTP→
 Protocolos definem: tipos de mensagens trocadas, 
sintaxe
 
Camada de Middleware
 Camada de software que é situada logicamente entre 
uma camada de nível mais alto, composta de usuários 
e aplicações e uma camada subjacente, que consiste 
de facilidades básicas de comunicação
 Inúmeros protocos para suportar serviços de 
middleware:
● Autenticação: não estão vinculados a uma aplicação
● Comprometimento
● Comunicação: Serviços de comunicação de alto nível
 
Camada de Middleware
 
(Sockets)
 Como os processos executando em diferentes 
máquinas trocam informação? 
● Em uma visão pilha de protocolos TCP/IP Enviando →
mensagens através da utilização de sockets
 Socket: ponto final de uma comunicação full-duplex 
entre dois processos
● Processo casa / Socket Porta→ →
● Socket: Porta entre o processo da aplicação e o 
protocolo de transporte
 
(Sockets)
 Informações são string de bytes, sem significado 
aparente
 Não existe a transparência de distribuição: toda a 
comunicacão está está explícita, através de 
procedimentos send e receive
● Funções mais sofisticadas devem ser feitas na camada de 
aplicação
Por que não oferecer comunicação de alto nível, 
independente da aplicação?
 
Solução!
Middleware de comunicação
 Tipos:
● Chamadas de Procedimento Remoto
● Comunicação orientada a Mensagens
● Comunicação orientada a fluxo
 
Tipos de Comunicação 
(Middleware)
 Persistência
● Persistente: Mensagem é armazenada pelo 
middleware de comunicação durante o tempo que 
for necessário para entregá-la ao receptor 
(Servidor de emails)
● Transiente: Mensagem é armazenada somente 
durante o tempo em que a aplicação remetente e a 
aplicação receptora estiverem executando
 
Tipos de Comunicação 
(Middleware)
 Sincronização
● Assíncrona: Remetente continua sua execução 
imediatamente após ter apresentado sua mensagem 
para transmissão
● Síncrona: Remetente é bloqueado até saber que sua 
requisição foi aceita
● Middleware avise que se encarregará da 
transmissão
● Requisição ser entregue ao receptor
● Até o instante que o receptor retornar uma 
resposta
 
Tipos de Comunicação 
(Middleware)
 Granularidade
● 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 uma com as outras pela ordem ou 
pela relação temporal
 1
Sistemas Distribuídos –
Capítulo 4 - Aula 5
Aula de hoje
Chamada de 
Procedimento 
Remoto - RPC
Aula Passada
Clusters de 
Servidores
Migração de Código
Comunicação (Cap. 
4)
Fundamentos
 
Chamada de Procedimento Remoto
 Birrell and Nelson (1984)
“Permite a processos chamar 
procedimentos localizados em outras 
máquinas”
Desenvolvedor 
não precisa se preocupar mais com 
detalhes de implementação de rede 
(sockets nunca mais!)
Conceitualmente simples, mas...
 
Chamada de Procedimento 
Remoto - RPC
 Problemas
● Arquiteturas de duas máquinas podem ser 
diferentes
● Espaço de endereçamento diversos
● Passagem de parâmetros
 
Chamada de Procedimento 
Remoto - RPC
A idéia fundamental é fazer com que uma 
chamada de procedimento remoto pareça com 
uma chamada local
Transparência 
 
Chamada de Procedimento 
Remoto - Modelo
Similar ao modelo de chamadas locais de procedimentos
●Rotina que invoca o procedimento coloca os argumentos em 
uma área de memória bem conhecida e transfere o controle 
para o procedimento em execução, que lê os argumentos e os 
processa. 
●Em algum momento, a rotina retoma o controle, extraindo o 
resultado da execução de uma área bem conhecida da 
memória. Após isso, a rotina prossegue com a execução 
normal.
 
 
Chamada de Procedimento 
Remoto - Modelo
● Thread é responsável pelo controle de dois processos: 
invocador e servidor. O processo invocador primeiro manda 
uma mensagem para o processo servidor e aguarda (bloqueia) 
uma mensagem de resposta. 
● A mensagem de invocação contém os parâmetros do 
procedimento e a mensagem de resposta contém o resultado 
da execução do procedimento. Uma vez que a mensagem de 
resposta é recebida, os resultados da execução do 
procedimento são coletados e a execução do invocador 
prossegue.
 
 
Chamada de Procedimento 
Remoto - Modelo
Do lado do servidor, um processo permanece em espera até a 
chegada de uma mensagem de invocação. Quando uma 
mensagem de invocação é recebida, o servidor extrai os 
parâmetros, processa-os e produz os resultados, que são 
enviados na mensagem de resposta. O servidor, então, volta 
a esperar por uma nova mensagem de invocação.
 
 
Chamada de Procedimento 
Remoto - Modelo
 
Chamada de Procedimento 
Remoto - Modelo
Uma chamada remota de procedimento difere das chamadas 
locais em alguns pontos:
●Tratamento de erros: falhas do servidor ou da rede devem ser 
tratadas.●Variáveis globais e efeitos colaterais: Uma vez que o servidor 
não possui acesso ao espaço de endereços do cliente, argumentos 
protegidos não podem ser passados como variáveis globais ou 
retornados.
●Desempenho: chamadas remotas geralmente operam a 
velocidades inferiores em uma ou mais ordens de grandeza em 
relação às chamadas locais.
●Autenticação: uma vez que chamadas remotas de procedimento 
podem ser transportadas em redes sem segurança, autenticação 
pode ser necessário.
 
 
Operação Básica de RPC
 Chamada de procedimento convencional
 count = read (fd, buf, nbytes)
 fd descritor de um arquivo→
 buf vetor para o qual os caracteres serão →
lidos
 nbytes quantos bytes serão lidos→
 
Operação Básica de RPC
 Chamada de procedimento convencional
– Em C, parâmetros podem ser chamados por 
valor ou chamados por referência
 Em RPCs 
– A diferença entre chamadas por valor e por 
referência é importante
– Outro mecanismo de passagem de 
parâmetros é o copiar/restaurar: 
“chamador” copia a variável para a pilha e ao 
copiá-la de volta, sobreescreve o valor 
original semelhante a chamada por →
referência
 
Operação Básica de RPC
 Consideremos a chamada da função read
– Em um sistema tradicional, a função read é um tipo 
de interface entre o código de usuário e o sistema 
operacional local
 Usando RPC, é possível conseguir transparência na 
execução da função read
– Por ser um procedimento remoto, uma versão 
diferente da função read, denominada apêndice de 
cliente é colocada na biblioteca
– Ela não pede por dados ao SO local. Empacota os 
parâmetros em uma mensagem e a envia ao servidor
 
Operação Básica de RPC
 Usando RPC, é possível conseguir transparência na 
execução da função read
– Apêndice de cliente chama receive, bloqueando até 
que a resposta volte
– Quando a mensagem chega ao servidor, o SO do 
servidor a passa para um apêndice do servidor
– O apêndice de servidor desempacota os parâmetros 
da mensagem e chama o procedimento do servidor 
da maneira usual
 
Operação Básica de RPC
 Usando RPC, é possível conseguir transparência na 
execução da função read
– Do ponto de vista do servidor, é como se ele fosse 
chamado diretamente pelo cliente
– No caso de read o servidor colocará os dados no 
buffer, interno ao apêndice de servidor
– Ao final, empacota o buffer em uma mensagem e 
retorna o resultado ao cliente
– Ao chegar no cliente, o SO reconhece que a msg 
está direcionada ao processo cliente
– Msg é copiada para o buffer e o processo cliente é 
desbloqueado
 
Operação Básica de RPC
 
Operação Básica de RPC
Transparência conseguida com o uso de stubs 
(apêndices)
 Stub do cliente responsável por empacotar os 
parâmetros em uma msg e enviar a msg para a 
máquina do servidor. Quando resposta chega, 
resultado é copiado para cliente, e controle volta a 
ele
 Stub do servidor responsável por desempacotar 
parâmetros, chamar o procedimento do servidor e 
retornar resposta para máquina do cliente
 
Operação Básica de RPC
Cliente
Chamada Empacota
Parâmetros
Desempacota
ResultadoRetorno
Desempacota
Parâmetros
Servidor
Empacota
Resultado
Chamada
Retorno
Máquina Cliente Máquina Servidora
Stub do ServidorStub do Cliente
Transporte de 
mensagens
na rede
SO SO
 
Passos seguidos por um RPC
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
 
Passagem de Parâmetros
 Função do stub do cliente é pegar seus parâmetros, 
empacotá-los em uma mensagem e enviá-los ao stub do 
servidor (montagem de parâmetros - parameter 
marshaling).
Operação parece simples, mas:
Arquiteturas diferentes? 
Passagem de ponteiros (diferente espaço de 
endereçamento)?
 
Passagem de Parâmetros por 
valor
 
 Passagem de parâmetros por 
valor
 A chamada do procedimento remoto add somente 
funcionará se as máquinas do cliente e do servidor 
forem idênticas
 Problemas:
– Representação diferentes para caracteres 
– Ordenação de bytes
 
 Passagem de parâmetros por 
valor
 
 Passagem de parâmetros por 
valor
 Solução: Cliente diz seu tipo. Conversão feita pelo 
servidor se tipos forem diferentes.
 
 Passagem de parâmetros por 
referência
 Como são passados ponteiros ou, em geral, 
referências?
Um ponteiro somente é significativo dentro do 
espaço de endereço do processo no qual está sendo 
usado!
 
Passagem de parâmetros por 
referência
 Consideremos a função read, stub do cliente “sabe” que o 
segundo parâmetro aponta para um conjunto de caracteres
 Suponha que o cliente saiba o tamanho do vetor
 Solução Copiar/restaurar: →
– Copiar o vetor para a mensagem e enviar ao servidor
– Stub do servidor, chama o servidor com um ponteiro para 
este vetor
– Modificação feita pelo servidor é armazenada diretamente 
no vetor que está no stub
– Ao enviar o vetor de volta ao stub do cliente, o vetor é 
copiado de volta ao cliente
 
 Linguagem de Programação de 
Interface - IDL
 Interface consiste em um conjunto de 
procedimentos que podem ser chamados por um 
cliente e que são implementados por um servidor
 Utilização de interface simplifica consideravelmente 
aplicações cliente-servidor baseadas em RPCs
 Gerar completamente stubs de cliente e servidor - 
todos os sistemas de middleware baseados em RPC 
oferecem uma IDL para suportar desenvolvimento de 
aplicação
 
Possíveis falhas em RPCs
 O cliente não consegue localizar o servidor
 A mensagem de requisição do cliente para o 
servidor é perdida
 A mensagem de resposta do servidor para o 
cliente é perdida
 O servidor falha depois de receber uma 
requisição
 O cliente falha depois de fazer uma requisição
 
Possíveis falhas em RPCs
 O cliente não consegue localizar o servidor
– Causas:
• Servidor Desligado
• Versão desatualizada da interface
– Soluções
• Retornar o código indicando erro
• Ativar exceção: destroir a transparência
 
Possíveis falhas em RPCs
 A mensagem de requisição do cliente para o 
servidor é perdida
– Soluções
• Kernel do cliente inicializa um timer assim 
que a mensagem é enviada
• Se o timer expirar antes da resposta, o 
cliente re-envia a mensagem
 
Possíveis falhas em RPCs
A mensagem de resposta do servidor para o 
cliente é perdida
 
RPC Assíncrona
 Chamadas de procedimentos convencionais →
cliente bloqueia até que uma resposta seja 
retornada
 RPCs podem implementar facilidades pelas 
quais um cliente continua imediatamente após 
emitir a requisição RPC → RPCs assíncronas
 
RPC Assíncrona
 1
Sistemas Distribuídos –
Capítulo 4 - Aula 6
Aula de hoje
Comunicação 
orientada a 
mensagem
Comunicação 
orientada a fluxo
Aula Passada
Chamada de 
Procedimento 
Remoto - RPC
 
RPC/RMI
 Contribuem para ocultar comunicação em SDs →
transparência
 Nem sempre são eficientes:
– Comunicação transiente
– Natureza síncrona
 
Comunicação orientada a 
mensagem
Mensagens podem ser trocadas quando processos 
estão ou não em funcionamento (existe a 
possibilidade de armazenamento para posterior 
tratamento)
Execução deoutras atividades enquanto a requisição 
ainda não tenha sido tratada (comunicação 
assíncrona) 
 
Interface de Troca de 
Mensagens (MPI)
 Com multicomputadores de alto desempenho, 
desenvolvedores começaram a procurar primitivas 
orientadas a mensagem
– Escrever com facilidade aplicações eficientes →
primitivas devem estar em nível conveniente de 
abstração, facilitando o desenvolvimento, com 
sobrecarga mínima caso devam ser implementadas
 
Interface de Troca de 
Mensagens (MPI)
 Por quê não sockets?
– Não proporciona transparência
– Não são adequados para os protocolos proprietários 
desenvolvidos para redes de interconexão de alta 
velocidade, usadas em clusters de servidores de alto 
desempenho 
 
Interface de Troca de 
Mensagens (MPI)
 Inicialmente, bibliotecas prioritárias de trocas de 
mensagens eram incorporadas aos multicomputadores de 
alto desempenho
 Evolução natural: definição de um padrão para troca de 
mensagens, independente de hardware e de plataforma
MPI Message Passing Interface Interface de Troca → →
de Mensagens
 
Interface de Troca de 
Menssagens (MPI)
 Projetada para aplicações paralelas comunicação →
transiente
 Uso direto da rede subjacente
 Falhas sérias, como quedas de processos ou rede, são 
fatais e não requerem recuperação automática
 
Interface de Troca de 
Menssagens (MPI)
 Comunicação ocorre dentro de um grupo conhecido de 
processos
 Cada grupo recebe um identificador. Cada processo 
dentro de um grupo também recebe um identificador 
local
 (groupID,processID) identifica exclusivamente a →
fonte ou o destinatário de uma msg e é usado no lugar de 
um endereço de nível de transporte 
 
Interface de Troca de 
Menssagens (MPI)
 Primitivas Mais de 100 funções diferentes para troca →
de mensagens:
 MPI_recv recebimento de mensagem; 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
 
 
Comunicação Persistente 
Orientada a Mensagem
 Sistemas de Enfileiramento de Mensagens
– Middleware orientado a Mensagem (MOM)
– Proporcionam suporte extensivo para 
comunicação assíncrona persistente
– Oferecem capacidade de armazenamento 
de médio prazo para as mensagens
– Não exigem que o remetente ou o receptor 
estejam ativos durante a transmissão da 
mensagem
 
Comunicação Persistente 
Orientada a Mensagem
 Sistemas de Enfileiramento de Mensagens
– Visam ao suporte de transferências de 
mensagens têm permissão de durar minutos 
em vez de segundos ou milissegundos (como 
nos casos de sockets ou MPI)
 
Comunicação Persistente 
Orientada a Mensagem
Exemplo: Consulta que abranja vários bancos de 
dados pode ser repartida em subconsultas que 
são repassadas para bancos de dados individuais.
 Sistemas de enfileiramento de mensagens 
ajudam fornecendo meios básicos para 
empacotar cada subconsulta em uma 
mensagem e roteá-la até o banco de dados 
adequado.
 
Modelo de Enfileiramento 
de Mensagens
 Aplicações se comunicam inserindo mensagens em filas 
específicas.
 Mensagens são repassadas por uma série de servidores 
de comunicação, antes de serem entregues ao 
destinatário
– Na prática, a maioria dos servidores estão 
diretamente conectados uns aos outros
 Cada aplicação tem sua fila particular para a qual 
outras aplicações podem enviar mensagens
 
Modelo de Enfileiramento 
de Mensagens
 Remetente só tem a garantia de que, a certa altura, 
sua mensagem será inserida na fila do receptor
 Nenhuma garantia é dada sobre quando e nem se a 
mensagem será realmente lida ações totalmente →
determinadas pelo comportamento do receptor
 Remetente e o receptor podem executar em completa 
independência um em relação ao outro
 Tão logo uma mensagem tenha sido depositada em uma 
fila, permanecerá até ser removida, independentemente 
de seu remetente ou receptor estar em execução
 
Modelo de Enfileiramento 
de Mensagens
 
Modelo de Enfileiramento 
de Mensagens
 Características das mensagens
– Mensagens podem conter qualquer tipo de dado
– Mensagens devem ser adequadamente endereçadas
– O endereçamento é feito com o fornecimento de um 
nome exclusivo da fila destinatária no âmbito do 
sistema
 
Modelo de Enfileiramento 
de Mensagens
 
Arquitetura de um Sistema 
de Enfileiramento de 
Mensagens
 Filas 
– Mensagens somente podem ser colocadas em filas 
locais do remetente, na mesma máquina ou em uma 
máquina na mesma LAN → filas de fonte
– Mensagem colocada em uma fila contém a 
especificação de uma fila de destino
– Sistema de enfileiramento é responsável por 
fornecer filas para remententes e receptores e 
providenciar para que as msg sejam transferidas de 
sua fila de fonte para a fila de destino
 
Arquitetura de um Sistema 
de Enfileiramento de 
Mensagens
 Filas 
– Sistema de enfileiramento deve manter mapeamento 
de filas para localizações de rede, similar ao serviço 
de DNS
 
Arquitetura de um Sistema 
de Enfileiramento de 
Mensagens
 Gerenciador de Filas 
– Interage diretamente com a aplicação que está 
enviando ou recebendo uma mensagem
 Repassadores
– Gerenciadores especiais, que funcionam como 
roteadores
– Sistema de enfileiramento pode crescer 
gradativamente até uma rede de sobreposição de 
nível de aplicação
– Podem ser usados para multicasting
 
Arquitetura de um Sistema 
de Enfileiramento de 
Mensagens
 
Sistemas de Enfileiramento 
versus Email
 Sistemas de E-mail:
– Requisitos de filtragem automática de 
mensagens
– Não precisam garantir entrega de 
mensagens, prioridades de mensagens, 
facilidades de registro, balanceamento de 
carga, tolerância a falha
 
Sistemas de Enfileiramento 
versus Email
 Sistemas de Enfileiramento de Mensagens
– Fornece recursos mais amplos para 
tratamento de diversas aplicações 
diferentes
– Possibilitam comunicação persistente entre 
processos
– Manipulam acesso a banco de dados
– Realizam cálculos
– Prioridades de mensagens
 
 Até o momento...
 Troca de unidades de informação mais ou menos 
completas e independentes
 Ex: Requisição para invocar um procedimento
Quais são as facilidades que um sistema distribuído 
deve oferecer para trocar informaçõees 
dependentes de tempo (fluxos de áudio e vídeo)?
TEMPO É CRUCIAL!!!
 
 Comunicação Orientada a Fluxo – 
Tipos de Fluxo
 Fluxos Simples 
– Sequência simples de dados.
– Ex: Voz
 Fluxos “Complexos” 
– Consiste em vários fluxos simples relacionados 
denominados subfluxos
– Relação temporal entre os subfluxos
– Ex: Transmissão de um filme: vídeo,som, legenda
 
Qualidade de Serviço (QoS)
 Requisitos que descrevem o que é necessário para 
garantir que as relações temporais em um fluxo 
possam ser preservadas
 Está relacionada com:
– Pontualidade
– Volume
– Confiabilidade
 Sistemas operacionais e redes não suportam QoS!!! →
Serviço IP é best-effort
 
Como garantir QoS?(1)
 Serviço Diferenciados
 Bufferização para reduzir variância de atraso no 
receptor
 
Como garantir QoS?(2)
 Correção de Erro de Envio (Forward Error Correction 
- FEC)
 1
Sistemas Distribuídos –
Capítulo 4 - Aula 7
Aula passada
Comunicação 
orientada a 
mensagem
Comunicação 
orientada a fluxo
Aula de hoje
Comunicação 
Multicast
 
Comunicação Multicast – 
Camada de Rede
 Diferente da comunicação broadcast, onde todos os 
nós de uma rede recebem um pacote, na comunicação 
multicast o pacoteé entregue a apenas um subgrupo 
de nós na rede
 Na Internet, o identificador único que representa um 
grupo de destinatários é um grupo multicast classe D
 Como endereçar os pacotes dentro do subgrupo? Como 
fazer o gerenciamento dos nós do subgrupo? Como os 
nós da rede interagem para entregar um datagrama 
multicast a todos os membros do grupo?
 
Comunicação Multicast – 
Camada de Rede
 Todo o gerenciamento é feito pelo Protocolo de 
Gerenciamento de Grupo da Internet (IGMP)
– Opera entre o host e o roteador diretamente 
conectado a ele
 
Comunicação Multicast – 
Camada de Rede
 O IGMP provê os meios para que um host informe ao 
roteador conectado a ele que uma aplicação que está 
funcionando no host quer se juntar a um grupo 
multicast
 Dado que o escopo de interação do IGMP é limitado a 
um host e seu roteador conectado, um outro 
protocolo deve ser usado para coordenar os 
roteadores multicast por toda a Internet 
(PIM,DVMRP,MOSPF)
 Investimento em infra-estrutura, gerenciamento
 ISPs se mostravam relutantes em suportar 
multicasting
 
Comunicação Multicast – 
Camada de Aplicação
 Já que o multicast na camada de rede é 
extremamente custoso em questões de investimento, 
por que não transferir esta funcionalidade para a 
camada de aplicação?
 
Comunicação Multicast – 
Camada de Aplicação
 Com o advento das aplicações P2P:
– Novas técnicas de gerenciamento de redes de 
sobreposição (overlays) foram propostas
– Juntamente com as técnicas de gerenciamento, 
diversos algoritmos para difusão das mensagens (ou 
conteúdo) também foram propostos 
 
Comunicação Multicast – 
Camada de Aplicação
 Idéia Básica: 
– Nós se organizam em uma rede de sobreposição, usada 
para disseminar informações para os seus membros
– Os roteadores da rede física NÃO fazem parte do 
overlay de difusão das informações
Conexões entre nós no overlay podem cruzar vários 
enlaces físicos!
 
Comunicação Multicast – 
Camada de Aplicação
 Questões principais:
 
 Como construir o overlay para obter robustez, diminuir o 
atraso de difusão (explorando, por exemplo características 
dos peers ou de localização geográfica)
 
 Como difundir o conteúdo de maneira eficiente
 
Comunicação Multicast – Overlay
 
 
 
 Estruturas possíveis
– Árvore: Um único caminho entre cada par de nós. 
• Reorganização da estrutura a cada entrada/saída de 
um nó
• Baixa resiliência: a saída de um nó desconeta outros 
nós 
– Mesh: Neste tipo de orvelay, os nós se organizam em 
uma malha, com a existência (com grande 
probabilidade), de vários caminhos entre pares de nós
• Alta resiliência
 
Comunicação Multicast – Overlay
 
 
 
 Árvore
– Construir uma árvore qualquer não é uma tarefa crítica!
– Construir uma árvore eficiente é uma tarefa crítica!
– Problema: roteamento lógico versus roteamento físico
 
Comunicação Multicast – Overlay
 
 
 
 Qualidade da Árvore
Estresse de enlace: Quantas vezes uma mensagem atravessa o 
mesmo enlace? Exemplo: mensagem de A a D atravessa Ra,Rb 
duas vezes 
Penalidade de atraso relativo: Razão entre o atraso entre dois 
nós na sobreposição e o atraso que esses dois nós sofreriam na 
rede subjacente. Exemplo: mensagens de B a C possuem um 
atraso de 71 no overlay, mas de 47 no nível de rede, que gera 
uma penalidade de 1.51
Custo da árvore: parâmetro de medição global, relacionado com 
a minimização dos custos agregados de enlaces. Exemplo: atraso 
entre dois nós finais → spanning tree
 
Comunicação Multicast – Overlay
 
 
 
 Mesh
– Diferentes grafos podem ser usados
– Grafos aleatórios: Nenhum tipo de informação é 
usado para contruir topologias mais eficientes
– Grafos “com inteligência”: Neste caso, podemos 
considerar informações como banda dos nós ou 
localização geográfica (através do RTT, por 
exemplo) para construção da topologia
 
Comunicação Multicast – Overlay
 
 
 
 Mesh
– Grafos aleatórios também sofre de perda de 
desempenho (roteamento lógico versus roteamento 
físico)
• Usuário: maior atraso para entregua do conteúdo 
• ISP: envio desnecessário de conteúdo via outros 
ISPs
 
Resultado 2: Construção do 
Overlay (Lobb et al, 2009)
Problema: Contruir o overlay de difusão da 
informação de maneira a explorar os peers 
com grande banda de upload, diminuindo o 
tempo para difusão da informação
Idéia Básica: Peers com alta banda são 
“empurrados” para perto da fonte, criando um 
“backbone” de difusão da informação
Característica importante: A banda de upload 
dos peers é estimada indiretamente, 
considerando o total de chunks enviados até o 
instante de tempo atual
 
Adaptando o Overlay... (I)
O algoritmo é realizado independentemente 
por cada peer p
A cada δ chunks, o peer p ajusta a sua 
vizinhança aumentando-a ou diminuindo-a.
A decisão de crescimento ou diminuição é 
baseada na fração dos links de saída utilizados
 
Adaptando o Overlay...(II)
O que fazer?
1) Se, durante δ, p enviou pelo menos um chunk 
a um grande número de vizinhos, assumimos 
que p pode “alimentar” mais vizinhos e uma 
fração de novos peers, vizinhos dos vizinhos, 
são acrescentados a vizinhança de p
2) Caso contrário, se p enviou chunks a uma 
fração pequena de vizinhos, a vizinhança de p 
é diminuída
 
Simulação 
1) O overlay é formado por 10,000 peers, com 
quatro classes diferentes
 Classe 1 – 10% - 5Mbs +- 10%
 Classe 2 – 40% - 1Mbs +- 10%
 Classe 3 – 40% - 0.5Mbs +- 10%
 Classe 4 – 20% - 0Mbs 
2) Fonte é um peer especial, com 5.5Mbs de 
banda de upload. Um total de 10.000 chunks é 
 “empurrado” através do overlay
 
Questões
Já que o algoritmo é 
adaptativo, ele converge?
Como os peers se conectam? 
Existe preferência entre os 
peers, para a construção da 
vizinhança?
Qual o desempenho 
comparado com a topologia 
aleatória?
? ? ?
?? ?
 ? ? ?
? ?
 
Convergência
 
Vizinhos em cada Classe
C las s e 
1
C la s s e 
2
C la s s e 
3
C la s s e4 Deg ree
Fonte 33 44 22 1 116
C las s e 
1
26 42 30 2 121
C las s e 
2
20 35 37 8 15
C las s e 
3
20 31 37 11 7
 
Overlay Adaptativo v.s. Aleatório
 
Comunicação Multicast – Difusão de 
Dados
 
 
 
 Protocolos Epidêmicos
– Propagar as informações rapidamente entre um grande 
conjunto de nós usando somente informações locais
– Não existe nenhum componente centralizado para 
gerenciar a difusão da informação 
 
Comunicação Multicast – Difusão de 
Dados
 
 
 
 Questões importantes:
– Qual o conteúdo a ser enviado?
– Qual nó escolher para entregar o conteúdo?
 
Resultado 1: Algoritmos de 
Escalonamento (Silva et al, 2008)
Cada peer gerencia:
- Uma lista de vizinhos, para troca de chunks
 - Uma janela de chunks que podem ser 
distribuídos aos vizinhos
O Sistema:
Peers possuem banda de download infinita e 
banda de upload finita
Cada peer decide qual o chunk e qual o vizinho 
baseado somente em informações locais
 
Objetivos
Problema: Encontrar estratégias para 
disseminar chunks e selecionar os vizinhos que 
tornem o sistema eficiente (baixo retardo, 
baixa perdas)
Ideia Básica: Dado que a banda de upload é 
limitada, a capacidade de upload determina o 
desempenho do sistema.
 
Explorar, da melhor maneira possível, a banda 
de upoload dos peers
 
Bandwidth-Aware
Explorar a banda de upload da melhor 
maneira possível: Fazer com que os peers 
contribuem com a difusão do conteúdo 
baseado na banda de upload decada um.
Seleção de um peer antes do envio de um 
chunk: enviar o chunk ao vizinho com maior 
taxa de upload
 
Descrição do Sistema
(1) Chunks possuem tamanho constante L
(2) Peer p tem banda de upload u(p)
(3) Cada peer possui uma lista dos vizinhos e 
conhece a banda de upload de cada um
(4) Cada peer possui uma pequena janela 
deslizante w 
(5) Cada peer sabe o conteúdo da janela dos 
vizinhos
 
Descrição do Sistema (cont.)
(6) A topologia é descrita por um grafo 
aleatório, onde as arestas são definidas 
aleatoriamente 
(7) Cada peer seleciona k vizinhos aleatórios
(8) Churning não é levado em consideração
 
Bandwidth-Aware
Cada peer decide localmente
 (1) O chunk a ser distribuído
 (2) O vizinho que receberá o chunk
Escolha do chunk
 O chunk escolhido é o último gerado 
pela fonte (maior identificador) – latest 
chunk first proposto por Fabien et al.
Escolha do vizinho
 Bandwidth-aware 
 
Bandwidth-Aware (cont.)
Qual a estratégia?
 Selecionar o peer com a probabilidade 
proporcional a sua banda de upload
Bandwidth-aware tende entregar o chunk 
aos peers que contribuem mais 
significantemente ao processo de difusão:
 (1) Chunk j é enviado ao peer p somente 
se este não o tem
 (2) Se o chunk j não pode ser enviado, o 
próximo chunk na janela é escolhido
 
Simulação
(1) Simulação dividida em duas fases: geração 
da topologia e disseminação dos chunks
(2) Chunks são gerados a uma taxa de 1 
chunk/s com tamanho de L = 0.3 Mb
(3) Upload da fonte de informação = 1 Mbps
(4) Peers são divididos em 3 classes
P1 com taxa de upload [0.18,0.22] Mbps
 P2 com taxa de upload [0.3,0.4] Mbps
 P3 com taxa de upload [3,4] Mbps
 
Simulação (cont.)
 Medidas de desempenho
Retardo: Intervalo de tempo entre a geração 
do chunk na fonte e a chegada do mesmo no 
peer; valor médio e a distribuição do 99-
ésimo percentile para todos os peers
Perdas: Porcentagem de chunks perdidos
Melhoria do valor médio do 99-ésimo 
percentile e a porcentagem de perdas
 
Bandwidth-Aware vs Aleatório
 Objetivo: Comparar Bandwidth-Aware com a 
seleção aleatória de um peer
(1) Overlay com 1,000 peers
7% em P3 – alta banda de upload
 27% em P1 – baixa banda de upload
(2) 25 topologias diferentes, escolhidas 
aleatoriamente
(3) 200 chunks são distribuídos e w = 5
 
Bandwidth-Aware vs Aleatório 
(cont.)
Por que o desempenho de B têm uma grande melhoria?
Na estrutura da topologia, peers com maior banda 
de upload são vizinhos da fonte ou
estão a poucos passos.
Clusterização virtual!!
 
Bandwidth-Aware vs Aleatório 
(cont.)
Perdas diminuem quando Bandwidth-Aware é 
aplicada
 - O número de peers que perdem reduz em 
um fator de 2 para o overlay A e 3 para o B
 1
Sistemas Distribuídos –
Capítulo 5 - Aula 8
Aula passada
Prova
Aula de hoje
Comentários Prova
Nomes, 
Identificadores, 
Endereços
Nomeação Simples
Nomeação Estruturada
 
Nomeação
 Nomes:
– Compartilhar recursos
– Identificar entidades de maneira única
– Fazer referência a localizações
 Nome deve ser resolvido para a entidade à qual se 
refere
– Sistema de Nomeação (ex. DNS)
 Em um SD, a implementação de um sistema de 
nomeação costuma ser distribuída por várias máquinas
– Modo como é feita a distribuição desempenha papel 
fundamental na eficiência e escalabilidade do 
sistema
 
Nomes, Identificadores e 
Endereços
 Entidades: Máquinas, impressoras, discos, 
processos, usuários, páginas Web, janelas 
gráficas, mensagens, etc.
 São acessadas através de um ponto de acesso , 
ou simplesmente, endereço
– Ex: Servidor e seu número IP
 Portanto, um endereço pode ser utilizado como 
uma maneira de nomear, identicar uma entidade
– Problema: Entidade pode mudar facilmente 
de ponto de acesso! 
– Ex: Servidor Web alocado em outra rede
 
Nomes, Identificadores e 
Endereços
Como nomear entidades, sem utilizar 
especificamente seu endereço, ou seja, 
nomeá-las independentemente da sua 
posição física (localização)?
Identificadores ou Nomes amigáveis a 
seres humanos
 
 
Identificadores 
 Em muitos casos, são cadeias aleatórias de bits, 
com as seguintes propriedades:
– Um identificador referencia, no máximo, 
UMA entidade
– Cada entidade é referenciada por, no 
máximo, um identificador
– Um identificador sempre referencia a mesma 
entidade, isto é, nunca é reutilizado
 Ex: Identificadores de entidades em sistemas 
P2P baseados no sistema Chord
 
Nomes amigáveis
 Nomes representados por uma cadeia de 
caracteres
– Pathnames, domínios na Internet, números de 
processos
• Ex: /etc/passwd; http://www.ufjf.br
Como resolvemos nomes e 
identificadores para endereços?
 
Sistemas de Nomeação
 Mantém uma vinculação nome-endereço
 Na forma mais simples
– Tabela de pares (nome,endereço)
– Contudo, sistemas que abrangem redes de 
grande porte, uma tabela centralizada não 
vai funcionar
 Em SDs, usualmente o nome é decomposto em 
várias partes, e a resolução é realizada por meio 
de consultas recursivas 
 
Sistemas de Nomeação
 Três Classes
– Nomeação Simples
– Nomeação Estruturada
– Nomeação Baseada em Atributo
 
Nomeação Simples
 
 
 
 Aplicada a identificadores
– Cadeias aleatórias de bits nomes simples→
– Não contém sequer uma informação sobre 
como localizar o ponto de acesso de uma 
entidade associada
 
Nomeação Simples
 
 
 
 Problema: Dado um identificador, como localizar 
o ponto de acesso (endereço)?
 
 - Soluções Simples (broadcasting)
– Tabelas de Hash Distribuídas (DHT)
 
Nomeação Simples – Broadcasting 
e Multicasting
 
 
 
 Consideradas soluções simples
 Aplicáveis somente a redes locais
 
Nomeação Simples – Broadcasting 
 
 
 
 Recursos oferecidos por redes locais nas quais 
todas as máquinas estão conectadas a um 
único cabo ou seu equivalente lógico
 Como funciona?
– Mensagem que contém o identificador da 
entidade é enviada a todos as máquinas da 
rede
– Cada uma das máquinas verifica se tem esta 
entidade
– Máquinas com ponto de acesso para a 
entidade, enviam uma msg que contém o 
endereço 
 
Nomeação Simples – Broadcasting 
 
 
 
 Se torna ineficiente quando a rede cresce
– Largura de banda da rede é desperdiçada, 
com grande número de mensagens de 
requisição
– Aumento da probabilidade de colisões de 
mensagens, diminuindo o throughput do 
sistema
– Grande número de máquinas pode ser 
interrompido por requisições que não podem 
responder 
 
Nomeação Simples – Multicasting 
 Somente um grupo restrito de máquinas 
recebe a requisição
 Banco de Dados Replicado
– Endereço multicast é associado a uma 
entidade replicada
– Multicasting é usado para localizar a réplica 
mais próxima
– Requisição para o endereço multicast, cada 
réplica responde com seu endereço IP
– Réplica mais próxima aquela cuja resposta →
chega antes
 
Tabelas de Hash Distribuídas 
(DHT) 
 Exemplo: Nós são organizados logicamente em 
um anel (Chord)
– Usa um espaço de identificadores de m bits 
para designar nós e entidades específicas 
(arquivos, processos)
– Número m bits é usualmente 128 ou 160
– Entidade com chave k cai sob a jurisdição 
do nó que tenha o menor identificador id >= 
k succ(k)→
 
Tabelas de Hash Distribuídas 
(DHT) 
Como resolver com eficiência uma chave k 
para o endereço de succ(k)? 
 Abordagem linear
 Tabela de Derivação
 
Tabelas de HashDistribuídas 
(DHT) 
 Abordagem linear
– Cada nó p monitora o sucessor succ(p+1) e 
o predecessor pred(p)
– Ao receber uma requisição para a chave k, p 
repassa a requisição para os seus vizinhos, a 
menos que pred(p) < k <= p → p retorna o 
próprio endereço
– Não escalável!
 
Tabelas de Hash Distribuídas 
(DHT) 
 Tabela de derivação (finger table)
– Possui, no máximo, m entradas
– Denotando a tabela de derivação de p por 
Ftp
 Ftp[i]=succ(p+2 i -1)
i-ésima entrada aponta para o primeiro nó que 
sucede p por no mínimo 2 i -1
 
Tabelas de Hash Distribuídas 
(DHT) 
a) Suponhamos que
p = 4 receba uma requisição
para k = 7 succ(p+1) → →
 repassa a 
requisição ao nó = 9 
b) Suponhamos que
p = 4 receba uma requisição
para k = 3 como pred(4)→
= 1< 3<=4 retorna o próprio→
endereço.
 
Tabelas de Hash Distribuídas 
(DHT) 
 Como encontrar uma entidade k?
– Referências na tabela de derivação são 
atalhos para nós existentes no espaço de 
identificadores
– Distância do atalho em relação ao nó p 
aumenta exponencialmente à medida que o 
índice na tabela de derivação cresce
– Para consultar uma chave k, o nó p 
repassará a requisição ao nó q com índice j 
na tabela de derivação de p
q = Ftp[ j ] <= k <= FTp[j+1]
 
Tabelas de Hash Distribuídas 
(DHT) 
1) Considere a resolução
de k=12, a partir do nó 28
2) Nó 28 consultará k=12 verifica→
que FT[4] < k<= FT[5]
3) Requisicão será repassada para
o nó 4
4) O nó 4 selecionará o nó 9, 
porque FT[3] < k<= FT[4]
5) O nó 9 selecionará o nó 11
6) O nó 11 repassará o pedido ao nó 14
Consulta O(log(N)) passos→
 
Nomeação Estruturada
 Nomes simples são bons para máquinas, mas 
não são convenientes para a utilização de seres 
humanos
 Sistemas de nomeação comumente suportam 
nomes estruturados
– Exemplo: Nomeação de arquivos, hosts na 
Internet
 
Nomeação Estruturada – Espaço 
de nomes
 Nomes são organizados em um espaço de 
nomes
 Espaços de nomes podem ser representados 
como um grafo dirigido, com dois tipos de nós:
– Nó-folha: entidade 
– Nó de diretório: entidade que se refere a 
outros nós
 Nó de diretório possui uma tabela de diretório
<nome aresta, nome nó>
 
Nomeação Estruturada – Espaço 
de nomes
 Sistemas de nomeação possuem, na maioria, um nó 
raiz
 Cada caminho no grafo de nomeação pode ser 
referenciado pela sequência dos labels nas arestas 
N:<label1, label2, ..., labeln>
• Nome de caminho absoluto: primeiro nó no 
caminho é a raiz 
• Nome de caminho relativo: primeiro nó pode 
ser qualquer nó
 
Nomeação Estruturada – 
Resolução de nomes
 Espaços de nomes oferecem um mecanismo 
para armazenar e recuperar informações sobre 
entidades por meio de nomes
 Dado um nome de caminho, deve ser possível 
consultar qualquer informação armazenada no 
nó referenciado por aquele nome
 Problema: Para resolver um nome, precisamos 
de um nó de diretório. Como escolher este nó 
inicial?
 
Nomeação Estruturada –
Resolução de nomes 
 Mecanismo de fechamento: Trata da seleção do nó 
inicial em um espaço de nomes a partir do qual a 
resolução de nomes deve começar.
 São implícitos ao contexto em que a resolução de 
nomes está se aplicando
www.cs.vu.nl: início da resolução é feito através do 
servidor de nome DNS (raiz)
– /home/steen/mbox:início da resolução ocorre no 
servidor local NFS
 
Nomeação Estruturada –
Resolução de nomes – Alias 
 Outro nome para a mesma entidade
 Vários nomes absolutos para o mesmo nó 
 
Nomeação Estruturada –
Resolução de nomes – 
Diversos Espaços de Nomes
 Como fundir diferentes espaços de nomes de 
maneira transparente? Dado dois espaços de nomes 
A e B, como A acessa B e B acessa A?
Possível Solução: Montagem (Mouting)
 
 Nomeação Estruturada –
Resolução de nomes – 
Diversos Espaços de Nomes
 1
Sistemas Distribuídos –
Capítulos 5 e 6 - Aula 9
Aula de hoje
Nomeação estruturada
Implementação de um 
espaço de nomes
Implementação de resolução 
de nomes
Nomeação baseada em 
atributo
Introdução ao problema de 
sincronização (cap 6)
Aula Passada
Comentários Prova
Nomes, 
Identificadores, 
Endereços
Nomeação Simples
Nomeação Estruturada
 
Implementação de um 
espaço de nomes
 Serviço que permite que usuários e processos 
adicionem, removam e consultem nomes
Serviço de nomeação é implementado por servidores de 
nomes
Servidores de nomes devem prover:
Escalabilidade
Manutenção descentralizada
Tolerância a falhas, robustez
Escopo global: Nomes possuem o mesmo significado 
em todos lugares
 
 
Implementação de um 
Espaço de Nomes
 Costumam ser organizados em hierarquia
 Segundo Cheriton e Mann (1989) é conveniente dividir os espaço 
de nomes em três camadas
– Camada global 
• Raiz e seus filhos
• Principal característica: Estabilidade
• Podem representar organizações
– Camada Administrativa
• Nós de diretórios
• Gerenciados por uma única organização
• Relativamente estáveis
– Camada Gerencial
• Nós cujo comportamento típico é a mudança periódica
• Mantidos por administradores de sistemas e usuários finais
 
Implementação de um 
Espaço de Nomes
 
Como resolver nomes? 
 Resolução Iterativa
– Servidor responde somente o que sabe: o 
nome do próximo servidor que deve ser 
buscado
– Cliente procura iterativamente os outros 
servidores
 Resolução Recursiva
– Servidor passa o resultado para o próximo 
servidor que encontrar
– Para o cliente, somente existe uma 
mensagem de retorno: o endereço do nome 
ou 'não encontrado'
 
Como resolver nomes?
 
Iterativa versus Recursiva
Tipo Carga
Camada 
Global
Cache Comunicação
Iterativa Baixa Menos 
Eficiente
Custosa
Recursiva Alta Mais 
Eficiente
Menos 
custosa
 
Iterativa versus Recursiva
2: Application Layer 9
DNS: Domain Name System
Pessoas: muitos 
identificadores:
 nome, CI, CPF, passaporte
Roteadores e hosts:
 Endereço IP address (32 
bits) – usado para 
endereçar datagramas
 “nome”, e.g., ww.yahoo.com 
– usado por humanos
Q: como mapear um 
endereço IP e o nome?
Domain Name System:
r Banco de dados distribuído 
implementado em hierarquia 
com muitos servidores de 
nome
r Protocolo da camada de 
aplicação hosts, roteadores, 
servidores de nomes se 
comunicama para resolver 
nomes (tradução 
endereço/nome)
2: Application Layer 10
DNS 
Por quê não centralizar o 
DNS?
r Único ponto de falha
r Volume de tráfego
r Banco de dado centralizado 
distante
r Manutenção
Não é escalável!
Serviços DNS 
r Tradução do nome para o 
endereço IP
r Apelidos de hospedeiro
r Apelidos do servidor de 
email
r Distribuição de carga
 Vários servidores Web: 
conjunto de endereços IP 
para um único nome
2: Application Layer 11
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
poly.edu
DNS servers
umass.edu
DNS serversyahoo.comDNS servers
amazon.com
DNS servers
pbs.org
DNS servers
Banco de Dados Distribuído e 
Hierárquico
Cliente procura o IP para www.amazon.com:
r Cliente consulta um servidor raiz para encontrar o servidor 
DNS .com
r Cliente consulta o servidor DNS .com para encontrar o 
servidor amazon.com
r Cliente consulta o servidor amazon.com para encontrar o 
endereço www.amazon.com
2: Application Layer 12
DNS:Servidores Raiz
r Contactado pelo servidor de nome local que não pode traduzir o nome
r Servidor raiz
 13 servidores raiz de 
nome no mundo
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA 
(and 36 other locations)
i