1. Universidade Federal do Esp´
ırito Santo
TIAGO RIGO GUASTI
Utilização do paradigma Publish/Subscribe para a
criação de um cache DNS proativo
˜
SAO MATEUS/ES
2013

2. Universidade Federal do Esp´
ırito Santo
TIAGO RIGO GUASTI
Utilização do paradigma Publish/Subscribe para a
criação de um cache DNS proativo
Trabalho de Conclus˜o de Curso submetido
a
ao Departamento de Engenharias e Compu-
ta¸ao da Universidade Federal do Esp´
c˜ ırito
Santo como requisito parcial para aprova¸ao
c˜
na disciplina Projeto de Gradua¸ao II.
c˜
Orientador:
Prof. Rodolfo da Silva Villa¸a, M.Sc.
c
˜
SAO MATEUS/ES
2013

3. Utiliza¸ao do paradigma Publish/Subscribe para a cria¸ao de um cache
c˜ c˜
DNS proativo
Tiago Rigo Guasti
Trabalho de Conclus˜o de Curso submetido
a
ao Departamento de Engenharias e Compu-
ta¸ao da Universidade Federal do Esp´
c˜ ırito
Santo como requisito parcial para aprova¸ao
c˜
na disciplina Projeto de Gradua¸˜o II.
ca
Aprovada por:
Prof. Rodolfo da Silva Villa¸a, M.Sc. / UFES (Orientador)
c
Prof. H´lcio Bezerra de Mello, D.Sc. / UFES
e
Prof. Renato Elias Nunes de Moraes, D.Sc. / UFES
S˜o Mateus, 01 de Fevereiro de 2013.
a

4. ”Nunca soube o que era medo; tenho o m´gico segredo de conquistar o imposs´
a ıvel”
Dom Quixote.

5. Resumo
V´rias solu¸oes na ´rea de tecnologia da informa¸ao est˜o sendo implantadas para
a c˜ a c˜ a
suprir necessidades de grandes portais da Internet, estas solu¸oes tem como ponto co-
c˜
mum a dependˆncia da utiliza¸ao de valores TTL (Time To Live) extremamente baixa
e c˜
em respostas DNS (Domain Name System). Isso vem causando uma queda de desempe-
nho de servidores DNS devido ` alta taxa de falhas causadas por registros expirados (por
a
terem TTL baixo). Este trabalho tem como objetivo analisar a viabilidade da utiliza¸˜o
ca
do paradigma de comunica¸ao publish/subscribe a fim de minimizar o impacto da utili-
c˜
za¸˜o de valores TTL baixos no desempenho de cache DNS. Para provar a viabilidade
ca
foi implementada uma solu¸˜o baseada em uma rede P2P (Peer-to-peer ) Pastry onde foi
ca
poss´ executar o servi¸o publish/subscribe al´m de um servidor DNS que faz uso dos
ıvel c e
servi¸os publish/subscribe para dar caracter´
c ıstica proativa ao seu cache. Os resultados
foram satisfat´rios indicando que ´ poss´ utilizar esta proposta para implementa¸ao de
o e ıvel c˜
uma solu¸ao capaz de melhorar o desempenho do servi¸o DNS atrav´s do uso de cache
c˜ c e
proativo.
Palavras-chave: Cache, DNS, Domain Name System, Internet, Pastry, Peer-to-Peer,
Publish/Subscribe, Servi¸o de Resolu¸˜o de Nomes.
c ca

6. Abreviações
API : Application programming interface
CDN : Content Delivery Network
DDoS : Distributed Denial of Service
DIG : Domain Information Groper
DNS : Domain Name System
IDE : Integrated development environment
IETF : Internet Engineering Task Force
IP : Internet Protocol
MD5 : Message-Digest Algorithm 5
P2P : Peer-To-Peer
SRI-NIC : Stanford Research Institute - Network Information Center
TTL : Time To Live

7. Sumário
Lista de Figuras vi
Lista de Tabelas vii
1 Introdução 1
2 Conceitos Básicos 4
2.1 O Protocolo DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Implementação 10
3.1 Scribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 Vis˜o Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
a
3.1.2 Modifica¸oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
c˜
3.2 DNSHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Interface de Publica¸˜o (Publish) . . . . . . . . . . . . . . . . . . . . . . . 18
ca
4 Funcionamento do Protótipo e Testes 20
5 Conclusão e trabalhos futuros 29
Referências 1

8. Lista de Figuras
1.1 Diagrama da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Exemplo de ´rvore DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 5
2.2 Consulta sem cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Consulta com cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Diagrama das entidades envolvidas . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Diagrama da arquitetura proposta. . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Diagrama da arquitetura implementada . . . . . . . . . . . . . . . . . . . . 11
3.2 Exemplo de anel Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Fluxograma do DNSHandler . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Formul´rio de publica¸ao de um t´pico . . . . . . . . . . . . . . . . . . . . 19
a c˜ o
3.5 Formul´rio de publica¸ao de um IP . . . . . . . . . . . . . . . . . . . . . . 19
a c˜
4.1 Interface da ferramenta DIG . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Janela indicando o IP atual . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Interface da IDE Eclipse rodando o prot´tipo . . . . . . . . . . . . . . . . 23
o
4.4 Tempo de duas consultas consecutivas . . . . . . . . . . . . . . . . . . . . 24
4.5 Console indicando consultas . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Formul´rio de publica¸ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
a c˜
4.7 Formul´rio de publica¸ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
a c˜
4.8 Console indicando o envio e recebimento de uma publica¸ao . . . . . . . . 25
c˜
4.9 DIG mostrando uma mudan¸a no IP . . . . . . . . . . . . . . . . . . . . . 26
c
4.10 Mudan¸a no IP mostrada pelo Console . . . . . . . . . . . . . . . . . . . . 26
c
4.11 Comparativo de desempenho entre servidores DNS . . . . . . . . . . . . . 28

9. Lista de Tabelas
4.1 Tabela com resultado dos testes . . . . . . . . . . . . . . . . . . . . . . . . 27

10. Capítulo 1
Introdução
A Internet como ´ conhecida hoje ´, sem d´vida, uma ferramenta indispens´vel para a
e e u a
dissemina¸ao de conhecimento. Todo o contingente que faz parte da rede, tanto consome,
c˜
quanto gera conte´do. Essa forma intr´
u ınseca de funcionamento, combinada ` possibili-
a
dade de permanˆncia indeterminada de toda informa¸˜o publicada, mudou os paradigmas
e ca
modernos de propaga¸ao de conte´do, baseado apenas em um fluxo cont´
c˜ u ınuo, unilateral
e praticamente irrecuper´vel de informa¸ao, como o r´dio e a televis˜o.
a c˜ a a
Por fazer esse papel t˜o importante, a Internet ganha destaque no cotidiano das
a
pessoas. A cada nova tecnologia, algo que antes era feito utilizando meios f´
ısicos, passa a
ser realizado pelo meio digital. Por isso, vem crescendo a dependˆncia da sociedade das
e
novas formas de comunica¸ao baseadas na Internet.
c˜
Isso s´ ´ poss´ gra¸as `s diversas solu¸˜es que vˆm sendo criadas e implementadas
oe ıvel c a co e
para garantir disponibilidade e integridade dos dados que circulam sobre a grande rede.
Muitas solu¸˜es que est˜o sendo desenvolvidas para a Internet dependem da utiliza¸ao do
co a c˜
protocolo DNS (Domain Name System) como chave para o seu sucesso [20].
Parte desse sucesso est´ baseada na utiliza¸ao de cache pelos servidores DNS [28].
a c˜
Atrav´s do cache, o servidor pode responder a uma requisi¸ao sem a necessidade de
e c˜
fazer uma consulta externa (desde que o registro procurado esteja dispon´ e n˜o tenha
ıvel a
expirado) acelerando as requisi¸oes pois ´ poss´ gerar uma resposta de imediato, sem
c˜ e ıvel
depender de fatores externos.
Com o aumento do tr´fego da Internet e com a utiliza¸ao em massa de s´
a c˜ ıtios dinˆmicos,
a
grandes portais de conte´do ficaram impossibilitados de rodar em apenas uma m´quina,
u a
ocasionando uma distribui¸˜o do conte´do na rede, ao mesmo tempo em que ataques
ca u
de nega¸ao de servi¸o (DDoS ) vˆm se tornando um problema frequentemente enfrentado
c˜ c e
pelas equipes de TI ao redor do mundo. Com o intuito de evitar estes problemas, foram

11. 1 Introdu¸˜o
ca 2
propostas algumas solu¸oes que hoje est˜o sendo utilizadas. Dentre elas, destacam-se o
c˜ a
Round-Robin DNS [9], o uso de CDN (Content Delivery Networks), [18] al´m de t´cnicas
e e
descritas em [30] [23], que tˆm como foco evitar ataques de nega¸ao de servi¸o.
e c˜ c
No modelo atual, os servidores DNS utilizam o campo TTL (Time To Live) como
parˆmetro para estipular por quanto tempo eles poder˜o manter uma entrada em seu
a a
cache. Assim, ´ evidente pensar que a eficiˆncia do cache DNS dependa de valores altos
e e
de TTL.
Todas essas tecnologias tˆm como ponto em comum estarem baseadas na utiliza¸ao de
e c˜
TTL baixo. O que por um lado vem resolvendo os problemas citados, acaba gerando uma
deficiˆncia no desempenho dos caches DNS [11], pois h´ um aumento significativo nas
e a
falhas de cache devido ao pouco tempo em que um registro pode permanecer armazenado
localmente.
Neste cen´rio, seria interessante a utiliza¸˜o de um cache DNS proativo capaz de se
a ca
anteceder ` requisi¸ao de um cliente (atualizando conte´dos dinˆmicos) evitando assim
a c˜ u a
falhas no cache, acelerando a propaga¸ao de altera¸oes e por conseguinte, prevenindo a
c˜ c˜
perda de integridade dos registros DNS armazenados [24].
Sendo assim, este trabalho tem como proposta a utiliza¸˜o do paradigma de comuni-
ca
ca¸˜o publish/subscribe para dar esta caracter´
ca ıstica proativa ao servi¸o DNS.
c
Em resumo, publish/subscribe ´ um sistema que oferece aos assinantes a capacidade de
e
manifestar o seu interesse em um evento ou um padr˜o de eventos, a fim de ser notificado de
a
qualquer conte´do gerado por uma fonte que publica algo correspondente ao seu interesse.
u
Em outros termos, os produtores publicam informa¸˜es em um canal de software (um
co
gestor de eventos) e consumidores se inscrevem em informa¸˜es que querem receber do
co
respectivo canal [16].
Na Figura 1.1 podemos observar que o gestor de eventos seria implementado pelos
pr´prios servidores DNS atrav´s da cria¸ao de uma rede P2P (Peer-to-Peer ). Os pro-
o e c˜
dutores seriam os hosts cujos nomes estariam dispon´
ıveis no cache dos servidores DNS
participantes da rede.
Desta forma, ao haver mudan¸as em algum nome dos hosts participantes da rede, eles
c
se encarregariam de disparar mensagens de publica¸oes ` rede P2P, que por sua vez faria
c˜ a
notifica¸oes aos servidores DNS inscritos. Assim, essa altera¸ao seria propagada de forma
c˜ c˜
proativa para os caches.
A fim de comprovar de forma qualitativa a viabilidade da proposta apresentada, foi

12. 1 Introdu¸˜o
ca 3
Figura 1.1: Diagrama da Arquitetura Proposta
implementado um prot´tipo constitu´ de uma rede P2P capaz de gerir as funcionalidades
o ıdo
publish/subscribe, al´m de um servidor DNS juntamente com uma interface onde ´ poss´
e e ıvel
efetuar publica¸oes nesta rede.
c˜
Atrav´s do prot´tipo foram realizados testes com o intuito de demonstrar que ´ pos-
e o e
s´ a redu¸ao no tempo de resolu¸ao de nomes, utilizando o conceito apresentado.
ıvel c˜ c˜
O restante deste trabalho est´ organizado da seguinte forma: No cap´
a ıtulo 2 ´ apre-
e
sentada uma vis˜o geral sobre DNS e publish/subscribe. O cap´
a ıtulo 3 faz uma abordagem
sobre a implementa¸ao do prot´tipo desenvolvido. No cap´
c˜ o ıtulo 4 s˜o apresentados os tes-
a
tes e resultados obtidos e, por fim, s˜o apresentadas as conclus˜es e trabalhos futuros no
a o
cap´
ıtulo 5.

13. Capítulo 2
Conceitos Básicos
Este cap´
ıtulo visa proporcionar o entendimento b´sico dos conceitos relacionados ao
a
DNS e publish/subscribe.
2.1 O Protocolo DNS
Com o grande crescimento da Internet, em 1987 Mokapetris [21] [22] criou o conceito
de DNS. Antes, todos os n´s (hosts e servidores) integrantes da rede possu´
o ıam um ar-
quivo local no qual era armazenada uma tabela que mapeava os nomes das m´quinas
a
daquela rede em endere¸os IP (Internet Protocol ). Estes arquivos eram gerenciados cen-
c
tralmente pelo SRI-NIC (Stanford Research Institute - Network Information Center ) e,
periodicamente, cada computador na rede deveria atualizar seus arquivos para manter
tudo funcionando.
Tal solu¸ao logo se tornou invi´vel devido ` sua natureza n˜o escal´vel. Por isso,
c˜ a a a a
foi criado um sistema hier´rquico e escal´vel capaz de funcionar de forma distribu´
a a ıda,
tornando-se o protocolo DNS.
O Domain Name System (DNS) [21] ´ um sistema para atribui¸˜o e distribui¸ao de
e ca c˜
nomes para computadores e servi¸os de redes baseado na pilha TCP/IP. Endere¸os IP s˜o
c c a
usados pela camada de rede para determinar, sem ambiguidades, a localiza¸˜o de algum
ca
dispositivo dentro de uma mesma rede. A nomea¸ao oferecida pelo DNS ´ usada para
c˜ e
localiza¸ao de computadores e servi¸os atrav´s da utiliza¸˜o de nomes mnemˆnicos. Por
c˜ c e ca o
exemplo, para o usu´rio ´ muito mais f´cil gravar o nome www.ufes.br do que o endere¸o
a e a c
IP 172.20.3.121.
Segundo Tanenbaum [29] “a essˆncia do DNS ´ a cria¸˜o de um esquema hier´rquico de
e e ca a
atribui¸ao de nomes baseados no dom´
c˜ ınio de um sistema de banco de dados distribu´
ıdo

14. 2.1 O Protocolo DNS 5
para implementar esse esquema de nomenclatura”. A estrutura hier´rquica do DNS ´
a e
ilustrada na Figura 2.1.
Figura 2.1: Exemplo de ´rvore DNS
a
Servidores de nomes s˜o programas que mantˆm as informa¸oes sobre determinada
a e c˜
parte da ´rvore DNS, chamada de zona. Um servidor de nomes corresponde a um n´ na
a o
´rvore e responde com autoridade para os endere¸os daquela zona. Caso haja um subdo-
a c
m´
ınio, ele poder´ delegar para outro servidor de nomes os endere¸os de tal subdom´
a c ınio,
com o intuito de descentralizar a administra¸˜o dessas informa¸˜es. A tarefa b´sica de
ca co a
um servidor de nomes ´ responder `s requisi¸oes usando dados da sua zona.
e a c˜
O processo de obter informa¸ao do espa¸o de nomes de dom´ ´ chamado de resolu¸ao
c˜ c ınio e c˜
de nomes e o elemento DNS que desempenha tal tarefa ´ chamado de Resolvedor.
e
Supondo no cen´rio ilustrado na Figura 2.2, que um resolvedor localizado em ber-
a
kley.edu, queira acessar o host www.cs.colorado.edu, e que o servidor de nomes local
nunca tenha recebido uma consulta referente ao respectivo dom´
ınio e n˜o saiba nada so-
a
bre ele. O processo de resolu¸˜o de nomes se dar´ nas seguintes etapas: o resolvedor
ca a
poder´ consultar alguns servidores que ele j´ tenha conhecimento anterior, mas supondo
a a
que nenhum deles tenha informa¸˜es referentes ao destino procurado, ele encaminhar´ o
co a
pedido ao servidor edu (seta 1), por sua vez, o servidor edu conhece os seus endere¸os
c
filhos, e dentre eles, est´ o servidor colorado.edu (seta 2), que por sua vez conhece o
a
servidor cs.colorado.edu (seta 3), que por fim, conhece o servidor www.cs.colorado.edu.
Depois de finalmente chegar a um host que conhece o destino procurado, o pedido segue
o caminho inverso (setas 4,5,6) at´ chegar ao resolvedor. Esse m´todo de resolu¸˜o de
e e ca
nomes ´ denominado consulta recursiva.
e

15. 2.2 Publish/Subscribe 6
Figura 2.2: Consulta sem cache
Neste momento, o servidor local poder´ guardar esse registro em cache, mas sempre
a
respeitando campo TTL inclu´ no registro de resposta. Se algum outro pedido de
ıdo
resolu¸˜o de nomes referente ao host cs.colorado.edu for efetuado no mesmo servidor
ca
local, este poder´, respeitando o campo TTL, responder ` solicita¸ao com o seu registro
a a c˜
armazenado em cache e n˜o precisar´ fazer todo o caminho descrito no par´grafo acima,
a a a
assim o caminho percorrido seria apenas o ilustrado na Figura 2.3 (setas 1 e 2).
´
E evidente pensarmos que o uso de cache DNS acelera o processo de resolu¸ao de
c˜
´
nome, pois evita a necessidade de consultas externas. E necess´rio tamb´m ter em mente
a e
que isso s´ ´ poss´ se tivermos um valor de TTL alto, entre 1 e 24 horas [11].
oe ıvel
2.2 Publish/Subscribe
Segundo [16], publish/subscribe ´ um paradigma de comunica¸ao que busca prover
e c˜
desacoplamento e flexibilidade necess´rios para aplica¸oes distribu´
a c˜ ıdas de larga escala. O
paradigma se baseia em duas entidades principais: produtores e consumidores. Produ-
tores (publishers) s˜o aqueles que publicam os dados no sistema, enquanto consumidores
a
(subscribers) definem um formato de assinatura, a fim de expressar quais dos dados sendo
publicados s˜o de seu interesse.
a
O ato de registrar interesse em um conte´do ´ definido como inscri¸˜o, ent˜o consumi-
u e ca a

16. 2.2 Publish/Subscribe 7
Figura 2.3: Consulta com cache
dores podem fazer inscri¸oes em v´rios conte´dos, definidos como t´picos. A partir deste
c˜ a u o
momento, o consumidor est´ apto a receber mensagens referentes ao t´pico de interesse.
a o
O modelo de sistema b´sico de intera¸ao publish/subscribe conta com um servi¸o de
a c˜ c
eventos para armazenamento e gest˜o de assinaturas e entrega eficiente de mensagens,
a
denominado Broker, representando um mediador entre produtores e consumidores [16].
O Broker se encarrega de entregar a mensagem a cada consumidor, de forma que pro-
dutores n˜o precisam conhecer os consumidores das mensagens, assim como consumidores
a
n˜o necessitam conhecer os publicadores, removendo o acoplamento entre as entidades. De
a
acordo com [16], o esquema de intera¸˜o publish/subscribe, provˆ a forma de comunica¸ao
ca e c˜
fracamente acoplada, necess´ria a ambientes de larga escala, como a Internet.
a
A arquitetura do Broker pode ser implementada em duas poss´
ıveis arquiteturas [13]. A
primeira ´ centralizada com um unico servi¸o de notifica¸˜o, respons´vel por manter todos
e ´ c ca a
os registros de interesse, al´m de disseminar todas as publica¸oes geradas. A segunda ´
e c˜ e
distribu´ onde v´rios servidores est˜o interconectados e a carga de servi¸o ´ distribu´
ıda, a a c e ıda
entre eles.
Apesar de a arquitetura centralizada ter uma complexidade de implementa¸ao rela-
c˜
tivamente baixa, seu grande problema ´ relacionado ao desempenho. Assim, a arquite-
e
tura distribu´ ´ a escolha mais adequada para aplica¸˜es que requerem processamento
ıda e co

17. 2.2 Publish/Subscribe 8
de grandes quantidades de dados, al´m de ser uma arquitetura escal´vel [17], ou seja,
e a
quando h´ necessidade de se melhorar o desempenho do sistema, devido ` inclus˜o de
a a a
novos participantes, ´ poss´ a inclus˜o de mais um servidor facilmente.
e ıvel a
Uma das implementa¸oes de um broker distribu´ ´ a Scribe [6], que disponibiliza
c˜ ıdo e
a API (Application programming interface) proposta por Darek et al. [14], especificando
servi¸os de roteamento de mensagens, notifica¸˜o de eventos, busca e armazenamento
c ca
distribu´
ıdo, baseada na rede P2P Pastry [26].
Temos ent˜o trˆs entidades, Broker, produtor e consumidor. Os consumidores re-
a e
gistram interesse em t´picos, o produtor faz publica¸oes em um determinado t´pico e
o c˜ o
o broker fica respons´vel tanto por gerenciar as inscri¸˜es dos consumidores, quanto de
a co
despachar uma publica¸˜o dos produtores para os seus respectivos consumidores.
ca
Na Figura 2.4 temos um diagrama onde ´ poss´ observar as entidades envolvidas e
e ıvel
suas respectivas mensagens. Ainda podemos ver um ciclo completo de funcionamento do
publish/subscribe.
Primeiramente, o consumidor se registra em um t´pico, Subscribe (mensagem 1);
o
posteriormente temos uma publica¸ao, Publish (mensagem 2); e finalmente o consumidor
c˜
recebe esta publica¸˜o, Notify (mensagem 3).
ca
Figura 2.4: Diagrama das entidades envolvidas
Na Figura 2.5 podemos ver um diagrama da arquitetura proposta. Os Produtores
(Publishers) seriam os hosts, cujos nomes estariam dispon´
ıveis no cache dos servidores
DNS participantes da rede, enquanto o Consumidor (subscriber ) seria o servidor DNS
proposto.

18. 2.2 Publish/Subscribe 9
Figura 2.5: Diagrama da arquitetura proposta.

19. Capítulo 3
Implementação
Para demonstrar a viabilidade da solu¸˜o proposta neste documento, foi implementado
ca
um prot´tipo, que ser´ apresentado ao longo deste cap´
o a ıtulo.
A ideia original discutida anteriormente ´ de que cada n´ da rede Pastry seja tamb´m
e o e
um servidor DNS funcional, o que pode ser notado na Figura 1.1. Para simplificar o
trabalho, esta proposta foi modificada de forma que um m´dulo externo que implementa
o
o servi¸o DNS tenha acesso a um n´ espec´
c o ıfico da rede e possa trocar as mensagens de
inscri¸ao e notifica¸ao conforme a Figura 3.1. Dessa forma, os outros n´s n˜o implementam
c˜ c˜ o a
o servi¸o DNS. Estas altera¸oes n˜o invalidam os resultados obtidos nos testes, uma vez
c c˜ a
que em ambos os cen´rios apenas o n´ que recebe a requisi¸˜o executa servi¸os de resolu¸ao
a o ca c c˜
de nomes.
A Figura 3.1 mostra o produtor, o broker e o consumidor. O papel designado inicial-
mente ao produtor seria executado pelos hosts que tivessem seus nomes disponibilizados
pelos servidores DNS participantes da rede. Por simplifica¸ao, essa funcionalidade foi
c˜
implementada na forma de uma interface gr´fica onde ´ feita a alimenta¸ao do nome do
a e c˜
host com seu respectivo endere¸o IP a fim de disparar uma mensagem de notifica¸˜o para
c ca
que pudesse ser observada a atualiza¸˜o proativa do cache DNS.
ca
A troca de mensagens entre o cache DNS e os agentes que se encontram fora da linha
tracejada (que representa a implementa¸˜o efetuada no trabalho), que seriam os usu´rios
ca a
e o servidor DNS externo, segue a especifica¸˜o padr˜o definida na RFC 1035 [22]. Com
ca a
isso, ´ poss´ que um usu´rio fa¸a a utiliza¸ao da implementa¸ao realizada neste trabalho
e ıvel a c c˜ c˜
como seu servidor DNS principal.
Podemos dividir a implementa¸˜o em trˆs m´dulos: Scribe, que ´ respons´vel por
ca e o e a
disponibilizar as funcionalidades de um Broker publish/subscribe; DNSHandler, que dis-
ponibiliza servi¸os DNS al´m de interagir com o Broker, e uma Interface Gr´fica que ´
c e a e

20. 3.1 Scribe 11
respons´vel pelo papel de produtor.
a
Figura 3.1: Diagrama da arquitetura implementada
3.1 Scribe
3.1.1 Visão Geral
Scribe [10], ´ uma implementa¸˜o distribu´ do publish/subscribe rodando em cima
e ca ıda
da rede P2P Pastry (implementada por FreePastry [4]). Ela foi escolhida por trazer
uma API bem documentada, de f´cil entendimento e que possu´ todas as caracter´
a ıa ısticas
desejadas para o desenvolvimento deste trabalho Al´m de ser escrita em Java [5], o que
e
facilitou a reutiliza¸ao do servi¸o DNSHandler utilizado neste trabalho e explicado na
c˜ c
se¸ao 3.2.
c˜
O Pastry [15] visa construir uma rede P2P estruturada, descentralizada, auto orga-
niz´vel e tolerante a falhas para aplica¸˜es P2P. Todos os n´s da rede juntamente com a
a co o
informa¸ao que ela armazena s˜o identificados em um espa¸o de endere¸amento compar-
c˜ a c c
tilhado, constitu´ por um identificador de 128 bits.
ıdo
Por possuir um espa¸o de endere¸amento compartilhado, n˜o h´ como distinguir uma
c c a a
informa¸ao e um n´ apenas pelo seu identificador. Por quest˜es did´ticas, nodeId e chave
c˜ o o a

21. 3.1 Scribe 12
ser˜o usados ao se referir ao identificador de um n´ e conte´do, respectivamente.
a o u
O nodeId, al´m de identificar um n´, indica sua posi¸˜o em um espa¸o de identifica-
e o ca c
dores circulares. Uma chave ´ mapeada para um n´ cujo nodeId est´ numericamente mais
e o a
pr´ximo da identifica¸ao da chave.
o c˜
O nodeId ´ gerado atrav´s de uma fun¸˜o Hash aplicada ao IP de um n´, a fun¸˜o
e e ca o ca
hash tem como objetivo transformar informa¸oes em chaves de tamanhos fixos, como se
c˜
fossem impress˜es digitais daquelas informa¸˜es [25].
o co
Como exemplo, podemos citar a fun¸˜o hash MD5 (Message-Digest algorithm 5) [25]
ca
que ´ um algoritmo de hash de 128 bits. Ao aplicar a fun¸˜o ao IP “172.31.24.44” temos
e ca
como resultado a chave " 6e26e8fa9c28c702092c87659ffcfcd4", seu objetivo ´ identificar o
e
n´ no espa¸o compartilhado citado anteriormente.
o c
Para demonstrar o espa¸o compartilhado, podemos aplicar a mesma fun¸ao hash no
c c˜
nome “www.ufes.br” tendo como resultado a chave “5c90bb261623c8d7dcfcb03fb4be1806”
que possui o mesmo tamanho (128 bits) do exemplo anterior que se tratava de um IP.
Para a organiza¸ao da estrutura em formato de anel, cada n´ pertencente ` rede Pastry
c˜ o a
mant´m, entre outras informa¸˜es, o nodeId de seus n´s adjacentes (ou n´s vizinhos) e uma
e co o o
tabela de roteamento que possui registros de outros n´s da rede localizados mais distantes
o
no anel (a fim de diminuir o n´mero de saltos no encaminhamento das mensagens na
u
rede).
Quando um n´ com nodeId A recebe uma mensagem com chave D, ele verifica se A ´
o e
o nodeId mais pr´ximo de D, baseado no nodeId de seus vizinhos (sucessor e antecessor).
o
Caso ele seja efetivamente o n´ mais pr´ximo, ser´ o respons´vel pela chave D. Caso
o o a a
contr´rio, o n´ dever´ fazer o roteamento da mensagem no anel.
a o a
O processo de roteamento ´ executado com base na tabela de roteamento, com a qual
e
um n´ decide o que fazer com uma mensagem. O funcionamento da tabela e seu processo
o
de preenchimento fogem do escopo deste texto, e por isso, n˜o ser˜o abordados. Seu
a a
funcionamento pode ser encontrado na referˆncia [26].
e
A Figura 3.2, exemplifica um processo de roteamento, o n´ 65a1fc recebe uma mensa-
o
gem com a chave d46a1, ao verificar que ele n˜o ´ o respons´vel por tal chave, a mensagem
a e a
´ encaminhada at´ o n´ d13da3, o mais pr´ximo presente na sua tabela de roteamento.
e e o o
Esse processo se repete at´ a mensagem chegar ao n´ d467c4.
e o
Utilizando o nodeId de seus vizinhos, o n´ d467c4 verifica que tanto as distˆncias
o a

22. 3.1 Scribe 13
Figura 3.2: Exemplo de anel Pastry
entre a chave (d46a1c) e seu antecessor (d462ba), quanto a chave (d46a1c) e seu sucessor
(d471f1), s˜o maiores do que a distancia entre seu pr´prio nodeId e a chave da mensagem
a o
(o que pode ser notado pela distˆncia espacial mostrada na Figura), assim o n´ d467c4
a o
identifica que ´ o respons´vel pela chave procurada.
e a
Como dito anteriormente, este documento fez uso da SCRIBE, capaz de gerir as
funcionalidades do publish/subscribe sobre a rede Pastry. Para tal foi utilizado a API de
desenvolvimento Scribe apresentada em [27].
1. API Pastry
De forma simplificada, a API Pastry exporta as seguintes fun¸oes utilizadas pela
c˜
aplica¸˜o SCRIBE [26] [27]:
ca
(a) nodeId = pastryInit(Credentials, Application)
Faz com que um n´ participe de uma rede Pastry existente (ou come¸e uma
o c
nova), e retorne o nodeId do n´ local. O argumento Credentials cont´m in-
o e
forma¸oes necess´rias para autenticar o n´. O argumento Application ´ um
c˜ a o e
identificador para o objeto que fornece os procedimentos a serem invocados
quando determinados eventos ocorrem, por exemplo, uma chegada de mensa-
gem.
(b) route(msg,key)

23. 3.1 Scribe 14
Procedimento para encaminhar a mensagem msg para o n´ com nodeId nume-
o
ricamente mais pr´ximo da chave key, dentre todos os n´s Pastry dispon´
o o ıveis.
(c) send(msg,IP-addr)
Procedimento para enviar a mensagem msg ao n´ com o endere¸o IP especifi-
o c
cado. A mensagem ´ recebida atrav´s do m´todo deliver().
e e e
(d) deliver(msg,key)
Chamado por Pastry quando uma mensagem ´ recebida e nodeId do n´ ´
e o e
numericamente mais pr´ximo da chave key, entre os vizinhos no anel. Isso
o
quer dizer que o n´ atual ´ o respons´vel pela mensagem.
o e a
(e) forward(msg,key,nextId)
Chamado por Pastry pouco antes de uma mensagem ser enviada para o n´
o
seguinte, o aplicativo pode alterar o conte´do da mensagem ou o valor do
u
pr´ximo n´ (nextId). Definir o pr´ximo n´ como NULL termina o roteamento
o o o o
da mensagem no n´ local.
o
2. API Scribe
Segundo [27] Scribe oferece a seguinte API para suas aplica¸˜es:
co
(a) create(credentials, topicId)
Cria um t´pico (topicId ), e utiliza credentials para gerir controle de acesso.
o
(b) subscribe(credentials, topicId, eventHandler)
Inscreve o n´ local no t´pico definido por topicId, Todos os eventos recebidos
o o
posteriormente para o assunto s˜o passados para o manipulador de eventos
a
especificado (eventHandler ).
(c) unsubscribe(credentials, topicId)
Remove a inscri¸ao do n´ atual do t´pico especificado em topicId.
c˜ o o
(d) publish(credentials, topicId, event)
Faz com que o evento event seja publicado no t´pico topicId.
o
3.1.2 Modicações
A implementa¸˜o foi baseada no c´digo de exemplo dispon´ em [7]. Esta imple-
ca o ıvel
menta¸ao traz trˆs classes que ser˜o explicadas a seguir, junto `s modifica¸oes efetuadas
c˜ e a a c˜
para adequa¸ao no trabalho.
c˜

24. 3.1 Scribe 15
1. Classe MyScribeContent
Esta classe define o tipo de conte´do a ser enviado dentro de uma mensagem gerada
u
por um Produtor (host). Inicialmente, ela possu´ a identifica¸ao do remetente e um
ıa c˜
n´mero inteiro, esses dados eram irrelevantes na solu¸˜o proposta, ent˜o a classe foi
u ca a
modificada para que pudesse carregar uma string que cont´m o nome do produtor
e
junto ao IP do mesmo. Essas informa¸oes s˜o necess´rias para que o consumidor
c˜ a a
(neste caso o servidor DNS implementado no trabalho) possa atualizar os registros
contidos em seu cache.
2. Classe MyScribeClient
Define o comportamento (m´todos) dos servi¸os publish/subscribe, os que interes-
e c
sam no contexto deste trabalho s˜o:
a
(a) subscribe(String topico)
Este m´todo trata o pedido de inscri¸˜o em um t´pico passado como parˆme-
e ca o a
tro, inicialmente ele n˜o recebia nenhum parˆmetro, pois o nome do t´pico era
a a o
fixo. Ao executar esse m´todo, ´ utilizada uma fun¸ao hash interna do Fre-
e e c˜
ePastry para a cria¸ao de um nodeId, e posteriormente ´ chamado o m´todo
c˜ e e
subscribe herdado da classe BaseScribe que processa o pedido de inscri¸ao.
c˜
(b) sendMulticast(String topico, InetAddress ip)
´
E a interface de publica¸˜o, inicialmente ele apenas publicava um n´mero se-
ca u
quencial em um t´pico fixo. Ele foi modificado para receber como parˆmetro o
o a
nome de um host e o seu respectivo IP. Tais dados s˜o encapsulados pela classe
a
MyScribeContent e despachados pelo m´todo publish() herdado da classe Ja-
e
vaScribe que processa o envio a todos os inscritos no respectivo t´pico.
o
(c) deliver(Topic topic, ScribeContent content)
´
E executado toda vez que o n´ recebe uma publica¸ao destinada a ele pr´-
o c˜ o
prio, a partir da´ a publica¸ao torna-se uma notifica¸˜o. Inicialmente, apenas
ı, c˜ ca
mostra uma mensagem dizendo que o n´ recebeu uma publica¸ao junto ao seu
o c˜
conte´do. Na implementa¸ao da solu¸ao proposta, ´ respons´vel por disparar
u c˜ c˜ e a
a atualiza¸˜o do cache do servidor DNS proativo, chamando um m´todo da
ca e
classe que implementa o cache DNS.
3. Classe ScribeTutorial
Tem como objetivo iniciar o ambiente FreePastry, possui o m´todo main que d´
e a
in´ ` execu¸ao do programa.
ıcio a c˜

25. 3.2 DNSHandler 16
Foi modificada para tamb´m dar inicio ao servi¸o DNS ` interface que d´ acesso
e c a a
para o usu´rio ao processo de publica¸oes na rede.
a c˜
Como o intuito deste trabalho ´ demonstrar a viabilidade da solu¸ao, esta classe
e c˜
instancia v´rios n´s da rede Pastry na mesma m´quina. Para isso, cada n´ ´ ins-
a o a oe
tanciado com uma porta TCP diferente, assim todos os n´s ficam dispon´
o ıveis para
trocarem informa¸˜es entre si. Nesta etapa, ´ poss´
co e ıvel definir quantos n´s ser˜o
o a
instanciados.
No momento da cria¸˜o dos n´s, dois deles s˜o escolhidos para serem os n´s de
ca o a o
entrada para o cache DNS (consumidor) e para a interface de publica¸ao (produtor).
c˜
Por simplifica¸˜o, foram escolhidos sempre o primeiro n´ instanciado e o n´ N/2,
ca o o
onde N representa o n´mero total de n´s a serem instanciados.
u o
Ap´s a inicializa¸˜o da rede Pastry, a classe faz a inicializa¸˜o em forma de threads,
o ca ca
dos servi¸os de DNS e de interface de publica¸˜es. Neste momento, a solu¸˜o est´
c co ca a
pronta para uso.
3.2 DNSHandler
O servidor DNS implementado foi baseado no c´digo utilizado no trabalho de conclu-
o
s˜o de curso do aluno Matheus Vieira Costa [12], seu funcionamento ´ ilustrado na Figura
a e
3.3, onde podemos ver um fluxograma de funcionamento do DNS.
A primeira tarefa realizada pelo DNSHandler consiste em esperar alguma requisi¸ao
c˜
feita na porta 53 [19], utilizada como padr˜o para consultas DNS atrav´s do protocolo
a e
UDP durante a comunica¸ao. Esta funcionalidade ´ implementada pela classe DNSHan-
c˜ e
dlerServer.
Ao receber uma requisi¸˜o, o objeto DNSHandlerServer dispara uma thread, defi-
ca
nida pela classe DNSHandlerResponse. A partir deste momento, o aplicativo extrai as
informa¸oes contidas na requisi¸˜o. Inicialmente a unica informa¸ao necess´ria ´ o campo
c˜ ca ´ c˜ a e
nome, por´m o formato do nome n˜o era adequado para uso, o que exigiu um tratamento
e a
sobre o mesmo para enfim poder ser utilizado. Um nome como‘www.terra.com.br’, e re-
presentado no protocolo DNS como ‘3www5terra3com2br’, no qual tem os pontos, que
representam mudan¸as de n´
c ıveis na ´rvore hier´rquica do DNS, substitu´
a a ıdos por n´meros
u
que representam a quantidade de caracteres representados pelo determinado n´ [12].
ıvel
Possuindo o nome a ser consultado, ´ feita uma pesquisa do registo em cache, o cache
e

26. 3.2 DNSHandler 17
Figura 3.3: Fluxograma do DNSHandler

27. 3.3 Interface de Publica¸˜o (Publish)
ca 18
´ implementado pela classe DNSCache, esta classe apenas faz o encapsulamento de uma
e
Hashtable que cont´m como ´
e ındice uma string que representa um nome de dom´
ınio e
seu conte´do ´ um IP.
u e
Note que em uma implementa¸˜o real de cache, se faz necess´rio o armazenamento
ca a
de mais dados como TTL e informa¸oes para que seja poss´
c˜ ıvel verificar se o registro
armazenado expirou, dentre outras informa¸oes. Como n˜o ´ objetivo da implementa¸ao
c˜ a e c˜
a cria¸ao de uma aplica¸˜o para uso fora de um ambiente controlado, isso foi omitido na
c˜ ca
solu¸˜o.
ca
Se a resposta do cache for positiva (isso quer dizer que o retorno ´ um IP), o programa
e
envia uma resposta ` requisi¸ao. Caso contr´rio, o cache responder´ com NULL, indicando
a c˜ a a
que n˜o possui o registro solicitado.
a
Caso a resposta do cache seja negativa (NULL), o programa far´ o pedido de inscri¸˜o
a ca
no t´pico referente ao nome solicitado ` rede Pastry. Neste momento, o cache estar´ apto
o a a
a receber notifica¸˜es advindas do referido nome.
co
Quando um nome n˜o est´ em cache, o programa faz uma consulta a um servidor
a a
de DNS externo. Ao receber a resposta, o programa extrai o IP da solicita¸˜o inicial
ca
e o insere, junto com o seu nome, no cache. Como dito anteriormente, o campo TTL
(Time To Live) ´ ignorado nesta etapa, pois a solu¸ao parte do pressuposto que todas
e c˜
as atualiza¸oes posteriores a este momento ser˜o fornecidas pela rede Pastry. Por isso,
c˜ a
assume-se que um registro que esteja contido em cache sempre seja o mais atual dispon´
ıvel.
Ap´s este passo, podemos montar o pacote DNS de resposta (response) seguindo as
o
defini¸oes da RFC 1035 [22], preenchendo o campo referente ao IP do dom´
c˜ ınio solicitado,
depois esse pacote ´ enviado ao cliente atrav´s do seu IP que foi armazenado no in´ do
e e ıcio
processo.
3.3 Interface de Publicação ( Publish )
Esta parte da implementa¸ao simula o papel dos hosts que possuem seus nomes in-
c˜
clu´
ıdos na rede Pastry, para isso o usu´rio precisa preencher dois campos, o T´pico, que
a o
representa o nome do host, e o seu endere¸o IP.
c
Feito isso, o programa dispara uma publica¸˜o (publish), atrav´s de um m´todo p´-
ca e e u
blico dispon´ por um n´ em espec´
ıvel o ıfico da rede Pastry (este n´ ´ escolhido, descrita no
oe
item 3.2.1) que ser´ entregue ao servi¸o DNS atrav´s de uma mensagem de notifica¸ao.
a c e c˜

28. 3.3 Interface de Publica¸˜o (Publish)
ca 19
Figura 3.4: Formul´rio de publica¸ao de um t´pico
a c˜ o
Figura 3.5: Formul´rio de publica¸˜o de um IP
a ca

29. Capítulo 4
Funcionamento do Protótipo e Testes
Com o objetivo de averiguar a viabilidade da solu¸ao proposta, foram executados
c˜
alguns testes usando a implementa¸ao descrita no capitulo 3 deste documento.
c˜
Como o escopo do documento n˜o contemplava um ambiente real, todos os testes
a
foram executados dentro de um ambiente controlado, o que facilita o entendimento dos
resultados obtidos sem comprometer a qualidade dos testes.
Com o intuito de garantir a clareza dos testes, foram levantados quatro cen´rios:
a
1. Direto (Consulta direta a um servidor externo).
Foram feitas consultas diretamente ao servidor externo, sem a utiliza¸˜o da imple-
ca
menta¸ao. Tem por objetivo o levantamento de valores de referˆncia.
c˜ e
2. Sem Cache.
´
E utilizada a implementa¸ao proposta, mas o cache da aplica¸˜o encontra-se vazio,
c˜ ca
por isso ´ necess´rio consultar um servidor externo para que seja poss´ responder
e a ıvel
` requisi¸˜o.
a ca
3. Com Cache.
O dom´
ınio consultado est´ em cache e por isso n˜o h´ obrigatoriedade em se con-
a a a
sultar um servidor externo.
4. Cache Pastry (Consulta com cache atualizado pela rede Pastry).
O dom´ ´
ınio consultado est´ em cache e foi atualizado pela rede Pastry. E o ponto
a
chave da solu¸ao proposta. Temos que ter em mente, neste momento, que o resultado
c˜
esperado deste cen´rio ser´ equivalente ao cen´rio 3 (consulta Com Cache), isso se
a a a
d´ ao fato de a resposta neste cen´rio n˜o possuir diferen¸a alguma de uma simples
a a a c
resposta contida em cache.

30. 4 Funcionamento do Prot´tipo e Testes
o 21
Ao contr´rio de uma solu¸˜o convencional, o cache desta implementa¸ao, por de-
a ca c˜
fini¸ao, n˜o sofre com falhas de cache (cache miss) causados por TTL . Isso s´ ´
c˜ a oe
poss´ gra¸as ` rede Pastry, que fica encarregada de manter o cache sempre atu-
ıvel c a
alizado, pois ao ocorrerem modifica¸oes nos dom´
c˜ ınios armazenados, ´ esperado que
e
seja feita a sua atualiza¸ao atrav´s de uma publica¸˜o.
c˜ e ca
Em uma solu¸˜o convencional, mesmo contendo um registro em cache, se esse re-
ca
gistro estiver expirado (seu tempo de permanˆncia no cache for maior do que seu
e
TTL), ser´ necess´ria uma consulta a outros servidores DNS, com isso espera-se um
a a
tempo de resposta parecido com uma consulta sem cache.
Os testes foram executados com o aux´ da ferramenta DIG (Domain Information
ılio
Groper ). Com ela podemos levantar o tempo que uma consulta DNS demora para ser
respondida, o IP de resposta, dentre outras informa¸˜es n˜o relevantes para este trabalho.
co a
Figura 4.1: Interface da ferramenta DIG
Na Figura 4.1, podemos observar na primeira linha “C:dig ufes.br @8.8.8.8 ”, isso
quer dizer que foi feita uma consulta do dom´ ufes.br utilizando o servidor DNS 8.8.8.8.
ınio
Nesta ferramenta dois dados ser˜o importantes, o Query time, que indica o tempo
a
de resolu¸˜o do nome e o IP associado ao dom´
ca ınio. Neste caso, temos dois endere¸os IP
c
associados.
Na Figura 4.2, podemos observar o IP 172.31.24.44 associado ` m´quina onde foram
a a
realizados os testes, esse IP ser´ utilizado posteriormente nos testes.
a
Na Figura 4.3, podemos observar a interface do programa em execu¸ao, que foi im-
c˜

31. 4 Funcionamento do Prot´tipo e Testes
o 22
Figura 4.2: Janela indicando o IP atual
plementado e testado utilizando a IDE (Integrated Development Environment) Eclipse na
sua vers˜o Juno [3].
a
Podemos observar no Console algumas sa´
ıdas geradas pelo Freepastry, elas indicam
que os n´s pastry foram iniciados com sucesso, juntamente com uma parte do nodeId.
o
Nas duas ultimas linhas, podemos observar as frases: Servidor dns Rodando, in-
´
dicando que ocorreu tudo bem na inicializa¸ao do servidor DNS e Cliente Rodando,
c˜
indicando que a Interface de Publica¸˜o (Publish) tamb´m foi inicializada sem erros.
ca e
A partir desse momento, a ferramenta est´ apta a receber solicita¸oes de resolu¸˜o de
a c˜ ca
nomes.
Para demonstrar todas as funcionalidades do prot´tipo, foram executadas as seguintes
o
tarefas, respectivamente:
• Atrav´s da ferramenta Dig foram feitas duas consultas consecutivas ao prot´tipo
e o
para resolver o dom´
ınio ufes.br
Na Figura 4.4 podemos observar um Query time de 72 ms (milissegundos) na pri-
meira consulta e 3 ms na segunda consulta. Isso ocorre porque na segunda consulta o
registro encontra-se em cache, como podemos observar na sa´ do console, ilustrado
ıda
na Figura 4.5

32. 4 Funcionamento do Prot´tipo e Testes
o 23
Figura 4.3: Interface da IDE Eclipse rodando o prot´tipo
o

33. 4 Funcionamento do Prot´tipo e Testes
o 24
Figura 4.4: Tempo de duas consultas consecutivas
Figura 4.5: Console indicando consultas

34. 4 Funcionamento do Prot´tipo e Testes
o 25
• Foi executada uma publica¸ao no dom´
c˜ ınio ufes.br , atualizando seu IP para 2.2.2.2.
Este IP foi escolhido arbitrariamente apenas para ilustrar o funcionamento do pro-
grama.
Figura 4.6: Formul´rio de publica¸˜o
a ca
Figura 4.7: Formul´rio de publica¸˜o
a ca
Na Figura 4.8, temos a sa´ do Console indicando que o n´ 5 (esse n´mero indica
ıda o u
apenas a ordem que o n´ foi criado e n˜o representa seu NodeId ) recebeu um pu-
o a
blish e fez o encaminhamento para a rede Pastry, com isso a rede pastry fez uma
notifica¸˜o ao n´ 0, que ´ o respons´vel por atualizar o cache, em seguida temos a
ca o e a
mensagem que o n´ esta sendo atualizado.
o
Figura 4.8: Console indicando o envio e recebimento de uma publica¸ao
c˜
• Foi executada novamente uma consulta ao prot´tipo a fim de averiguar se realmente
o
foi atualizado o registro do dom´
ınio ufes.br
Na Figura 4.9, podemos observar que o endere¸o IP foi atualizado para o que era
c
esperado.
Na Figura 4.10, podemos observar a sa´ do Console indicando que o registro
ıda
estava em cache, e que seu IP ´ 2.2.2.2. Note que esta sa´ n˜o difere em nada da
e ıda a

35. 4 Funcionamento do Prot´tipo e Testes
o 26
Figura 4.9: DIG mostrando uma mudan¸a no IP
c
Figura 4.10: Mudan¸a no IP mostrada pelo Console
c
Figura 4.5, pois apesar da consulta ter sido feita em um registro modificado pela
rede Pastry, isso n˜o modifica em nada o processo de resolu¸ao a partir de registros
a c˜
em cache.
Os testes foram executados com base nos 10 nomes mais visitados no Brasil, em
Janeiro de 2013, por um estudo realizado pelo site Alexa [1] da Amazon. Cada nome foi
consultado 10 vezes em cada cen´rio, citados no in´ deste cap´
a ıcio ıtulo: Direto, Sem Cache,
Com Cache e Cache Pastry.
A quantidade de 10 consultas foi definida com base na pequena varia¸ao de tempo
c˜
encontrada ao longo dos testes, isso indica que os dados eram bastantes est´veis no mo-
a
mento da avalia¸ao e por isso um n´mero maior de repeti¸oes n˜o traria acr´scimo de
c˜ u c˜ a e
informa¸oes relevantes.
c˜
A Tabela 4.1 mostra os resultados obtidos para cada caso testado com a sua referida
m´dia e desvio padr˜o.
e a
Sobre os resultados obtidos, podemos observar um leve aumento no tempo de resposta
se compararmos os casos Direto e Sem Cache. Isso se deve ao fato de haver um atraso
devido ao processamento interno do prot´tipo ` requisi¸ao.
o a c˜

36. 4 Funcionamento do Prot´tipo e Testes
o 27
Tabela 4.1: Tabela com resultado dos testes
Nomes Direto Sem Cache Com Cache Cache Pastry
(ms) (ms) (ms) (ms)
facebook.com 26 29 3 2
google.com.br 26 30 3 3
google.com 26 31 4 3
youtube.com 26 32 3 4
uol.com.br 29 40 2 2
live.com 26 28 3 4
globo.com 26 29 3 2
blogspot.com.br 29 33 2 3
yahoo.com 26 31 3 3
mercadolivre.com.br 26 30 2 4
M´dia
e 26,6 31,3 2,8 3
Desvio Padr˜oa 1,26 3,40 0,63 0,82
Se compararmos os tempos de resposta dos cen´rios Sem Cache e Com Cache, podemos
a
notar um grande salto de desempenho, isso deve-se principalmente ` latˆncia da rede, pois
a e
ao fazer uma consulta externa, temos que considerar a infraestrutura da rede, a distˆncia
a
f´
ısica entre o cliente e o servidor DNS, dentre outros fatores. Essa latˆncia prejudica uma
e
resolu¸˜o sem cache.
ca
Em contrapartida, na resolu¸ao em cache, a latˆncia de rede verificada nos experimen-
c˜ e
tos praticamente n˜o existe, pois tanto o servidor DNS quanto o cliente est˜o rodando na
a a
mesma m´quina.
a
Em um ambiente real, mesmo a solu¸˜o proposta provavelmente teria um aumento
ca
nos tempos de resposta, pois ´ de se esperar que neste cen´rio servidor e cliente estejam
e a
em m´quinas diferentes, e com isso tamb´m sofram com a latˆncia da rede.
a e e
Mas para provar que uma resolu¸˜o, mesmo em um ambiente real, na maioria das
ca
vezes ´ mais r´pida quando o registro encontra-se em cache, foi feito um teste com o
e a
programa DNS Benchmark [2].
O DNS Benchmark ´ um aplicativo que permite efetuar testes de benchmark para
e
analisar e comparar o desempenho de v´rios servidores DNS.
a
Na Figura 4.11, podemos notar que o servidor (exceto o local, mostrado em primeiro
da lista), com melhor desempenho (destacado na Figura) teve um desempenho 3 vezes
maior quando as requisi¸˜es estavam em cache (Cached ), se comparadas `s resolu¸oes que
co a c˜
n˜o estavam em cache (Uncached ).
a

37. 4 Funcionamento do Prot´tipo e Testes
o 28
Figura 4.11: Comparativo de desempenho entre servidores DNS
Se compararmos os cen´rios Com Cache e Cache Pastry, poderemos notar resultados
a
parecidos, como era esperado, haja vista que n˜o existe diferen¸a alguma no processo de
a c
resolu¸˜o nesses dois cen´rios.
ca a
Isso pode parecer estranho no primeiro momento, mas temos que ter em mente o que
foi dito da descri¸˜o do cen´rio Cache Pastry. O ganho da solu¸˜o acontece no instante
ca a ca
que um registro em cache expira; nesse momento a solu¸ao proposta continua respondendo
c˜
com o tempo descrito no cen´rio Cache Pastry devido ao cache ser proativo, enquanto
a
uma solu¸ao tradicional demoraria o tempo do cen´rio Sem Cache, pois se o registro
c˜ a
encontra-se espirado ´ como se ele n˜o estivesse em cache.
e a

38. Capítulo 5
Conclusão e trabalhos futuros
As ferramentas que possibilitam o funcionamento da Internet nem sempre s˜o as me-
a
lhores solu¸˜es conhecidas, isso pode ocorrer por v´rios motivos. Muitos servi¸os utilizados
co a c
por n´s foram pensados em um ambiente totalmente diferente, dentro de universidades
o
ou de uso militar e hoje se encontram em uma rede mundial, que est´ presente em todos
a
os continentes e com milh˜es de usu´rios.
o a
Essa mudan¸a de contexto muitas vezes sobrecarrega esses servi¸os e sua migra¸ao
c c c˜
para outras tecnologias nem sempre ´ t˜o simples. Podemos citar como exemplo a mi-
e a
gra¸˜o do IPv4 para o IPv6, o primeiro rascunho do IPv6 est´ descrito na RFC 1752 [8]
ca a
em 1994, e suas especifica¸˜es foram oficializadas pelo IETF (Internet Engineering Task
co
Force) apenas em 2012, e sua migra¸ao por completa se quer tem previs˜o de t´rmino.
c˜ a e
Mas essa dificuldade de ado¸˜o de novas tecnologias n˜o pode desencorajar os pes-
ca a
quisadores, pois v´rias dessas mudan¸as s˜o simplesmente inevit´veis para que a Internet
a c a a
continue funcionando.
Temos hoje uma mudan¸a significativa no que diz respeito ` utiliza¸˜o de valores de
c a ca
TTL em cache DNS, que s˜o cada vez menores. Isso degrada o desempenho de servidores
a
DNS e come¸a a tornar-se um problema. Na literatura temos v´rias implementa¸˜es que
c a co
tentam resolver esse problema.
Muitas dessas implementa¸˜es tiveram como preocupa¸ao o esfor¸o de migra¸ao para
co c˜ c c˜
tal solu¸ao, por isso podem n˜o ser a solu¸ao mais eficaz no que diz respeito a desempenho.
c˜ a c˜
Este trabalho n˜o julgou o crit´rio esfor¸o de migra¸˜o em nenhum momento, por isso
a e c ca
a solu¸ao partiu de alguns pressupostos que podem afast´-la de uma solu¸˜o real, mas o
c˜ a ca
objetivo era experimentar algo ainda n˜o estudado como base de inspira¸˜o para novas
a ca
propostas.

39. 5 Conclus˜o e trabalhos futuros
a 30
Por esse motivo, n˜o foram feitos testes de desempenho da ferramenta em ambientes
a
de alta carga de trabalho, e sim testes qualitativos para demonstrar a viabilidade da
solu¸˜o.
ca
Por´m, atrav´s dos resultados obtidos fica comprovada a hip´tese de que ´ poss´
e e o e ıvel
implementar um cache DNS proativo de forma transparente ao usu´rio (ou seja, n˜o ´
a a e
necess´rio efetuar modifica¸˜es nos programas clientes) a fim de melhorar o desempenho
a co
da resolu¸ao de nomes atrav´s da solu¸ao proposta.
c˜ e c˜
Como o escopo do projeto contempla testes controlados fora de um ambiente real, seu
prot´tipo teve muitas implementa¸oes simplificadas, por isso existem v´rias sugest˜es de
o c˜ a o
trabalhos futuros como:
• Melhoria do DNSHandler a fim de responder corretamente a erros de resolu¸ao, al´m
c˜ e
de responder a qualquer tipo de registros DNS.
• Criar um protocolo de comunica¸ao baseado em IP para comunica¸˜o de uma apli-
c˜ ca
ca¸ao externa ` interface de publica¸˜o implementada.
c˜ a ca
• Incorporar o servi¸o DNSHandler a todos os n´s da rede Pastry para possibilitar a
c o
simula¸ao em um ambiente distribu´
c˜ ıdo.
• Melhorar a implementa¸ao do cache DNS para que possa verificar a expira¸ao de
c˜ c˜
um registro, caso n˜o seja atualizado por uma publica¸˜o antes de expirar.
a ca
• Aplicar e testar a ideia de cache proativo em redes CDN (Content Delivery Networks).

40. Referências
[1] Alexa top sites in brazil. http://www.alexa.com/topsites/countries/BR. aces-
sado: 15/01/2013.
[2] Domain name speed benchmark. http://www.grc.com/dns/benchmark.htm. aces-
sado: 12/04/2012.
[3] Eclipse. http://www.eclipse.org. acessado: 20/05/2012.
[4] Freepastry. http://www.freepastry.org. acessado: 19/05/2012.
[5] Java. http://www.java.com. acessado: 19/05/2012.
[6] Scribe, a scalable group communication system. http://www.freepastry.org/
SCRIBE/default.htm. acessado: 12/04/2012.
[7] Scribe tutorial. https://trac.freepastry.org/wiki/tut_scribe. acessado:
19/05/2012.
[8] Bradner, S., Mankin, A. The Recommendation for the IP Next Generation
Protocol. RFC 1752, Internet Engineering Task Force, janeiro de 1995.
[9] Brisco, T. DNS Support for Load Balancing. RFC 1794, Internet Engineering Task
Force, abril de 1995.
[10] Castro, M., Druschel, P., Kermarrec, A. M., Rowstron, A. I. Scribe: a
large-scale and decentralized application-level multicast infrastructure. IEEE J.Sel.
A. Commun. 20, 8 (setembro de 2006), p. 1489–1499.
[11] Chen, X., Wang, H., Ren, S. Dnscup: Strong cache consistency protocol for dns.
Em Distributed Computing Systems, 2006. ICDCS 2006. 26th IEEE International
Conference on (2006), p. 40.
[12] Costa, M. V. Avalia¸ao de servi¸os para computa¸ao em nuvem para implanta¸ao
c˜ c c˜ c˜
de um servi¸o de resolu¸˜o de nomes. Trabalho de conclus˜o de curso, Universidade
c ca a
Federal do Esp´
ırito Santo, S˜o Mateus, 2012.
a
[13] Cugola, G., Jacobsen, H.-A. Using publish/subscribe middleware for mobile
systems. SIGMOBILE Mob. Comput. Commun. Rev. 6, 4 (outubro de 2002), p. 25–
33.
[14] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., Stoica, I. Towards
a common api for structured peer-to-peer overlays. Em Proceedings of the 2nd In-
ternational Workshop on Peer-to-Peer Systems (IPTPS03) (Berkeley, CA, February
2003).

41. Referˆncias
e 2
[15] Druschel, P., Rowstron, A. Past: a large-scale, persistent peer-to-peer sto-
rage utility. Em Hot Topics in Operating Systems, 2001. Proceedings of the Eighth
Workshop on (may 2001), p. 75 – 80.
[16] Eugster, P. T., Felber, P. A., Guerraoui, R., Kermarrec, A.-M. The
many faces of publish/subscribe. ACM Comput. Surv. 35, 2 (junho de 2003), p. 114–
131.
[17] Huang, Y., Garcia-Molina, H. Publish/subscribe in a mobile environment.
Wirel. Netw. 10, 6 (novembro de 2004), p. 643–652.
[18] Krishnamurthy, B., Wills, C., Zhang, Y. On the use and performance of
content distribution networks. Em Proceedings of the 1st ACM SIGCOMM Workshop
on Internet Measurement (New York, NY, USA, 2001), IMW ’01, ACM, p. 169–182.
[19] Levy, S., Jacobson, T. Telnet X.3 PAD option. RFC 1053, Internet Engineering
Task Force, abril de 1988.
[20] Liu, C., Albitz, P. DNS and BIND. Oreilly Series. O’Reilly Media, 2009.
[21] Mockapetris, P. Domain names - concepts and facilities. RFC 1034, Internet
Engineering Task Force, novembro de 1987.
[22] Mockapetris, P. Domain names - implementation and specification. RFC 1035,
Internet Engineering Task Force, novembro de 1987.
[23] Pappas, V., Massey, D., Zhang, L. Enhancing dns resilience against denial of
service attacks. Em Dependable Systems and Networks, 2007. DSN ’07. 37th Annual
IEEE/IFIP International Conference on (june 2007), p. 450 –459.
[24] Ramasubramanian, V., Sirer, E. G. The design and implementation of a next
generation name service for the internet. SIGCOMM Comput. Commun. Rev. 34, 4
(agosto de 2004), p. 331–342.
[25] Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321, Internet Engineering
Task Force, abril de 1992.
[26] Rowstron, A. I. T., Druschel, P. Pastry: Scalable, decentralized object lo-
cation, and routing for large-scale peer-to-peer systems. Em Proceedings of the
IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg
(London, UK, UK, 2001), Middleware ’01, Springer-Verlag, p. 329–350.
[27] Rowstron, A. I. T., Kermarrec, A.-M., Castro, M., Druschel, P. Scribe:
The design of a large-scale event notification infrastructure. Em Proceedings of the
Third International COST264 Workshop on Networked Group Communication (Lon-
don, UK, UK, 2001), NGC ’01, Springer-Verlag, p. 30–43.
[28] Shaikh, A., Tewari, R., Agrawal, M. On the effectiveness of dns-based server
selection. Em INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE
Computer and Communications Societies. Proceedings. IEEE (2001), vol. 3, p. 1801
–1810 vol.3.
[29] Tanenbaum, A. Redes de Computadores. Campus, 2003.

42. Referˆncias
e 3
[30] Vlajic, N., Andrade, M., Nguyen, U. The role of dns ttl values in potential
ddos attacks: What do the major banks know about it? Procedia Computer Science
10, 0 (2012), p. 466 – 473. ANT 2012 and MobiWIS 2012.