Relatorio III - MI Conectividade e Concorrencia TEC502

Tempo em Sistemas Distribudos.

Emanuel Santana Santos, Lucas da Silva Cardoso
1
Curso de Bacharelado em Engenharia de Computacao
Universidade Estadual de Feira de Santana (UEFS)
Campus de Feira de Santana 44036-900 Feira de Santana BA Brasil
emanuel.santana1514@gmail.com, thelucascardoso@gmail.com

Abstract. This article aims to show a solution found for the problem of clock
synchronization, through distributed systems. This work was developed and
tests performed without system, such as difficulties encountered, how they were
solved and the final result, showing the developed product and tests performed
without system. So that the synchronization between the clocks is working.

Resumo. Este artigo tem como finalidade mostrar a solucao encontrada para
o problema de sincronizacao de relogios, por meio de sistemas distribudos.
Esse trabalho foi passado ao grupo TEC502 e aqui sera detalhando todo o
processo de construcao do sistema, mostrando quais as ferramentas utilizadas
nesse processo, quais as dificuldades encontradas, como elas foram resolvidas
e o resultado final, mostrando o produto desenvolvido e testes realizados no
sistema para que a sincronia entre os relogios esteja funcionando.

1. Introducao
Hoje em dia, praticamente tudo que o ser humano faz gira em torno de tempo, seja tempo
de trabalho, tempo de sono, tempo de viagens. Cada vez mais as pessoas querem fa-
zer mais coisas, em menos tempo, ou tentando sempre administra-lo da melhor maneira
possvel para que possa cumprir todas as suas tarefas.
Nesse mundo monotono, e necessario sempre se manter atualizado, uma vez que
o tempo e essencial para os seus compromissos diarios, atrasos no horario do seu com-
putador, relogio de pulso ou smartphone, mesmo que de alguns minutos ou segundos,
pode gerar efeitos catastroficos, isso pode ser comprovado pela TEORIA DO CAOS
de Edward Lorenz. Na teoria do caos, Lorenz explica que pequenos eventos distintos, em
locais diferentes ou nao, podem provocar eventos maiores, chegando ate ser possvel criar
catastrofes a partir do bater de asas de uma borboleta.
Entao, pensando em evitar possveis catastrofes no mundo, foi solicitado que o
grupo TEC502 produzisse um software capaz de sincronizar relogios de computadores
por meio de sistemas distribudos, que seus donos possam realizar suas tarefas e ir aos
seus compromissos no horario correto.

2. Fundamentacao Teorica
Para que o software de sincronia por meio de sistemas distribudos pudesse ser desenvol-
vido, foi necessaria uma busca mais aprofundada sobre o que poderia ser seria utilizado,
e entao constatou-se que seria utilizado:
2.1. Enderecos Multicast
Enderecos Multicast sao uma faixa de enderecamento IP definida pela RFC 5771. Seu
intervalo compreende os valores entre 224.0.0.0 ate 239.255.255.255, sendo que toda a
faixa 224.0.0.0 e reservada e nao deve ser utilizada [Deering 1988] [(IETF) 2010].
O JAVA possui uma API que simplifica a utilizacao de enderecos multicast. A
API MulticastSocket possui um comando que insere a sua aplicacao em um grupo que
responde a um endereco multicast escolhido anteriormente e que respeite o intervalo de
enderecamento definido. Apos uma aplicacao entrar no grupo ene sera capaz de enviar e
receber mensagens de todos os outros elementos que podem estar nesse grupo.

2.2. Protocolo UDP

A utilizacao da API MulticastSocket geralmente esta associada ao envio e recebimento
de mensagens utilizando o protocolo UDP. O protocolo UDP e um protocolo simples,
orientado a datagrama, diferentemente do protocolo TCP, ele nao fornece confiabilidade
na transmissao, mas en contra partida se torna mais rapido pelo falto da ausencia de
overhead que o TCP apresenta [dos Reis 2016].

2.3. Sistemas Distribudos (SD)

Um sistema distribudo e uma colecao de computadores independentes entre si que se
apresenta ao usuario como um sistema unico e coerente [Tanenbaum and Steen 2006].
Assim, a computacao distribuda consiste em fazer com que diversos processos
que acontecem distantes um do outro sejam vistos como uma unica coisa, de forma que o
usuario nao perceba que um outro dispositivo esta sendo responsavel por aquele processo
que ele esta executando.

2.3.1. Tempo em SD

Tempo em SD e uma questao muito abordada, principalmente a sincronizacao, pois e

algo que e necessario fazer em diversas ocasioes. Existem dois modos de sincronizacao
de tempo em SD:

Sincronizacao Externa - Sincroniza os relogios com base em uma fonte externa

de tempo.
Sincronizacao Interna - Sincroniza os relogios com base no relogio dos demais
utilizando um grau de precisao conhecido por todos.

Um outro conceito bem importante relacionado a tempo de um modo geral e em

relacao ao Drift .
Drift e a diferenca entre as contagens dos relogios, essa diferenca em geral ocorre
por conta dos cristais utilizados nos relogios fsicos, sendo algo que dificilmente
possa ser alterado, exceto por situacoes onde esteja sendo realizada uma simulacao
de relogio, como este software pro exemplo. A existencia de valores de drift di-
ferentes provoca a necessidade se estarmos sempre sincronizando nossos relogios
com fontes de hora externas confiaveis.
2.4. Algoritmos de Eleicao
Visto que estamos trabalhando sobre um Sistema Distribudo, e que o nosso desafio e rea-
lizar a sincronizacao de relogios, precisaramos de um metodo de definir qual relogio seria
a referencia para os demais. Para resolver essa questao existem os chamados algortimos
de eleicao. Esses algortimos sao utilizados em SD para realizar diversas tarefas, as mais
comuns: escolha de um lder e ordenacao de tarefas/processo.
Os algoritmos existentes possuem diversos metodos e meios de eleger algum dis-
positivo, os mais comuns sao os metodos de Bully e o da eleicao em anel. O algoritmo de
Bully, que serviu como base para o desenvolvimento da eleicao do sistema descrito neste
relatorio funciona da seguinte maneira:
O processo observa que nao ha um lder, ou ha algum problema com ele;
Ele envia entao uma mensagem a todos os processos que possuem um ID maior
que o dele;
Se algum desses processos responderem, ele abandona a disputa;
Se nenhum processo responder, significa que ele possui um ID maior que os de-
mais e assume a posicao de lder.

2.5. Threads
Para desenvolver um sistema que conseguisse tratar de muitas informacoes provenientes
do grupo multicast e o seu proprio processamento foi necessario a utilizacao de Threads
para assegurar que as tarefas fossem realizadas paralelamente. Conseguindo assim, de
forma satisfatoria realizar uma conversa no grupo ao mesmo tempoque realiza uma
decisao [Tanenbaum 2003].
Um conceito relacionado a threads e o de multithread, onde em um mesmo ob-
jeto, um mesmo elemento, existe mais de uma thread sendo executada, o que e aplicado
nesse processo de desenvolvimento.

3. Metodologia
Como o sistema de sincronizacao deve funcionar para um grupo especfico de relogios,
viu-se a necessidade de conectar todos esses relogios de alguma forma, e a solucao mais
viavel encontrada, foi a utilizacao de grupos multicast. Utilizando a API MulticastSocket
e possvel criar um grupo onde todos os computadores recebem as mensagens enviadas
para o grupo. Alem disso nao e necessario ter um unico servidor base para os dados,
todos os relogios podem acabar sendo selecionados como lder do grupo e assim acabar
assumindo a funcao de Servidor de tempo, e uma vez que isso acontece, todos os outros
relogios devem entender que este e o lder e comecar a atualizar seu horario a partir dele.
Quando ocorre a conexao de um novo relogio no grupo ele ja passa a receber
mensagens dos outros, e quando isso acontece e gerada uma eleicao de coordenador,
onde o vencedor e o relogio como maior horario.
O sistema basicamente funciona da seguinte maneira:
Apos a abertura da interface a contagem do relogio e iniciada com o comando
Start.
Acontece a conexao do relogio com os grupos multicast.
 Verificacao de quem e o relogio lder do grupo.
Eleicao de um lder, caso necessario.
Envio/recebimento de mensagens com o horario do lder, e sincronizacao dos
relogios.

Para a construcao do software foi utilizada a IDE Eclipse, iniciado pela IBM em
novembro de 2001 e apoiado por um consorcio de fornecedores de software. A fundacao
eclipse foi criada em janeiro de 2004 como uma empresa independente sem fins lucra-
tivos para atuar como mordomo da comunidade eclipse. Alem disso, a linguagem de
programacao utilizada na construcao do sistema foi o java em todas as suas partes.

4. Resultados e Discussoes
Ao iniciar o software e mostrada uma tela onde e possvel alterar a hora do relogio, alterar
o tempo de Drift, inciar o relogio e tambem conectar a um grupo multicast, deve-se clicar
no botao Start caso seja o primeiro relogio a se conectar no grupo.
Ao realizar a conexao e entrar no grupo, esse relogio e adicionado em grupos au-
xiliares criados para segmentar os dados de foma que nao ocorra um fluxo grande e desne-
cessario em apenas um grupo, evitando problemas de atraso na sincronizacao por causa do
grande fluxo de informacoes na rede. Existem dois grupos: um grupo para recebimento
de atualizacoes de horario, e outro para comunicacao de solicitacoes e protocolo entre
relogios. Alem disso todo o processo foi dividido em varias Threads, de forma a garantir
que todos os passos da execucao do programa seja de certa forma independentes entre si.
Foram criadas as Threads de verificacao do grupo multicast, definindo assim o primeiro
lder caso nao exista nenhum outro relogio no grupo, a thread que e responsavel por re-
ceber e processar a atualizacao de horario do lder, a thread que envia as atualizacoes do
horario, caso o dispositivo seja o lder do grupo e a thread que e responsavel pela eleicao.
Um ponto decisivo da construcao deste software foi a definicao do metodo de
eleicao, e a forma de sincronizacao de relogios, assuntos que foram pertinentes em todas
as sessoes tutoriais, e que foram fonte de varios questionamentos e duvidas. Apos as
discussoes entre o grupo, por consenso foi definido que a aplicacao que possusse o maior
horario deveria se tornar o lder do grupo, de forma a manter o tempo sempre avancando,
requisito que foi descrito no texto base do problema, em em meio a tantas interpretacoes
possveis.
A solucao computacional para a eleicao, a partir da definicao do que deveria ocor-
rer, foi feita com base no algoritmo de Bully, sendo que, ao inves de ser o maior ID, o
maior tempo seria escolhido como o lder do grupo. Essa solucao foi desenvolvida com a
ajuda de Alyson Dantas, um componente do grupo, mas de uma dupla diferente.

5. Conclusao
Ao ser repassado para o grupo TEC502, o problema explicita o que o sistema deve ser
capaz de fazer: sincronizacao dos relogios que estao ligados a rede, tratamentos para
casos onde o relogio que estava sendo utilizado como referencia deixe de enviar o horario
para os outros, interface com a hora do relogio, opcoes para que a hora seja alterada e
tambem uma opcao para que um tempo de Drift (atraso) seja inserido entre os relogios.
O texto tambem especifica que deve ser encontrada uma forma de selecionar um novo
relogio como lder, alem disso, tambem ha uma condicao que diz que o tempo so avanca,
isso restringe mudancas de horario de maneira em que o relogio regrida no tempo, o que
quebraria a condicao de monotonicidade.
Os requisitos propostos no problema foram cumpridos de forma parcial, onde o
processo de sincronia funciona de forma satisfatoria, com apenas um atraso mnimo entre
os relogios; a solucao para escolher um novo relogio lder tambem funciona, mas de forma
satisfatoria, uma vez que se o lder cair e nao entrar nenhum outro relogio no grupo o
algoritmo de eleicao nao funciona de forma 100% correta, falha essa que aparenta ser
na utilizacao de multithreading, pois o processo de eleicao e realizado, mas entra em um
estado congeladoe tem sua continuidade apenas quando um novo relogio e conectado
ao grupo.

Referencias
Deering, S. E. (1988). Multicast routing in internetworks and extended LANs, volume 18.
ACM.
dos Reis, F. (2016). Curso de redes protocolo udp (user datagram protocol).
Disponvel em: http://www.bosontreinamentos.com.br/redes-computadores/curso-de-
redes-protocolo-udp-user-datagram-protocol/. Acesso em: 10 jul. 2017.
(IETF), I. E. T. F. (2010). Iana guidelines for ipv4 multicast address assignments. Dis-
ponvel em: https://tools.ietf.org/html/rfc5771. Acesso em: 10 jul. 2017.
Tanenbaum, A. S. (2003). Sistemas Operacionais Modernos. Pretience Hall do Brasil, 2
edition.
Tanenbaum, A. S. and Steen, M. V. (2006). Distributed systems: principles and para-
digms. Pretience Hall, 2th edition.