Sistema de deslocação de texto em máquinas

adjacentes
Helder Ribeiro 47428 Hugo Leite 50044 Ricardo Maciel 50037
Janeiro 5, 2011

1
Conteúdo
1 Introdução 4
1.1 Algoritmo de Berkeley . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Sockets UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Vantagens do UDP . . . . . . . . . . . . . . . . . . . . . . 6

2 Implementção 7
2.1 Eleição do coordenador . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Algoritmo de sincronização . . . . . . . . . . . . . . . . . . . . . 7
2.3 Apresentação da mensagem . . . . . . . . . . . . . . . . . . . . . 9

3 Resultados e discussão 10
3.0.1 Sincronização . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.0.2 Rede usada . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Conclusão 12

2
 Resumo
O seguinte relatorio diz respeito à implementação de um sistema de
apresentação de mensagens dinamico em maquinas adjacentes.Bocados da
mensagem são apresentados em cada maquina e actualizados de forma a
que o texto seja visto a correr pelos monitores adjacentes.

3
1 Introdução
Este Projecto realiza-se no âmbito da disciplina de Sistemas Distribuidos do
4Ano do Mestrado integrado em Engenharia de Comunicações orientado pelo
Prof. Francisco Moura do departamento de informatica da Universidade do
Minho. O objectivo do projecto consiste na implementação de um sistema
de apresentação de mensagens dinamico em maquinas adjacentes. Bocados de
mensagens são apresentados em cada maquina e actualizados de forma a que o
texto seja visto a correr pelos monitores adjacentes. Foi usado um algoritmo de
sincronização baseado no algoritmo de berkeley sobre sockets udp.

1.1 Algoritmo de Berkeley

O Algoritmo de Berkeley tem como objectivo sincronizar os relogios de varios
computadores sem acesso a uma fonte UTC externa, tipicamente ligados à uma
rede local ou internet como está explicito na Figura 1.
• Um computador é eleito coordenador. Se falhar, há reeleição do seu lugar.
• Periodicamente, o coordenador recebe o valor dos relógios dos outros com-
putadores
• O coordenador calcula a média e difunde o ajuste que cada computador
tem de fazer ao seu relógio:
• ti = m(ti) + Tround / 2
• Ajuste: dti = ti - média( t1, t2, t3, ...) ;
• O tratamento estatı́stico dos valores pode detectar e eliminar valores ex-
tremos e erróneos.

Figura 1: Algoritmo de Berkeley

4
 Pontos Fortes do Algoritmo:
• O ajuste dos relógios com base na média de um número elevado de máquinas
tende a reduzir a margem de erro;
• Ignorar valores muito distantes da média permite tolerar relógios com
valores muito diferentes;
• A actualização dos relógios atravês do envio do ajuste a efectuar evita a
incerteza introduzida pela propagação de mais uma mensagem.
Nota: Os relógios evoluem em conjunto, mas o tempo medido não tem qual-
quer relação com o exterior

1.2 Sockets UDP

O UDP dá às aplicações acesso directo ao serviço de entrega de datagramas,
como o serviço de entrega que o IP dá. O UDP é pouco confiável, sendo um
protocolo não orientado à conexão. Não existem técnicas no protocolo para
confirmar que os dados chegaram ao destino corretamente. O UDP usa número
de porta de origem e de destino de 16 bits.
O UDP é um acrónimo do termo inglês User Datagram Protocol que significa
protocolo de datagramas de utilizador. O UDP faz a entrega de mensagens in-
dependentes, designadas por datagramas, entre aplicações ou processos, em sis-
temas host. A entrega pode ser feita fora de ordem e datagramas podem ser per-
didos. A integridade dos dados pode ser conferida por um ”checksum”baseado
no complemento de um, de 16 bits.
Os pontos de acesso do UDP são geralmente designados por ”Portas de proto-
colo”ou ”portas”ou até ”portos”, em que cada unidade de transmissão de dados
UDP identifica o endereço IP e o número de porta do destino e da fonte da
mensagem, podendo os números ser diferentes em ambos os casos.
A diferença básica entre o UDP e o TCP é o facto de que o TCP é um protocolo
orientado à conexão e, portanto, inclui vários mecanismos para iniciar, manter
e encerrar a comunicação, negociar tamanhos de pacotes, detectar e corrigir
erros, evitar congestionamento do fluxo e permitir a retransmissão de pacotes
corrompidos, independente da qualidade do meio fı́sicos.
No UDP, por sua vez, é feito para transmitir dados pouco sensı́veis, como fluxos
de áudio e vı́deo, ou para comunicação sem conexão como é o caso da negociação
DHCP ou tradução de endereços por DNS. No UDP não existem verificações e
nem confirmações. Os dados são transmitidos apenas uma vez, incluindo apenas
um frágil, e opcional, sistema de CRC de 16 bits. Os pacotes que chegam cor-
rompidos são simplesmente descartados, sem que o emissor sequer saiba do prob-
lema. Por outro lado, a ausência de estruturas de controle complexas garante
ao UDP alta eficiência, já que cada pacote é composto praticamente somente
por dados.

5
1.2.1 Vantagens do UDP
O UDP é uma escolha adequada para fluxos de dados em tempo real, especial-
mente aqueles que admitem perda ou corrompimento de parte de seu conteúdo,
tais como vı́deos ou voz. Aplicações sensı́veis a atrasos na rede, mas poucos
sensı́veis a perdas de pacotes, como jogos de computadores, também podem
utilizar se do UDP. As garantias do TCP envolvem retransmissão e espera de
dados, como consequência, intensificam os efeitos de uma alta latência de rede.
O UDP também suporta broadcasting e multicasting. Caso esses recursos se-
jam necessários, o UDP deverá necessariamente ser utilizado. Algum tratamento
de erro pode ser adicionado, mas geralmente aplicações multicast também ad-
mitem perda de parte dos pacotes ou fazem retransmissões constantes (tal como
o ocorre no protocolo DHCP).
O UDP não perde tempo com criação ou destruição de conexões. Durante uma
conexão, o UDP troca apenas 2 pacotes, enquanto no TCP esse número é supe-
rior a 10. Por isso, aplicações que encaixam num modelo de pergunta-resposta
também são fortes candidatas a usar UDP. Entretanto, pode ser necessário im-
plementar algoritmos de timeouts, acks e, no mı́nimo, retransmissão. Nesse
caso, vale lembrar que se a troca de mensagens for muito intensa, o protocolo
TCP pode voltar a ser vantajoso, já que seu custo de conexão será amortizado.
Embora o processamento dos pacotes UDP seja realmente mais rápido, quando
as garantias de confiabilidade e ordenação são necessárias, é pouco provável que
uma implementação em UDP obterá resultados melhores do que o uso direto do
TCP. Em primeiro lugar, corre-se o risco de que uma implementação ingênua
feita em UDP seja menos eficiente do que os algoritmos já testados e otimiza-
dos presentes no TCP. Em segundo lugar, boa parte do protocolo TCP, nos
principais sistemas operativos, opera em modo núcleo, tendo portanto uma ex-
ecução mais privilegiada do que um protocolo de aplicação teria. Finalmente, é
válido lembrar que muitas placas de rede já possuem o TCP programado no seu
firmware o que permite, por exemplo, o cálculo de checksum por hardware. Por
isso, o protocolo UDP não deveria ser utilizado para fluxos de bytes confiáveis,
tais como a transferência de arquivos. Como exemplo, podemos citar o protocolo
TFTP, exceção a essa regra, que foi feito para redes locais, de alta confiabili-
dade. Na internet, o seu desempenho é muito inferior à sua versão confiável, o
protocolo FTP.

6
2 Implementção
2.1 Eleição do coordenador
Foi usado no projecto um algoritmo de sincronização baseado no algoritmo de
Berkeley. O algoritmo de Berkeley pressupõe que entre as máquinas existe a
eleição de um lı́der que irá coordenar a sincronização temporal das maquinas
que fazem parte do sistema distribuido. A eleição do coordenador é conseguida
do seguinte modo:

• Iniciam-se os processos nas diferentes máquinas numa disposição em anel;

• Uma das maquinas escolhida por nós calcula um ID aleatorio e envia-o ao
vizinho;
• Cada uma das maquinas compara o ID recebido com o seu proprio ID e
reenvia ao vizinho o ID de maior valor;
• No caso de o ID recebido ser igual ao seu a maquina decrementa o seu ID
e reenvia ao vizinho o ID que recebeu;
• Ao completar o ciclo ja se tem o ID do lı́der e o mesmo é reenviado por
todas as maquinas mais uma vez;
• No fim deste segundo e ultimo ciclo, a maquina elegida como coordenador
já sabe que o é, pois verefica se o ID que recebeu é igual ao seu.

Findo este processo de eleição a máquina coordenadora envia o seu IP ao

vizinho que por sua vez o envia a maquina seguinte até completar o ciclo. Deste
modo todas as maquinas sabem a quem têm de se ligar para iniciar o processo
de sincronização.

2.2 Algoritmo de sincronização

Neste momento o IP do coordenador já é conhecido por todas as máquinas. O
algoritmo de sincronização processa-se da seguinte forma:

• Os clientes ligam-se ao coordenador;

• O coordenador obtem a sua hora local (Tantes ) e no instante seguinte envia
uma mensagem a cada máquina pedindo-lhes as suas horas;
• Nos instantes em que recebe a resposta de cada maquina o coordenador
obtem de novo a sua hora local (Tdepois );
• Com estes valores (Tantes e Tdepois ) é calculado o RTT (Round Trip Time)
o qual será usado no passo seguinte RTT = Tdepois - Tantes ;
• Calcula-se então o desfazamento temporal entre o coordenador e as restantes
máquinas ;

7
 • Com estes desfazamentos calcula-se a respectiva média e o desfazamento
para cada máquina;
• O coordenador envia então o valor delta;
• Cada maquina ajusta o seu tempo usando a função adjtime();

Se o tempo de ajuste for positivo, o relogio do sistema adianta a hora aos

poucos (i.e., adicionando pequenos valores de tempo de relogio a cada segundo)
até estar concluido. Se o tempo de ajuste for negativo, o relogio do sistema
atrasa a hora da mesma forma.

8
2.3 Apresentação da mensagem
A construção da mensagem a apresentar é feita atravês da aplicação banner do
linux. Como a aplicação devolve o texto na vertical criamos uma aplicação que
coloca o texto na horizontal de forma a podermos apresentar a mensagem a
correr nos computadores adjacentes. É carregado o output do banner para uma
matriz e trocamos as colunas pelas linhas. Estando os computadores sincroniza-
dos o coordenador envia uma mensagem com a hora em que cada máquina tem
de arrancar o deslocamento do texto. Se tivermos 5 máquinas m1. m2, m3, m4,
m5 dispostas da esquerda para a direita a máquina m5 é a primeira a começar
e ao fim do tempo X (correspondente ao tempo desde o inicio até a saida do
primeiro caractere do monitor da máquina m5 ) a máquina m4 arranca, isto
assim até a máquina m1.

9
3 Resultados e discussão
3.0.1 Sincronização
Poderiamos ter usado o algoritmo de Lamport para apresentar as mensagens no
ecrã. Ao usar o algoritmo de Lamport uma determinada acção deveria executar
apenas quando o anterior acabasse de ser executado mas achamos que não era
o algoritmo adequado.
Existe um aspecto que não implementamos na nossa aplicação que corresponde
a resincronização quando um computador sai do anel. A maneiro como achamos
que isso deveria de ser implementado era fazendo com que os computadores par-
tilhassem os IP’s de todas as máquinas do anel.

3.0.2 Rede usada

Criamos um programa que conta o RTT de uma mensagem entre 2 máquinas.
Para produzir os resultados aqui obtidos, executamos 3 baterias de testes em 2
ambientes diferentes. O primeiro (Router) é uma rede local criada por nós, com
o auxı́lio de um router wireless doméstico. O segundo ambiente correspondia à
rede ’eduroam’. Analisando as médias (tabela 1) e os gráficos (imagem 2 e 3)
aqui apresentados, constata-se que usando a rede eduroam existe um maior lag.

Figura 2: Calculo do RTT usando a rede eduroam

10
 Figura 3: Calculo do RTT usando uma rede local

Média 1 0s
Router Média 2 0s
Média 3 0s
Média 1 0.1s
Eduroam Média 2 0.2s
Média 3 0.2s

Tabela 1: Tabela das médias

Decidimos então usar a rede local com um router doméstico com sokets UDP.

11
4 Conclusão
Este trabalho permitiu-nos solidificar conceitos relativos ao paradigma dos sis-
temas distribuidos. O uso de aplicações em rede depende essencialmente dos
algoritmos de sincronização de forma a não haver problemas devido a máquinas
que não controlamos estarem com problemas .

12
Referências
Wikipédia. 2 Jan. 2011 http://pt.wikipedia.org/wiki/User Datagram Protocol.

Apontamentos de: Sérgio Duarte (c) 2010 - DI / FCT / UNL

G. Coulouris, J. Dollimore and T. Kindberg,

Distributed Systems - Concepts and Design,
Addison-Wesley, 4th Edition, 2005

Andrew S. Tanenbaum, David J. Wetherall

Computer Networks, 5th Edition 2010

13