Académique Documents
Professionnel Documents
Culture Documents
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.
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
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:
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();
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.
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
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.
13