UNIVERSIDADE ESTADUAL DO PIAUÍ - UESPI

CAMPUS PROFESSOR ANTÔNIO GIOVANNE ALVES DE SOUSA

CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
SISTEMAS DISTRIBUÍDOS

PROCESSOS/ VIRTUALIZAÇÃO/ REDES E 𝐒𝐃𝐬 /

INTRODUÇÃO AOS PARADIGMAS DE COMUNICAÇÃO
E SINCRONIZAÇÃO EM 𝐒𝐃𝐬

Msc. PATRÍCIA DAYANA DE ARAÚJO SOUZA

Material Adaptado
 Comunicação em Sistemas Distribuídos

• A comunicação entre processos distribuídos é feita pela troca de

mensagens (com primitivas TCP ou UDP).
• As mensagens são armazenadas em pacotes chamados datagramas.
• As mensagens são trocadas entre processos (ou threads) localizados em
máquinas distintas.
• Os protocolos garantem que processos consigam estabelecer a
comunicação mesmo em plataformas diferentes ou tecnologias diferentes.
• O mecanismo de comunicação entre processos usa middleware para
simplificar a comunicação.
Processos
• Processos interagem e cooperam na execução de tarefas. Em
muitos casos, processos precisam trocar informação de forma
controlada para:
–dividir tarefas e aumentar a velocidade de computação;
–aumentar da capacidade de processamento (rede);
–atender a requisições simultâneas.
• Metodologias:
– Compartilhamento de memória (sistema monoprocessado);
– Pipes e Sinais (ambiente centralizado);
– Troca de Mensagens (ambiente distribuído).
 Virtualização
• Threads e processos podem ser vistos como um modo de fazer mais coisas
ao mesmo tempo – permitem construir (porções de) programas que parecem
ser executados simultaneamente.
• Em um computador monoprocessador essa execução simultânea é uma
ilusão (como há somente uma única CPU, só uma instrução de um único
thread ou processo será executada por vez, a ilusão de paralelismo é criada
pelo chaveamento rápido entre threads e processos).
• Essa separação entre ter uma única CPU e ser capaz de fingir que há mais
delas pode ser estendida também a outros recursos, o que resulta no que
denominamos virtualização de recursos.
• Essa virtualização é aplicada há décadas, mas conquistou renovado interesse
à medida que sistemas (distribuídos) de computadores se tornaram mais
comuns e complexos.
 Virtualização
• Na prática, todo sistema (distribuído) de computadores oferece uma interface de
programação a software de alto nível, como mostra a Figura 3.4(a). Há vários
tipos diferentes de interfaces, que vão desde o conjunto básico de instruções
oferecido por uma CPU até o vasto conjunto de interfaces de programação de
aplicação que acompanha muitos dos sistemas atuais de middlewares.
• Em sua essência, a virtualização trata de estender ou substituir uma interface
existente de modo a imitar o comportamento de um outro sistema, como
mostra a Figura 3.4(b).
Prof. Luiz Fernando Bittencourt IC - UNICAMP

Virtualização

• Máquina virtual em diferentes níveis de abstração

• Processos individuais
• Sistemas completos
• Máquinas virtuais
• Uso flexível de hardware e isolamento de software.
• Tradução de conjuntos de instruções.
• Variedade de arquiteturas de máquinas virtuais.
• Máquinas virtuais de processo e de sistema.
 Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturas de Máquinas Virtuais

• Em geral, sistemas de computadores oferecem 4 tipos

diferentes de interfaces em 4 níveis diferentes:
• 1: instruções de máquina que podem ser invocadas por qualquer
pograma.
• 2: instruções de máquina que podem ser invocadas somente por
programas privilegiados, como o sistema operacional.
• 3: Chamadas de sistema: oferecidas por um sistema operacional.
• 4: Chamadas de biblioteca: conjunto conhecido como interface de
programação de aplicativo (API).
 Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturas de Máquinas Virtuais

• Em geral, sistemas de computadores oferecem 4 tipos

diferentes de interfaces em 4 níveis diferentes:
• 1: instruções de máquina que podem ser invocadas por
qualquer pograma.
• 2: instruções de máquina que podem ser invocadas somente
por programas privilegiados, como o sistema operacional.
• 3: Chamadas de sistema: oferecidas por um sistema
operacional.
• 4: Chamadas de biblioteca: conjunto conhecido como
interface de programação de aplicativo (API).
 Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturas de Máquinas Virtuais

• Máquina Virtual de Processo:

• Aplicações desenvolvidas para um Sistema Operacional são executadas em
outro Sistema Operacional. A virtualização é feita somente para um único
processo. Funcionam como emuladores, com a finalidade de imitar chamadas
de sistema.
• Máquina virtual de sistema
• Fornece o conjunto de instruções completo do hardware. Vários sistemas
operacionais diferentes executando independente e concorrentemente na
mesma plataforma. Importantes no contexto de confiabilidade e segurança
proporcionando isolamento de uma aplicação e seu ambiente. As falhas não
afetam a máquina inteira.
 Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturas de Máquinas Virtuais

• Máquina virtual de processo

• Sistema de execução com conjunto de instruções abstrato para
executar aplicações.
• Instruções interpretadas (p. ex. Java).
• Emulação (Wine) – necessário imitar comportamento de
chamadas de sistema (não trivial).
• Chamada de máquina virtual de processo / runtime
software.
 Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturas de Máquinas Virtuais

• Máquina virtual de sistema

• Protege completamente o hardware original.
• Interface: conjunto de instruções completo do mesmo (ou de outro)
hardware.
• Pode ser oferecida simultaneamente a programas diferentes.
• Vários sistemas operacionais executando independente e
concorrentemente na mesma plataforma.
• Camada chamada de Virtual Machine Monitor – VMM – ou hypervisor.
• Exemplos de VMMs: VMWare, Xen, KVM, etc.
 Prof. Luiz Fernando Bittencourt IC - UNICAMP

Arquiteturas de Máquinas Virtuais

• Tipos de monitores de máquina virtual (VMMs)

• Tipo 1: nativa (bare metal): executa sobre uma interface direta com
hardware.
• Tipo 2: hospedada (hosted): executa sobre um sistema operacional
em uma máquina hospedeira.
Virtualização
Comunicação entre Processos
 Sistemas Distribuídos
⚫ Não há memória compartilhada
⚫ Troca de Mensagens (comunicação entre processos)
⚫ Protocolos de comunicação
 Regras para a correta troca de mensagens
 Interpretação das mensagens
 Camadas
◼ Responsabilidades específicas na troca de mensagens
 Modelo OSI
◼ Modelo abstrato de redes

◼ Comunicação entre sistemas abertos

 Protocolos

 Modelo OSI
◼ Um sistema aberto é preparado para se comunicar com
qualquer outro sistema aberto através de regras que ditam
o formato, conteúdo e significado das mensagens enviadas
e recebidas.

• Modelos gerais de protocolos nas trocas de

mensagens
◼ Orientado a Conexão
◼ Sem Conexão
 Protocolos

 Protocolo Orientado a Conexão

◼ Emissor e Receptor devem estabelecer uma
conexão (podendo negociar o protocolo
usado) antes da troca de dados
⚫ Ex.: Comunicação telefônica

 Protocolo Sem Conexão

◼ Não há conexão entre Emissor e Receptor
⚫ Ex.: Correio eletrônico.
 Modelo OSI

 Divisão do Modelo OSI

◼ 7 Camadas
◼ Cada camada trata de um aspecto da
comunicação
◼ Cada camada provê uma interface às adjacentes
⚫ Operações que definem os serviços da camada
◼ Cabeçalhos podem ser acrescentados e
retirados às mensagens
 Modelo OSI

Máquina 1 Máquina 2

Processo A Processo B

protocolo de aplicação
aplicação aplicação
protocolo de apresentação
apresentação apresentação
protocolo de sessão
sessão sessão

transporte protocolo de transporte

transporte
protocolo de rede
rede rede
protocolo de enlace
enlace enlace

física protocolo de meio físico

física

Rede de comunicação
 Modelo OSI

 A Camada Física
◼ Responsável pela transmissão dos bits de
informação (0’s e 1’s) no meio de comunicação
⚫ Padronização elétrica
⚫ Sincronização

⚫ Padronização de conectores

◼ Ex.: RS-232-C
⚫ Comunicação serial
 Modelo OSI

 A Camada de Enlace de Dados

◼ Realiza a detecção e correção de erros
◼ Padroniza o formato de um quadro
◼ Adiciona bits de paridade, start, stop e checksum
◼ Ordena os quadros e pede retransmissão de
quadros perdidos
 Modelo OSI

 A Camada de Rede
◼ Determina as Rotas que os pacotes seguem
do remetente ao destinatário
⚫ Roteamento

⚫ Custo
 Modelo OSI

 A Camada de Rede
◼ Procura a melhor rota

⚫ Distância
⚫ Velocidade (tráfego)
 Atrasos
 Variante com o tempo
◼ Protocolos Orientados a Conexão
◼ Protocolos Sem Conexão
 Modelo OSI

 A Camada de Transporte
◼ Conexão confiável

⚫ Detecta e corrige perda de pacotes

⚫ Provê confiabilidade ponto a ponto

◼ Pode ser construído sobre X.25 ou IP

⚫ X.25
 Seqüência de Pacotes
⚫ IP (serviço de rede não orientado a conexão)
 Ordem dos pacotes depende dos caminhos
⚫ TCP (serviço de transporte orientado a conexão) e UDP
(serviço de transporte não orientado a conexão)
 Modelo OSI

 A Camada de Sessão
◼ Provê sincronização
◼ Uma evolução da camada de transporte
◼ Permite inserir pontos de verificação em
mensagens longas
◼ Raramente é implementada
 Modelo OSI

 A Camada de Apresentação
◼ Relacionada ao significado dos bits

⚫ Mensagens

◼ Trata da representação da informação

◼ Facilita a comunicação entre máquinas com
diferentes formatos de dados
 Modelo OSI

 A Camada de Aplicação
◼ Coletânea de protocolos para atividades comuns
⚫ E-mail (smtp, pop e imap)
⚫ FTP

⚫ HTTP
⚫ DNS

⚫ Etc.
 Modelo OSI - Resumo
Funções e Serviços Camada do RM-OSI

Processos da redepara aplicativos Aplicação

e interface com o usuário.
Formatação e representação dos dados. Apresentação
Comunicação entre hosts, cuida do Sessão
diálogo.
Conexões (comunicações) fim-a-fim. Transporte
Endereço lógico e melhor caminho. Rede
Acesso lógico ao meio físico (endereço Enlace
físico).
Transmissão binária (fios, conectores, Fisica
taxas de dados e voltagens).
 Antes de mais detalhes

• Lembremos 2 ou 3 coisas...
• Camada de rede (no nosso caso IP):
– Responsável por comunicação best-effort de pacotes entre nós
– Pacotes podem seguir rotas diferentes ou não chegar

• Camada de transporte:
– Comunicação entre processos
– Multiplexamos a comunicação do IP com portas
 Transporte: TCP, UDP

• Tipicamente, um programador só lida com a

camada de transporte;

• As camadas inferiores são responsáveis por enviar

dados brutos sem garantias de:
– Recebimento
– Ordem
– Integridade

• A camada de transporte torna isso tratável para os nós.

 TCP vs. UDP

• Em resumo, confiabilidade vs. desempenho

– Propriedades do TCP não são sempre importantes
 UDP: como e pra quê

• UDP é o IP no nível do transporte

– Transmissão de datagramas convertidos em
pacotes
– Checksum opcional
– Nenhuma garantia de chegada ou ordenação
– Não há retransmissão
 UDP-Traduzindo ...

• Mensagens podem ser perdidas

– Nos buffers, por exemplo
A comunicação está sujeita a falhas de omissão

• Mensagens podem sair de ordem

– Seguindo caminhos diferentes no roteamento IP
A comunicação está sujeita a falhas de tempo

• Isso nos diz algo sobre que tipo de sistemas devemos

construir sobre o UDP
 O UDP é útil!

• Um monte de problemas pode ser

solucionado no modelo UDP
– DNS, DCHP, VOIP
– Transmissão de vídeo
– Transmissão de áudio
– Utilização eficiente de banda em alto
desempenho
 TCP: como e para quê

• TCP abstrai fluxo de mensagens, com relação a:

– Tamanhos de mensagem
– Perdas de mensagens
– Diferenças na velocidade de envio e recebimento (fluxo)
– Duplicação e ordenação de mensagens
– Destino das mensagens! (outro lado da conexão)
• Funcionamento do TCP
–Validade: usa time-outs e retransmissões para tratar
perda de mensagens
–Integridade: uso do checksum e de número de sequências
para garantir mensagens não corrompidas nem duplicadas
 TCP-Traduzindo...

• Não há falhas de omissão ou desordenação de mensagens

• Timeouts escondem de você que o mundo é assíncrono
• O uso de checksum dá suporte à integridade dos dados
• Há falhas de fail-stop
– Mas quando a conexão cai, falhou o canal ou o processo?

• Processos não detectam imediatamente que mensagem não foi

recebida
– Têm que esperar o ack não vir
– Não dá pra saber se última mensagem antes da falha chegou.
 Endereçamento

• Como enviar a mensagem a máquina servidor e depois

ao processo servidor? - Endereço deve incluir também o
número do processo (codificado no programa dos
clientes).
• Cada processo pode ter seu próprio endereço
(escolhendo seus próprios endereços aleatoriamente);
• Processos localizam outros através de mensagens de
broadcast - Mensagens extras são colocadas na rede;
 Endereçamento

• O uso de servidores de nomes pode ser uma outra

opção - Referências a processos servidores são feitas
usando-se nomes ASCII e um servidor de nomes
realiza a tradução;
• Servidor de nomes pode ser replicado, mas cuidados
devem ser tomados para manter a consistência entre
servidores.
• Caches de endereços podem ser usadas - Requer um
componente centralizado;
 Endereçamento

 Endereço de Processo:
◼ Composto

⚫ Máquina + Processo (ID Local)

⚫ Kernel identifica o processo correspondente

 Não há ambigüidade
◼ Não é um esquema transparente
⚫ O usuário conhece a localização do servidor
 Endereçamento
 Localização do Servidor
◼ Mensagem via Broadcast
⚫ Cliente envia Pacote de Localização
 Endereço do processo destino
⚫ Cada Kernel avalia mensagem
 O Servidor destinatário responde com seu
endereço
 O Cliente guarda o endereço
⚫ Esquema transparente
⚫ Carga na rede
 Endereçamento

 Localização do Servidor
◼ Servidor de Nomes
⚫ Processos servidores são referenciados por
nomes (strings ASCII)
⚫ Cada nome é mapeado para o endereço de
máquina + ID local do processo
⚫ Solução centralizada
 Escalabilidade
 Falha
⚫ Replicação
 Vários servidores de nomes
COMUNICAÇÃO
ENTRE
PROCESSOS
DISTRIBUÍDOS
Troca de Mensagens
Troca de Mensagens
Troca de Mensagens
Troca de Mensagens
Troca de Mensagens
Troca de Mensagens-Destinatários
Troca de Mensagens-Comunicação Através de Sockets
 Troca de Mensagens-Comunicação Através de Sockets
• Os sockets estão entre a camada de
transporte e a de aplicações. Estando
nesse ponto de intercessão, eles
conseguem fazer uma interface entre a
aplicação e rede de maneira bem
transparente. Assim, aplicações são
implementadas através de uma
comunicação lógica. Lógica no sentido
de que para esses programas, eles estão
se comunicando diretamente um com o
outro, mas na prática, eles estão
passando pela rede para trocar
mensagens.
 Troca de Mensagens-Comunicação Através de Sockets
• Principais funções utilizadas ao criar um programa utilizando
socket:
 Troca de Mensagens-Comunicação Através de Sockets
• Socket do destinatário (servidor) deve estar
exclusivamente acoplado a uma porta do computador
local;
• Um mesmo socket pode ser usado tanto para enviar
quanto para receber mensagens (comunicação
bidirecional) ;
• Um processo pode usar múltiplas portas, mas não
pode compartilhar portas com outros processos do
mesmo computador (exceto no caso de sockets
associados a endereços multicast).
 Troca de Mensagens-Comunicação Através de Sockets
• Os sockets abstraem as camadas de rede para que
programadores possam se preocupar com a comunicação
de maneira distribuída de seus processos e aplicações.
• A implementação dos sockets foi concebida como uma API
com interface para o sistema operacional; que é o
responsável por controlar e garantir segurança da criação e
destruição desses sockets.
• Como um padrão, os sockets hoje estão presentes em
praticamente todos programas que utilizam a rede para se
comunicar e permitindo que novos sistemas distribuídos
apareçam.
 Primitivas de Comunicação

 Características das Primitivas de Comunicação

◼ Sincronização
◼ Bloqueio

◼ Bufferização

◼ Confiabilidade

⚫ Escolha dos projetistas de sistemas

C h a m a d a s Remotas d e Procedimentos (RPC)
C h a m a d a s R em o tas d e Procedimentos (RPC)

• É um protocolo para chamadas de procedimento remoto,

composto por camadas apoiadas sobre um ambiente de
computação distribuído (DCE-Distributed Computing
Environment).
• Segue um conjunto de regras que especificam meios
de codificar e decodificar a informação transmitida
entre duas aplicações.
• Auxilia os programadores a projetar e entender
programas distribuídos com mais facilidade porque
relaciona comunicação cliente-servidor a chamadas de
procedimento convencional.
C h a m a d a s Remotas d e Procedimentos (RPC)
C h a m a d a s R em o tas d e Procedimentos (RPC)
C h a m a d a s R em o tas d e Procedimentos (RPC)
C h a m a d a s R em o tas d e Procedimentos (RPC)
C h a m a d a s Remotas d e Procedimentos (RPC)
 Falhas em RPC

• Tipo 1 – C liente pode ter endereço errado do servidor.

Variável global de erro ou exceções (nem todas as
linguagens possuem exceções e acaba com a transparência
do sistema);
• Tipo 2 – Mensagem de requisição do cliente para o servidor
é perdida;
• Tipo 3 – Temporizadores poderiam fazer com que a requisição
fosse enviada novamente, porém algumas operações não são
idempotentes, isto é, não podem ser executadas mais que
uma vez (transferência de fundos);
 Falhas em RPC

• Tipo 4 – S ervidor pode falhar antes ou após

processar uma requisição.

• Tipo 5 – C liente falha após enviar uma requisição, que

gastam ciclos de CPU, que podem bloquear recursos,
etc.
 Sincronização

⚫ Comunicação é importante, mas não é tudo!

⚫ Como os processos cooperam e sincronizam uns com os
outros?
– Ex 1. → Importante que vários processos não
acessem simultaneamente um recurso
compartilhado como uma impressora, mas cooperem
para garantir um acesso temporário exclusivo.
– Ex 2. → Concordância, entre dois processos, em
relação a ordenação de eventos
 Sincronização

⚫ Sincronização em relação ao tempo → Relógios Físicos

e Lógicos
⚫ Sincronização em relação ao compartilhamento de
recursos → Exclusão Mútua
⚫ Sincronização em relação ao coordenador de um grupo
de processos → Algoritmos de Eleição de Lider
 Relógio do Computador

Como c o m p u t a d o r g u a r d a o t e m p o ?
I g u a l a relógio d i g i t a l : oscilador d e cristal
cristal e n e r g i z a d o oscila e m f re q u ê n c i a pré-
determinada
c a d a o s c i l aç ão i n c re m e n t a u m contador (tic d e
relógio)
RTC: R e al Time Clock
circuito i n t e gr ad o d e d i c a d o,
a l i m e n t a d o t a m b é m por b a t e r i a
(computador d e s l i g a d o )
f re q u ê n c i a d e 3 2 . 7 6 8 kHz, q u e é 2 1 5
tics por s e g u n d o
p o d e ser inicializado c o m u m valor
 Ho ra d o S i s t e m a
RTC é c h a m a d o d e Hardware Clock ou BIOS Clock
Ao iniciar, SO utiliza o RTC p a r a inicializar s e u próprio
relógio
System Clock ou Kernel Clock
Dá t a m b é m b a s e a d o e m c o n t a g e m d e ticks, mas pode usar o
origem:
t i c k s q u e a l i m e n t a m a CPU e a d a p t a ç õ e s (por software)
Hora do S i s t e m a (System Time): n ú m e ro d e ticks d e s d e
u m a cer ta d a t a (epoch)
Unix: 1 d e janeiro d e 1 9 7 0 à s 0 0 : 0 0 : 0 0 UT
Conver tida p a r a Hora do Calendário (Calendar Time)
l e v a e m c o n s i d e r a ç ã o f u s o horário, horário d e ve r ã o,
etc .
 A c e r t a n d o a Hora
Como a j u s t a r a hora do s e u
computador?
Id eia 0 : o l h a a hora no celular, c op i a o
valor p a r a c om p u t a do r ( a j u s t a Hora do
S i s t e m a , a j u s t a RTC)

Funciona se seu computador

não se comunicar!
Leituras s e q u e n c i a i s do relógio serão
m on ot ôn i c as ( n ã o v a r i a )
O problema é quando os computadores
precisam se comunicar.
 E x e m p l o c o m Dropbox
Relógios a j u s t a d o s c o m i d e i a 0
Trabalho e m g r u p o, u s a n d o Dropbox
supor q u e Dropbox utiliza hora d e
g r a v a ç ã o do arquivo (system time local)
Você e d i t a , s a l v a , Dropbox a t u a l i z a no s e u
a m i g o ( s e u relógio e s t á n a frente)
S e u a m i g o e d i t a , s a l v a , m a s Dropbox n ã o
a tu a liz a no s e u pois relógio d e l e e s t á a t r á s !

Evento ocorrendo depois

é tido como anterior!
 Sincronizando Relógios

S i n c ron i z açã o d e relógios: dois

relógios m a rc a n d o e x a t a m e n t e a
m e s m a hora

Prob l e ma 1 : Qual hora e l e s d e v e m m a rc a r ?

Prob l ema 2 : Como a j u s t a r os relógios?

Com relógios ( p e r fe i t a m e n t e ) sincronizados,

p ro b l e m a s anteriores n ã o ocorrem
hora d o s eve n t o s p o d e ser u ti l i zada
 Ho ra Certa
Diferentes referências d a hora certa
UT1: b a s e a d o e m o b s e r v a ç õ e s a s t ro n ô m i c a s
b a i x a precisão m a s c o m b i n a c o m o sol
TAI: International Atomic Time
ciclos d e r a d i a ç ã o emit ido s pelo C e s i u m
9 , 1 9 2 , 6 3 1 , 7 7 0 ciclos p / s e g ( a l t a precisão)
d i ve r g e do UT1 pois rotação d a terra e s t á f i c a n d o
m a i s d e v a g a r ( m e n o s d i a s por a n o no futuro)
UTC:TAI + a j u s t e s p a r a respeitar o UT1
m a n t é m d i fe re n ç a s e m m e n o s d e 1 s e g u n d o
a d i c i o n a u m s e g u n d o (leap second) q u a n d o
n e c e s sár i o
 Problemas c o m Relógios

N e n h u m oscilador é f u n d a m e n t a l m e n t e
idêntico a outro
Diversos fatores a f e t a m f re q u ê n c i a :
c o m p o s i ç ã o e f a b r i c a ç ã o, e fatores externos
( t e n s ã o elétrica, t e m p e r a t u r a , p re s s ã o, etc)
Até os osciladores do TAI p o s s u e m v a r i a ç õ e s

Problema f u n d a m e n t a l : clock drift

f re q u ê n c i a l i g e r a m e n t e diferentes, a c u m u l a m
t e m p o (tics) e m t a x a s diferentes
oscilador d e cristal c o m u m : erro ap rox i m a d o d e 1
segundo e m 10 dias
 E x e m p l o d e Clock Drift

dC/dt = d e r i v a d a do progresso do relógio

c o m rel ação a o t e m p o (hora cer ta, UTC)
 Exemplo Real
Relógio a t ôm i c o d e u m d o s s até l ite s
u s a d o s no GPS (IIR-8 PRN 1 6 )

10-9 s
Ajuste do
relógio
Erro entre relógios

104 s
Tempo (de referência)

Gustavo Mansur and Luiz Ferreira, “Error Behavior Of Atomic Clocks Aboard Gps Satellites”
Bol. Ciênc. Geod. 25 (4) • 2019
 Ajustando Relógios

Clock drift: a j u s t a r c o n s t a n t e m e n t e os
relógios d o s c o m p u t a d o re s
ve r d a d e a t é p a r a UTC!

Como a j u s t a r a hora do s e u
computador?

I d eia 1 : Perguntar a outro c o m p u tad o r !

F u n c i o n a ? Quais s e r ã o os p ro b l e m a s ?
 P e r g u n t a n d o a Hora

TA
A
tempo

B tempo
d
B e n v i a p e d i d o d e hora p a r a A
A re s p o n d e c o m s u a hora, T
A

Tempo entre verificar e m e n s a g e m c h e g a r é d

B acerta: T = T + d
B A

P ro b l e m a : Como de t e r m i n ar o valor d e d ?
 L i d a n d o c o m Atraso

Prob l e ma f u n d a m e n t a l : Determinar d
( n a f i g u r a anterior)

Tempo decorrido d e s d e a leitura do RTC d e A

a t é a escrita no RTC d e B !
SO d e A, i n t e r f a c e d e rede d e A, t r a n s m i s s ã o
p e l a rede (diversos e n l a c e s ) , i n t e rface d e rede
d e B , SO d e B
Atrasos s ã o aleatórios, d e p e n d e m d e mu i tos
fatores (ex. c a r g a no SO, c a r g a n a rede)
Tempo m a i s s i g n i f i c a t i vo : t e m p o d e rede
p r i n c i p a l m e n t e c o m vários e n l a c e s
 Estimando d
I d e i a : m á q u i n a B u s a s e u próprio relógio
T : horário q u e p e d i d o é feito
p

T : horário q u e resposta c h e g a
r

E s t i m a r d = (T – T ) / 2
p r

B a j u s t a relógio p a r a T A + d
TA
A
tempo

B
T d T tempo
p r

Problema: valor estimado é maior do que d

(retardo entre chegada e saída em A)
 E s t i m a n d o d Melhor *Usar o relógio de A para
estimar d*

I d e i a : m a rc a r hora d e c h e g a d a e m A,
d e s c o n tar t e m p o entre c h e g a d a / s a í d a
T T
2 3
A
tempo

B tempo
T1 d T4
E s t i m a r d = [(T 4 - T 1) – (T 3- T 2)] / 2
B a j u s t a relógio p a r a T + d
3

Problema: a s s u m e q u e retardo d e i d a i g u a l
a o d e volta
 Algoritmo d e Berkeley

Sincronizaç ão d e relógio p a r a m á q u i n a s n a m e s m a
rede local
o r i g i n a l m e n t e , s e m referência externa
Ser vidor i n fo r m a s u a hora p a r a m á q u i n a s clientes
M á q u i n a s clientes re s p o n d e m c o m d i fe re n ç a entre
valor recebido e s e u s relógios
Ser vidor f a z a m é d i a d a s d i fe re n ç a s re c e b i d a s
( re m ove n d o p o s s í ve i s outliers)
Ser vidor t r a n s m i t e p a r a c a d a cliente a j u s t e
n e c e s sár i o
Clientes f a z e m a j u s t e s e m s e u s relógios
 Exemplo

1) Ser vidor e n v i a hora a todos clien tes (broadcast)

2) Clientes re s p o n d e m c o m d i fe re n ç a s
3)Ser vidor f a z m é d i a e re s p o n d e c o m a j u s t e s
Não p o s s u i referência extern a ( m a s poderia)
NTP: Network T i m e Protocol
S e r v i ç o d e s i n c r o n i z a ç ã o d e re lógios p a r a a
Inte r ne t, u t i l i z a n d o UTC c o m o r e f e r ê n c i a
H i e r a r q u i a d e s e r v i d o r e s (time server), m o d e l o
cliente/servidor
Nível 0 são os servidores globais
de UTC, precisão de relógio atômico

Menos precisão!

Computadores finais, precisão de

alguns ms com UTC (mas varia)
 NTP: Network T i m e Protocol

Cliente p e r i o d i c a m e n t e solicita hora a três ou m a i s

ser vidores
Cliente e s t i m a "d “ ( s l i d e 6 3 )
Determin a hora cer ta f a z e n d o m é d i a d a s h oras
e s t i m a d a s , u s a n d o filtros (ex. e l i m i n a outliers)
Não s e t a a hora d i re t a m e n t e !
Atualiza a f re q u ê n c i a do relógio do s i s t e m a
f re q u ê n c i a d e tics por s e g u n d o é v a r i á ve l e
d e f i n i d a por software (x tics vir tuais por tic do HW)
Va n t a g e n s : hora do s i s t e m a n u n c a volta no t e m p o
(monotônica); m u d a n ç a s d e hora m a i s s u a v e s
 NTP e m A ç ã o

Sincronizaç ão c o n t i n u a d a do relógio do s i s t e m a
SO f a z controle fino d a f re q u ê n c i a do relógio do
s i s t e m a ( u s a n d o NTP)
Objetivo: Manter erro e m torno d e zero
 Sincronização d e Relógios

Prob l e ma f u n d a m e n t a l e difícil
TAI utiliza s at é l i t e s !

Relógios reais n u n c a e s t ã o perfeitamente

sincronizados
S i s t e m a s distribuídos p re c i s a m d e ordem
(em a l g u ns casos)
o rd e n a ç ã o g l o b a l d o s eve n t o s
e s c a l a d e t e m p o inferiores a 0 . 1 s e g

Outra ideia para ordenar eventos?

 Relacionando Eventos

E ve n t o s e m diferentes processos do SD
escrever no l o g , e nv i a r p e l a rede , a t u a l i z a r BD, etc

Relógios sincronizados s e r v e m p a r a ordenar

a ocorrência d e eve n t o s
M a s p o d e m o s definir ordem s e m u s a r
relógios reais
E xe m p l o : Processo (thread) s a b e a ordem d e
s e u s próprios eve n t o s
 E x e m p l o Futebolístico
Considere a c o b r a n ç a d e u m p ê n a l t i e cinco l u g a re s
l i n h a do go l , m a r c a do p ê n a l ti , l i n h a d a p e q u e n a
á re a , l i n h a d a g r a n d e á re a , l i n h a d e fu n d o
Considere os s e g u i n t e s eve n t o s
e 1 : artilheiro c h e g a n a l i n h a d a g r a n d e á re a
e 2 : goleiro c h e g a n a l i n h a do gol
e 3 : artilheiro corre p a r a b o l a n a m a r c a do p ê n al ti
e 4 : goleiro a b re os braços
e 5 : artilheiro c h u t a bola Podemos colocar os
e 6 : goleiro p u l a p a r a o lado eventos em ordem
e 7 : b o l a b a t e no goleiro
de ocorrência?
e 8 : artilheiro corre p a r a l i n h a d a p e q u e n a á re a
e 9 : b o l a v a i p a r a l i n h a d a p e q u e n a á re a
e 1 0 : artilheiro c h u t a b o l a n a l i n h a d a p e q u e n a á re a
e 1 1 : b ol a s a i p e l a l i n h a d e f u n d o
 Ordenação dos Eventos

P a r a c a d a local, s a b e m o s a re l ação d e ordem

ex. e 2 ocorre a n t e s d e e 4 q u e ocorre a n t e s d e e 7
P a r a locais diferentes, s a b e m o s a l g u m a s
relações d e ordem
ex. e 5 ocorre a n t e s d e e 7 q u e ocorre a n t e s d e e 1 0
M a s p a r a locais diferentes, n ã o s a b e m o s
a l g u m a s relações d e ordem
ex. e 3 ocorre a n t e s ou d e p o i s d e e 4

Ordenação Parcial dos Eventos!

 Diagrama de Eventos
e2 e4 e6 e7
Linha do gol
e3 e5 “rebote”
Marca do pênalti

e8 e9 e10
Linha peq área
“corrida do
e1 artilheiro”
Linha grd área

e11
Linha de fundo
tempo
D i a g r a m a ilustrativo: n ã o s a b e m o s s e e 4 ocorreu
antes de e5
D i a g r a m a a j u d a a e n t e n d e r ordem parcial
ex . “ s e t a ” i n d i c a q u e o r i g e m ocorreu a n t e s do
destino por c a u s a l i d a d e
 Relacionando eventos

R e l a ç ã o entre os eve n t o s do futebol

e 2 → e 4 , e 8 → e 9 (por ordem local)
e 1 → e 3 , e 7 → e 9 (por m e n s a g e m )
e 2 → e 6 , e 5 → e 1 0 (por transitividade)
e 3 || e 4 , e 5 || e 6 (por f a l t a d e re l ação →
entre os eve n t o s )
“ocorrem concorrentemente”
 Relógio Lógico d e Lamport

I d e i a : construir u m relógico lógico b a s e a d o

n a ocorrência d e eve n t o s
objetivo: inferir relação entre eve n t o s u s a n d o
relógio lógico
Associar a c a d a eve n t o do s i s t e m a u m valor inteiro
s e m relação c o m relógio real
C a d a processo (local) m a n t é m u m relógio lógico, L i
processo u s a relógio lógico p a r a a n o t a r o t e m p o
d e s e u s eve n t o s
Relógio lógico d e c a d a process cresce
monotonicamente
 Algoritmo d e Lamport
Como a j u s t a r o relógio l ó g i c o ? Três re g r a s :
1 ) e m c a d a processo i, incrementar relógio lógico L i
a n t e s d e c a d a eve n t o
2 ) A t r a n s m i s s ã o d e m e n s a g e m é um eve n t o, e nv i a -
s e o valor do relógio 𝐿𝑗 n a m e n s a g e m
3 ) a o receber m e n s a g e m ( m , t), processo i a t u a l i z a s e u
relógio: 𝐿𝑗 = m a x ( 𝐿𝑗 , t) + 1
t é o valor do relógio lógico recebido n a
mensagem
Valor do relógio g l o b a l d e u m eve n t o é valor do
relógio local o n d e eve n t o ocorreu
L(e) = L i(e) s e e ocorreu e m i
 Mensagens e Eventos
Algoritmo d e Lampor t n ã o e n v i a m e n s a g e n s
p e g a c a ro n a n a s m e n s a g e n s do s i s t e m a
distribuído
Algoritmo d e Lampor t n ã o d e f i n e os eve n t o s
eve n t o s definidos pelo s i s t e m a distribuído
1 2
p1 m1, m2 são
a b m1
m e n s a g e n s do SD
3 4
p2
time
s ã o e v e n t o s a , b , …fo r a m
𝑃1 , 𝑃2 , 𝑃3
c d m2 d e fi n i dos pelo SD
5
p3
1
SD p o d e ter outros
e f eve n t o s
 L e s l i e L a m p o r t – o próprio
Contribuições f u n d a m e n t a i s p a r a
s i s t e m a s distribuídos
Introduziu conceito d e relógios
lógicos e relação “ocorreu a n t e s ”
algoritmo d e Lampor t, 1 9 7 8
Introduziu conceito d e f a l h a s
bizantinas
E a i n d a “inventou ” o LaTeX
( L a é d e Lampor t)
Prêmio Turing d e 2 0 1 3
p a l e s t r a “An incomplete history
of concurrency”
 Referência
− TANENBAUM, Andrew S.; STEEN, Maarten Van., Sistemas
Distribuídos: Princípios e Paradigmas. São Paulo: Pearson Pretice Hall,
2007. 2ed.
− COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas
Distribuídos: conceitos e projeto. 4.ed. Porto Alegre: Bookman, 2007.
− BARBOSA, Valmir C.. An Introduction to Distributed Algorithms. MIT Press.
1996.
Bibiliografia Complementar:
− TEL Gerard. Introduction to Distributed Algorithms. Cambridge.
− Tecnologia de Sistemas Distribuídos: José Alves Marques e Paulo Guedes 1999 FCA
Editora de Informática
− Java Web Services: Up and Running (Second Edition): Martin Kalin 2013
(September 28) O'Reilly Media