Embed Size (px)
Citation preview
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
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 Conclusao de Curso submetidoao Departamento de Engenharias e Compu-tacao da Universidade Federal do EspıritoSanto como requisito parcial para aprovacaona disciplina Projeto de Graduacao II.
Orientador:
Prof. Rodolfo da Silva Villaca, M.Sc.
SAO MATEUS/ES
2013
Utilizacao do paradigma Publish/Subscribe para a criacao de um cache
DNS proativo
Tiago Rigo Guasti
Trabalho de Conclusao de Curso submetido
ao Departamento de Engenharias e Compu-
tacao da Universidade Federal do Espırito
Santo como requisito parcial para aprovacao
na disciplina Projeto de Graduacao II.
Aprovada por:
Prof. Rodolfo da Silva Villaca, M.Sc. / UFES (Orientador)
Prof. Helcio Bezerra de Mello, D.Sc. / UFES
Prof. Renato Elias Nunes de Moraes, D.Sc. / UFES
Sao Mateus, 01 de Fevereiro de 2013.
”Nunca soube o que era medo; tenho o magico segredo de conquistar o impossıvel”
Dom Quixote.
Resumo
Varias solucoes na area de tecnologia da informacao estao sendo implantadas parasuprir necessidades de grandes portais da Internet, estas solucoes tem como ponto co-mum a dependencia da utilizacao de valores TTL (Time To Live) extremamente baixaem respostas DNS (Domain Name System). Isso vem causando uma queda de desempe-nho de servidores DNS devido a alta taxa de falhas causadas por registros expirados (porterem TTL baixo). Este trabalho tem como objetivo analisar a viabilidade da utilizacaodo paradigma de comunicacao publish/subscribe a fim de minimizar o impacto da utili-zacao de valores TTL baixos no desempenho de cache DNS. Para provar a viabilidadefoi implementada uma solucao baseada em uma rede P2P (Peer-to-peer) Pastry onde foipossıvel executar o servico publish/subscribe alem de um servidor DNS que faz uso dosservicos publish/subscribe para dar caracterıstica proativa ao seu cache. Os resultadosforam satisfatorios indicando que e possıvel utilizar esta proposta para implementacao deuma solucao capaz de melhorar o desempenho do servico DNS atraves do uso de cacheproativo.
Palavras-chave: Cache, DNS, Domain Name System, Internet, Pastry, Peer-to-Peer,Publish/Subscribe, Servico de Resolucao de Nomes.
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
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 Visao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Modificacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 DNSHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Interface de Publicacao (Publish) . . . . . . . . . . . . . . . . . . . . . . . 18
4 Funcionamento do Protótipo e Testes 20
5 Conclusão e trabalhos futuros 29
Referências 1
Lista de Figuras
1.1 Diagrama da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Exemplo de arvore DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Formulario de publicacao de um topico . . . . . . . . . . . . . . . . . . . . 19
3.5 Formulario de publicacao de um IP . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Interface da ferramenta DIG . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Janela indicando o IP atual . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Interface da IDE Eclipse rodando o prototipo . . . . . . . . . . . . . . . . 23
4.4 Tempo de duas consultas consecutivas . . . . . . . . . . . . . . . . . . . . 24
4.5 Console indicando consultas . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Formulario de publicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Formulario de publicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8 Console indicando o envio e recebimento de uma publicacao . . . . . . . . 25
4.9 DIG mostrando uma mudanca no IP . . . . . . . . . . . . . . . . . . . . . 26
4.10 Mudanca no IP mostrada pelo Console . . . . . . . . . . . . . . . . . . . . 26
4.11 Comparativo de desempenho entre servidores DNS . . . . . . . . . . . . . 28
Lista de Tabelas
4.1 Tabela com resultado dos testes . . . . . . . . . . . . . . . . . . . . . . . . 27
Capítulo 1
Introdução
A Internet como e conhecida hoje e, sem duvida, uma ferramenta indispensavel para a
disseminacao de conhecimento. Todo o contingente que faz parte da rede, tanto consome,
quanto gera conteudo. Essa forma intrınseca de funcionamento, combinada a possibili-
dade de permanencia indeterminada de toda informacao publicada, mudou os paradigmas
modernos de propagacao de conteudo, baseado apenas em um fluxo contınuo, unilateral
e praticamente irrecuperavel de informacao, como o radio e a televisao.
Por fazer esse papel tao importante, a Internet ganha destaque no cotidiano das
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 dependencia da sociedade das
novas formas de comunicacao baseadas na Internet.
Isso so e possıvel gracas as diversas solucoes que vem sendo criadas e implementadas
para garantir disponibilidade e integridade dos dados que circulam sobre a grande rede.
Muitas solucoes que estao sendo desenvolvidas para a Internet dependem da utilizacao do
protocolo DNS (Domain Name System) como chave para o seu sucesso [20].
Parte desse sucesso esta baseada na utilizacao de cache pelos servidores DNS [28].
Atraves do cache, o servidor pode responder a uma requisicao sem a necessidade de
fazer uma consulta externa (desde que o registro procurado esteja disponıvel e nao tenha
expirado) acelerando as requisicoes pois e possıvel gerar uma resposta de imediato, sem
depender de fatores externos.
Com o aumento do trafego da Internet e com a utilizacao em massa de sıtios dinamicos,
grandes portais de conteudo ficaram impossibilitados de rodar em apenas uma maquina,
ocasionando uma distribuicao do conteudo na rede, ao mesmo tempo em que ataques
de negacao de servico (DDoS ) vem se tornando um problema frequentemente enfrentado
pelas equipes de TI ao redor do mundo. Com o intuito de evitar estes problemas, foram
1 Introducao 2
propostas algumas solucoes que hoje estao sendo utilizadas. Dentre elas, destacam-se o
Round-Robin DNS [9], o uso de CDN (Content Delivery Networks), [18] alem de tecnicas
descritas em [30] [23], que tem como foco evitar ataques de negacao de servico.
No modelo atual, os servidores DNS utilizam o campo TTL (Time To Live) como
parametro para estipular por quanto tempo eles poderao manter uma entrada em seu
cache. Assim, e evidente pensar que a eficiencia do cache DNS dependa de valores altos
de TTL.
Todas essas tecnologias tem como ponto em comum estarem baseadas na utilizacao de
TTL baixo. O que por um lado vem resolvendo os problemas citados, acaba gerando uma
deficiencia no desempenho dos caches DNS [11], pois ha um aumento significativo nas
falhas de cache devido ao pouco tempo em que um registro pode permanecer armazenado
localmente.
Neste cenario, seria interessante a utilizacao de um cache DNS proativo capaz de se
anteceder a requisicao de um cliente (atualizando conteudos dinamicos) evitando assim
falhas no cache, acelerando a propagacao de alteracoes e por conseguinte, prevenindo a
perda de integridade dos registros DNS armazenados [24].
Sendo assim, este trabalho tem como proposta a utilizacao do paradigma de comuni-
cacao publish/subscribe para dar esta caracterıstica proativa ao servico DNS.
Em resumo, publish/subscribe e um sistema que oferece aos assinantes a capacidade de
manifestar o seu interesse em um evento ou um padrao de eventos, a fim de ser notificado de
qualquer conteudo gerado por uma fonte que publica algo correspondente ao seu interesse.
Em outros termos, os produtores publicam informacoes em um canal de software (um
gestor de eventos) e consumidores se inscrevem em informacoes que querem receber do
respectivo canal [16].
Na Figura 1.1 podemos observar que o gestor de eventos seria implementado pelos
proprios servidores DNS atraves da criacao de uma rede P2P (Peer-to-Peer). Os pro-
dutores seriam os hosts cujos nomes estariam disponıveis no cache dos servidores DNS
participantes da rede.
Desta forma, ao haver mudancas em algum nome dos hosts participantes da rede, eles
se encarregariam de disparar mensagens de publicacoes a rede P2P, que por sua vez faria
notificacoes aos servidores DNS inscritos. Assim, essa alteracao seria propagada de forma
proativa para os caches.
A fim de comprovar de forma qualitativa a viabilidade da proposta apresentada, foi
1 Introducao 3
Figura 1.1: Diagrama da Arquitetura Proposta
implementado um prototipo constituıdo de uma rede P2P capaz de gerir as funcionalidades
publish/subscribe, alem de um servidor DNS juntamente com uma interface onde e possıvel
efetuar publicacoes nesta rede.
Atraves do prototipo foram realizados testes com o intuito de demonstrar que e pos-
sıvel a reducao no tempo de resolucao de nomes, utilizando o conceito apresentado.
O restante deste trabalho esta organizado da seguinte forma: No capıtulo 2 e apre-
sentada uma visao geral sobre DNS e publish/subscribe. O capıtulo 3 faz uma abordagem
sobre a implementacao do prototipo desenvolvido. No capıtulo 4 sao apresentados os tes-
tes e resultados obtidos e, por fim, sao apresentadas as conclusoes e trabalhos futuros no
capıtulo 5.
Capítulo 2
Conceitos Básicos
Este capıtulo visa proporcionar o entendimento basico dos conceitos relacionados ao
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 nos (hosts e servidores) integrantes da rede possuıam um ar-
quivo local no qual era armazenada uma tabela que mapeava os nomes das maquinas
daquela rede em enderecos IP (Internet Protocol). Estes arquivos eram gerenciados cen-
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 solucao logo se tornou inviavel devido a sua natureza nao escalavel. Por isso,
foi criado um sistema hierarquico e escalavel capaz de funcionar de forma distribuıda,
tornando-se o protocolo DNS.
O Domain Name System (DNS) [21] e um sistema para atribuicao e distribuicao de
nomes para computadores e servicos de redes baseado na pilha TCP/IP. Enderecos IP sao
usados pela camada de rede para determinar, sem ambiguidades, a localizacao de algum
dispositivo dentro de uma mesma rede. A nomeacao oferecida pelo DNS e usada para
localizacao de computadores e servicos atraves da utilizacao de nomes mnemonicos. Por
exemplo, para o usuario e muito mais facil gravar o nome www.ufes.br do que o endereco
IP 172.20.3.121.
Segundo Tanenbaum [29]“a essencia do DNS e a criacao de um esquema hierarquico de
atribuicao de nomes baseados no domınio de um sistema de banco de dados distribuıdo
2.1 O Protocolo DNS 5
para implementar esse esquema de nomenclatura”. A estrutura hierarquica do DNS e
ilustrada na Figura 2.1.
Figura 2.1: Exemplo de arvore DNS
Servidores de nomes sao programas que mantem as informacoes sobre determinada
parte da arvore DNS, chamada de zona. Um servidor de nomes corresponde a um no na
arvore e responde com autoridade para os enderecos daquela zona. Caso haja um subdo-
mınio, ele podera delegar para outro servidor de nomes os enderecos de tal subdomınio,
com o intuito de descentralizar a administracao dessas informacoes. A tarefa basica de
um servidor de nomes e responder as requisicoes usando dados da sua zona.
O processo de obter informacao do espaco de nomes de domınio e chamado de resolucao
de nomes e o elemento DNS que desempenha tal tarefa e chamado de Resolvedor.
Supondo no cenario ilustrado na Figura 2.2, que um resolvedor localizado em ber-
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 nao saiba nada so-
bre ele. O processo de resolucao de nomes se dara nas seguintes etapas: o resolvedor
podera consultar alguns servidores que ele ja tenha conhecimento anterior, mas supondo
que nenhum deles tenha informacoes referentes ao destino procurado, ele encaminhara o
pedido ao servidor edu (seta 1), por sua vez, o servidor edu conhece os seus enderecos
filhos, e dentre eles, esta o servidor colorado.edu (seta 2), que por sua vez conhece o
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) ate chegar ao resolvedor. Esse metodo de resolucao de
nomes e denominado consulta recursiva.
2.2 Publish/Subscribe 6
Figura 2.2: Consulta sem cache
Neste momento, o servidor local podera guardar esse registro em cache, mas sempre
respeitando campo TTL incluıdo no registro de resposta. Se algum outro pedido de
resolucao de nomes referente ao host cs.colorado.edu for efetuado no mesmo servidor
local, este podera, respeitando o campo TTL, responder a solicitacao com o seu registro
armazenado em cache e nao precisara fazer todo o caminho descrito no paragrafo acima,
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 resolucao de
nome, pois evita a necessidade de consultas externas. E necessario tambem ter em mente
que isso so e possıvel se tivermos um valor de TTL alto, entre 1 e 24 horas [11].
2.2 Publish/Subscribe
Segundo [16], publish/subscribe e um paradigma de comunicacao que busca prover
desacoplamento e flexibilidade necessarios para aplicacoes distribuıdas de larga escala. O
paradigma se baseia em duas entidades principais: produtores e consumidores. Produ-
tores (publishers) sao aqueles que publicam os dados no sistema, enquanto consumidores
(subscribers) definem um formato de assinatura, a fim de expressar quais dos dados sendo
publicados sao de seu interesse.
O ato de registrar interesse em um conteudo e definido como inscricao, entao consumi-
2.2 Publish/Subscribe 7
Figura 2.3: Consulta com cache
dores podem fazer inscricoes em varios conteudos, definidos como topicos. A partir deste
momento, o consumidor esta apto a receber mensagens referentes ao topico de interesse.
O modelo de sistema basico de interacao publish/subscribe conta com um servico de
eventos para armazenamento e gestao de assinaturas e entrega eficiente de mensagens,
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 nao precisam conhecer os consumidores das mensagens, assim como consumidores
nao necessitam conhecer os publicadores, removendo o acoplamento entre as entidades. De
acordo com [16], o esquema de interacao publish/subscribe, prove a forma de comunicacao
fracamente acoplada, necessaria a ambientes de larga escala, como a Internet.
A arquitetura do Broker pode ser implementada em duas possıveis arquiteturas [13]. A
primeira e centralizada com um unico servico de notificacao, responsavel por manter todos
os registros de interesse, alem de disseminar todas as publicacoes geradas. A segunda e
distribuıda, onde varios servidores estao interconectados e a carga de servico e distribuıda
entre eles.
Apesar de a arquitetura centralizada ter uma complexidade de implementacao rela-
tivamente baixa, seu grande problema e relacionado ao desempenho. Assim, a arquite-
tura distribuıda e a escolha mais adequada para aplicacoes que requerem processamento
2.2 Publish/Subscribe 8
de grandes quantidades de dados, alem de ser uma arquitetura escalavel [17], ou seja,
quando ha necessidade de se melhorar o desempenho do sistema, devido a inclusao de
novos participantes, e possıvel a inclusao de mais um servidor facilmente.
Uma das implementacoes de um broker distribuıdo e a Scribe [6], que disponibiliza
a API (Application programming interface) proposta por Darek et al. [14], especificando
servicos de roteamento de mensagens, notificacao de eventos, busca e armazenamento
distribuıdo, baseada na rede P2P Pastry [26].
Temos entao tres entidades, Broker, produtor e consumidor. Os consumidores re-
gistram interesse em topicos, o produtor faz publicacoes em um determinado topico e
o broker fica responsavel tanto por gerenciar as inscricoes dos consumidores, quanto de
despachar uma publicacao dos produtores para os seus respectivos consumidores.
Na Figura 2.4 temos um diagrama onde e possıvel observar as entidades envolvidas e
suas respectivas mensagens. Ainda podemos ver um ciclo completo de funcionamento do
publish/subscribe.
Primeiramente, o consumidor se registra em um topico, Subscribe (mensagem 1);
posteriormente temos uma publicacao, Publish (mensagem 2); e finalmente o consumidor
recebe esta publicacao, Notify (mensagem 3).
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.
2.2 Publish/Subscribe 9
Figura 2.5: Diagrama da arquitetura proposta.
Capítulo 3
Implementação
Para demonstrar a viabilidade da solucao proposta neste documento, foi implementado
um prototipo, que sera apresentado ao longo deste capıtulo.
A ideia original discutida anteriormente e de que cada no da rede Pastry seja tambem
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 modulo externo que implementa
o servico DNS tenha acesso a um no especıfico da rede e possa trocar as mensagens de
inscricao e notificacao conforme a Figura 3.1. Dessa forma, os outros nos nao implementam
o servico DNS. Estas alteracoes nao invalidam os resultados obtidos nos testes, uma vez
que em ambos os cenarios apenas o no que recebe a requisicao executa servicos de resolucao
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 simplificacao, essa funcionalidade foi
implementada na forma de uma interface grafica onde e feita a alimentacao do nome do
host com seu respectivo endereco IP a fim de disparar uma mensagem de notificacao para
que pudesse ser observada a atualizacao proativa do cache DNS.
A troca de mensagens entre o cache DNS e os agentes que se encontram fora da linha
tracejada (que representa a implementacao efetuada no trabalho), que seriam os usuarios
e o servidor DNS externo, segue a especificacao padrao definida na RFC 1035 [22]. Com
isso, e possıvel que um usuario faca a utilizacao da implementacao realizada neste trabalho
como seu servidor DNS principal.
Podemos dividir a implementacao em tres modulos: Scribe, que e responsavel por
disponibilizar as funcionalidades de um Broker publish/subscribe; DNSHandler, que dis-
ponibiliza servicos DNS alem de interagir com o Broker, e uma Interface Grafica que e
3.1 Scribe 11
responsavel pelo papel de produtor.
Figura 3.1: Diagrama da arquitetura implementada
3.1 Scribe
3.1.1 Visão Geral
Scribe [10], e uma implementacao distribuıda do publish/subscribe rodando em cima
da rede P2P Pastry (implementada por FreePastry [4]). Ela foi escolhida por trazer
uma API bem documentada, de facil entendimento e que possuıa todas as caracterısticas
desejadas para o desenvolvimento deste trabalho Alem de ser escrita em Java [5], o que
facilitou a reutilizacao do servico DNSHandler utilizado neste trabalho e explicado na
secao 3.2.
O Pastry [15] visa construir uma rede P2P estruturada, descentralizada, auto orga-
nizavel e tolerante a falhas para aplicacoes P2P. Todos os nos da rede juntamente com a
informacao que ela armazena sao identificados em um espaco de enderecamento compar-
tilhado, constituıdo por um identificador de 128 bits.
Por possuir um espaco de enderecamento compartilhado, nao ha como distinguir uma
informacao e um no apenas pelo seu identificador. Por questoes didaticas, nodeId e chave
3.1 Scribe 12
serao usados ao se referir ao identificador de um no e conteudo, respectivamente.
O nodeId, alem de identificar um no, indica sua posicao em um espaco de identifica-
dores circulares. Uma chave e mapeada para um no cujo nodeId esta numericamente mais
proximo da identificacao da chave.
O nodeId e gerado atraves de uma funcao Hash aplicada ao IP de um no, a funcao
hash tem como objetivo transformar informacoes em chaves de tamanhos fixos, como se
fossem impressoes digitais daquelas informacoes [25].
Como exemplo, podemos citar a funcao hash MD5 (Message-Digest algorithm 5) [25]
que e um algoritmo de hash de 128 bits. Ao aplicar a funcao ao IP “172.31.24.44” temos
como resultado a chave " 6e26e8fa9c28c702092c87659ffcfcd4", seu objetivo e identificar o
no no espaco compartilhado citado anteriormente.
Para demonstrar o espaco compartilhado, podemos aplicar a mesma funcao hash no
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 organizacao da estrutura em formato de anel, cada no pertencente a rede Pastry
mantem, entre outras informacoes, o nodeId de seus nos adjacentes (ou nos vizinhos) e uma
tabela de roteamento que possui registros de outros nos da rede localizados mais distantes
no anel (a fim de diminuir o numero de saltos no encaminhamento das mensagens na
rede).
Quando um no com nodeId A recebe uma mensagem com chave D, ele verifica se A e
o nodeId mais proximo de D, baseado no nodeId de seus vizinhos (sucessor e antecessor).
Caso ele seja efetivamente o no mais proximo, sera o responsavel pela chave D. Caso
contrario, o no devera fazer o roteamento da mensagem no anel.
O processo de roteamento e executado com base na tabela de roteamento, com a qual
um no decide o que fazer com uma mensagem. O funcionamento da tabela e seu processo
de preenchimento fogem do escopo deste texto, e por isso, nao serao abordados. Seu
funcionamento pode ser encontrado na referencia [26].
A Figura 3.2, exemplifica um processo de roteamento, o no 65a1fc recebe uma mensa-
gem com a chave d46a1, ao verificar que ele nao e o responsavel por tal chave, a mensagem
e encaminhada ate o no d13da3, o mais proximo presente na sua tabela de roteamento.
Esse processo se repete ate a mensagem chegar ao no d467c4.
Utilizando o nodeId de seus vizinhos, o no d467c4 verifica que tanto as distancias
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), sao maiores do que a distancia entre seu proprio nodeId e a chave da mensagem
(o que pode ser notado pela distancia espacial mostrada na Figura), assim o no d467c4
identifica que e o responsavel pela chave procurada.
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 funcoes utilizadas pela
aplicacao SCRIBE [26] [27]:
(a) nodeId = pastryInit(Credentials, Application)
Faz com que um no participe de uma rede Pastry existente (ou comece uma
nova), e retorne o nodeId do no local. O argumento Credentials contem in-
formacoes necessarias para autenticar o no. O argumento Application e um
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)
3.1 Scribe 14
Procedimento para encaminhar a mensagem msg para o no com nodeId nume-
ricamente mais proximo da chave key, dentre todos os nos Pastry disponıveis.
(c) send(msg,IP-addr)
Procedimento para enviar a mensagem msg ao no com o endereco IP especifi-
cado. A mensagem e recebida atraves do metodo deliver().
(d) deliver(msg,key)
Chamado por Pastry quando uma mensagem e recebida e nodeId do no e
numericamente mais proximo da chave key, entre os vizinhos no anel. Isso
quer dizer que o no atual e o responsavel pela mensagem.
(e) forward(msg,key,nextId)
Chamado por Pastry pouco antes de uma mensagem ser enviada para o no
seguinte, o aplicativo pode alterar o conteudo da mensagem ou o valor do
proximo no (nextId). Definir o proximo no como NULL termina o roteamento
da mensagem no no local.
2. API Scribe
Segundo [27] Scribe oferece a seguinte API para suas aplicacoes:
(a) create(credentials, topicId)
Cria um topico (topicId), e utiliza credentials para gerir controle de acesso.
(b) subscribe(credentials, topicId, eventHandler)
Inscreve o no local no topico definido por topicId, Todos os eventos recebidos
posteriormente para o assunto sao passados para o manipulador de eventos
especificado (eventHandler).
(c) unsubscribe(credentials, topicId)
Remove a inscricao do no atual do topico especificado em topicId.
(d) publish(credentials, topicId, event)
Faz com que o evento event seja publicado no topico topicId.
3.1.2 Modi�cações
A implementacao foi baseada no codigo de exemplo disponıvel em [7]. Esta imple-
mentacao traz tres classes que serao explicadas a seguir, junto as modificacoes efetuadas
para adequacao no trabalho.
3.1 Scribe 15
1. Classe MyScribeContent
Esta classe define o tipo de conteudo a ser enviado dentro de uma mensagem gerada
por um Produtor (host). Inicialmente, ela possuıa a identificacao do remetente e um
numero inteiro, esses dados eram irrelevantes na solucao proposta, entao a classe foi
modificada para que pudesse carregar uma string que contem o nome do produtor
junto ao IP do mesmo. Essas informacoes sao necessarias para que o consumidor
(neste caso o servidor DNS implementado no trabalho) possa atualizar os registros
contidos em seu cache.
2. Classe MyScribeClient
Define o comportamento (metodos) dos servicos publish/subscribe, os que interes-
sam no contexto deste trabalho sao:
(a) subscribe(String topico)
Este metodo trata o pedido de inscricao em um topico passado como parame-
tro, inicialmente ele nao recebia nenhum parametro, pois o nome do topico era
fixo. Ao executar esse metodo, e utilizada uma funcao hash interna do Fre-
ePastry para a criacao de um nodeId, e posteriormente e chamado o metodo
subscribe herdado da classe BaseScribe que processa o pedido de inscricao.
(b) sendMulticast(String topico, InetAddress ip)
E a interface de publicacao, inicialmente ele apenas publicava um numero se-
quencial em um topico fixo. Ele foi modificado para receber como parametro o
nome de um host e o seu respectivo IP. Tais dados sao encapsulados pela classe
MyScribeContent e despachados pelo metodo publish() herdado da classe Ja-
vaScribe que processa o envio a todos os inscritos no respectivo topico.
(c) deliver(Topic topic, ScribeContent content)
E executado toda vez que o no recebe uma publicacao destinada a ele pro-
prio, a partir daı, a publicacao torna-se uma notificacao. Inicialmente, apenas
mostra uma mensagem dizendo que o no recebeu uma publicacao junto ao seu
conteudo. Na implementacao da solucao proposta, e responsavel por disparar
a atualizacao do cache do servidor DNS proativo, chamando um metodo da
classe que implementa o cache DNS.
3. Classe ScribeTutorial
Tem como objetivo iniciar o ambiente FreePastry, possui o metodo main que da
inıcio a execucao do programa.
3.2 DNSHandler 16
Foi modificada para tambem dar inicio ao servico DNS a interface que da acesso
para o usuario ao processo de publicacoes na rede.
Como o intuito deste trabalho e demonstrar a viabilidade da solucao, esta classe
instancia varios nos da rede Pastry na mesma maquina. Para isso, cada no e ins-
tanciado com uma porta TCP diferente, assim todos os nos ficam disponıveis para
trocarem informacoes entre si. Nesta etapa, e possıvel definir quantos nos serao
instanciados.
No momento da criacao dos nos, dois deles sao escolhidos para serem os nos de
entrada para o cache DNS (consumidor) e para a interface de publicacao (produtor).
Por simplificacao, foram escolhidos sempre o primeiro no instanciado e o no N/2,
onde N representa o numero total de nos a serem instanciados.
Apos a inicializacao da rede Pastry, a classe faz a inicializacao em forma de threads,
dos servicos de DNS e de interface de publicacoes. Neste momento, a solucao esta
pronta para uso.
3.2 DNSHandler
O servidor DNS implementado foi baseado no codigo utilizado no trabalho de conclu-
sao de curso do aluno Matheus Vieira Costa [12], seu funcionamento e ilustrado na Figura
3.3, onde podemos ver um fluxograma de funcionamento do DNS.
A primeira tarefa realizada pelo DNSHandler consiste em esperar alguma requisicao
feita na porta 53 [19], utilizada como padrao para consultas DNS atraves do protocolo
UDP durante a comunicacao. Esta funcionalidade e implementada pela classe DNSHan-
dlerServer.
Ao receber uma requisicao, o objeto DNSHandlerServer dispara uma thread, defi-
nida pela classe DNSHandlerResponse. A partir deste momento, o aplicativo extrai as
informacoes contidas na requisicao. Inicialmente a unica informacao necessaria e o campo
nome, porem o formato do nome nao era adequado para uso, o que exigiu um tratamento
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 mudancas de nıveis na arvore hierarquica do DNS, substituıdos por numeros
que representam a quantidade de caracteres representados pelo determinado nıvel [12].
Possuindo o nome a ser consultado, e feita uma pesquisa do registo em cache, o cache
3.2 DNSHandler 17
Figura 3.3: Fluxograma do DNSHandler
3.3 Interface de Publicacao (Publish) 18
e implementado pela classe DNSCache, esta classe apenas faz o encapsulamento de uma
Hashtable que contem como ındice uma string que representa um nome de domınio e
seu conteudo e um IP.
Note que em uma implementacao real de cache, se faz necessario o armazenamento
de mais dados como TTL e informacoes para que seja possıvel verificar se o registro
armazenado expirou, dentre outras informacoes. Como nao e objetivo da implementacao
a criacao de uma aplicacao para uso fora de um ambiente controlado, isso foi omitido na
solucao.
Se a resposta do cache for positiva (isso quer dizer que o retorno e um IP), o programa
envia uma resposta a requisicao. Caso contrario, o cache respondera com NULL, indicando
que nao possui o registro solicitado.
Caso a resposta do cache seja negativa (NULL), o programa fara o pedido de inscricao
no topico referente ao nome solicitado a rede Pastry. Neste momento, o cache estara apto
a receber notificacoes advindas do referido nome.
Quando um nome nao esta em cache, o programa faz uma consulta a um servidor
de DNS externo. Ao receber a resposta, o programa extrai o IP da solicitacao inicial
e o insere, junto com o seu nome, no cache. Como dito anteriormente, o campo TTL
(Time To Live) e ignorado nesta etapa, pois a solucao parte do pressuposto que todas
as atualizacoes posteriores a este momento serao fornecidas pela rede Pastry. Por isso,
assume-se que um registro que esteja contido em cache sempre seja o mais atual disponıvel.
Apos este passo, podemos montar o pacote DNS de resposta (response) seguindo as
definicoes da RFC 1035 [22], preenchendo o campo referente ao IP do domınio solicitado,
depois esse pacote e enviado ao cliente atraves do seu IP que foi armazenado no inıcio do
processo.
3.3 Interface de Publicação (Publish)
Esta parte da implementacao simula o papel dos hosts que possuem seus nomes in-
cluıdos na rede Pastry, para isso o usuario precisa preencher dois campos, o Topico, que
representa o nome do host, e o seu endereco IP.
Feito isso, o programa dispara uma publicacao (publish), atraves de um metodo pu-
blico disponıvel por um no em especıfico da rede Pastry (este no e escolhido, descrita no
item 3.2.1) que sera entregue ao servico DNS atraves de uma mensagem de notificacao.
3.3 Interface de Publicacao (Publish) 19
Figura 3.4: Formulario de publicacao de um topico
Figura 3.5: Formulario de publicacao de um IP
Capítulo 4
Funcionamento do Protótipo e Testes
Com o objetivo de averiguar a viabilidade da solucao proposta, foram executados
alguns testes usando a implementacao descrita no capitulo 3 deste documento.
Como o escopo do documento nao contemplava um ambiente real, todos os testes
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 cenarios:
1. Direto (Consulta direta a um servidor externo).
Foram feitas consultas diretamente ao servidor externo, sem a utilizacao da imple-
mentacao. Tem por objetivo o levantamento de valores de referencia.
2. Sem Cache.
E utilizada a implementacao proposta, mas o cache da aplicacao encontra-se vazio,
por isso e necessario consultar um servidor externo para que seja possıvel responder
a requisicao.
3. Com Cache.
O domınio consultado esta em cache e por isso nao ha obrigatoriedade em se con-
sultar um servidor externo.
4. Cache Pastry (Consulta com cache atualizado pela rede Pastry).
O domınio consultado esta em cache e foi atualizado pela rede Pastry. E o ponto
chave da solucao proposta. Temos que ter em mente, neste momento, que o resultado
esperado deste cenario sera equivalente ao cenario 3 (consulta Com Cache), isso se
da ao fato de a resposta neste cenario nao possuir diferenca alguma de uma simples
resposta contida em cache.
4 Funcionamento do Prototipo e Testes 21
Ao contrario de uma solucao convencional, o cache desta implementacao, por de-
finicao, nao sofre com falhas de cache (cache miss) causados por TTL . Isso so e
possıvel gracas a rede Pastry, que fica encarregada de manter o cache sempre atu-
alizado, pois ao ocorrerem modificacoes nos domınios armazenados, e esperado que
seja feita a sua atualizacao atraves de uma publicacao.
Em uma solucao convencional, mesmo contendo um registro em cache, se esse re-
gistro estiver expirado (seu tempo de permanencia no cache for maior do que seu
TTL), sera necessaria uma consulta a outros servidores DNS, com isso espera-se um
tempo de resposta parecido com uma consulta sem cache.
Os testes foram executados com o auxılio da ferramenta DIG (Domain Information
Groper). Com ela podemos levantar o tempo que uma consulta DNS demora para ser
respondida, o IP de resposta, dentre outras informacoes nao relevantes para este trabalho.
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ınio ufes.br utilizando o servidor DNS 8.8.8.8.
Nesta ferramenta dois dados serao importantes, o Query time, que indica o tempo
de resolucao do nome e o IP associado ao domınio. Neste caso, temos dois enderecos IP
associados.
Na Figura 4.2, podemos observar o IP 172.31.24.44 associado a maquina onde foram
realizados os testes, esse IP sera utilizado posteriormente nos testes.
Na Figura 4.3, podemos observar a interface do programa em execucao, que foi im-
4 Funcionamento do Prototipo e Testes 22
Figura 4.2: Janela indicando o IP atual
plementado e testado utilizando a IDE (Integrated Development Environment) Eclipse na
sua versao Juno [3].
Podemos observar no Console algumas saıdas geradas pelo Freepastry, elas indicam
que os nos pastry foram iniciados com sucesso, juntamente com uma parte do nodeId.
Nas duas ultimas linhas, podemos observar as frases: Servidor dns Rodando, in-
dicando que ocorreu tudo bem na inicializacao do servidor DNS e Cliente Rodando,
indicando que a Interface de Publicacao (Publish) tambem foi inicializada sem erros.
A partir desse momento, a ferramenta esta apta a receber solicitacoes de resolucao de
nomes.
Para demonstrar todas as funcionalidades do prototipo, foram executadas as seguintes
tarefas, respectivamente:
• Atraves da ferramenta Dig foram feitas duas consultas consecutivas ao prototipo
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ıda do console, ilustrado
na Figura 4.5
4 Funcionamento do Prototipo e Testes 23
Figura 4.3: Interface da IDE Eclipse rodando o prototipo
4 Funcionamento do Prototipo e Testes 24
Figura 4.4: Tempo de duas consultas consecutivas
Figura 4.5: Console indicando consultas
4 Funcionamento do Prototipo e Testes 25
• Foi executada uma publicacao no domı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: Formulario de publicacao
Figura 4.7: Formulario de publicacao
Na Figura 4.8, temos a saıda do Console indicando que o no 5 (esse numero indica
apenas a ordem que o no foi criado e nao representa seu NodeId) recebeu um pu-
blish e fez o encaminhamento para a rede Pastry, com isso a rede pastry fez uma
notificacao ao no 0, que e o responsavel por atualizar o cache, em seguida temos a
mensagem que o no esta sendo atualizado.
Figura 4.8: Console indicando o envio e recebimento de uma publicacao
• Foi executada novamente uma consulta ao prototipo a fim de averiguar se realmente
foi atualizado o registro do domınio ufes.br
Na Figura 4.9, podemos observar que o endereco IP foi atualizado para o que era
esperado.
Na Figura 4.10, podemos observar a saıda do Console indicando que o registro
estava em cache, e que seu IP e 2.2.2.2. Note que esta saıda nao difere em nada da
4 Funcionamento do Prototipo e Testes 26
Figura 4.9: DIG mostrando uma mudanca no IP
Figura 4.10: Mudanca no IP mostrada pelo Console
Figura 4.5, pois apesar da consulta ter sido feita em um registro modificado pela
rede Pastry, isso nao modifica em nada o processo de resolucao a partir de registros
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 cenario, citados no inıcio deste capıtulo: Direto, Sem Cache,
Com Cache e Cache Pastry.
A quantidade de 10 consultas foi definida com base na pequena variacao de tempo
encontrada ao longo dos testes, isso indica que os dados eram bastantes estaveis no mo-
mento da avaliacao e por isso um numero maior de repeticoes nao traria acrescimo de
informacoes relevantes.
A Tabela 4.1 mostra os resultados obtidos para cada caso testado com a sua referida
media e desvio padrao.
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 prototipo a requisicao.
4 Funcionamento do Prototipo e Testes 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 2google.com.br 26 30 3 3google.com 26 31 4 3youtube.com 26 32 3 4uol.com.br 29 40 2 2live.com 26 28 3 4globo.com 26 29 3 2
blogspot.com.br 29 33 2 3yahoo.com 26 31 3 3
mercadolivre.com.br 26 30 2 4Media 26,6 31,3 2,8 3
Desvio Padrao 1,26 3,40 0,63 0,82
Se compararmos os tempos de resposta dos cenarios Sem Cache e Com Cache, podemos
notar um grande salto de desempenho, isso deve-se principalmente a latencia da rede, pois
ao fazer uma consulta externa, temos que considerar a infraestrutura da rede, a distancia
fısica entre o cliente e o servidor DNS, dentre outros fatores. Essa latencia prejudica uma
resolucao sem cache.
Em contrapartida, na resolucao em cache, a latencia de rede verificada nos experimen-
tos praticamente nao existe, pois tanto o servidor DNS quanto o cliente estao rodando na
mesma maquina.
Em um ambiente real, mesmo a solucao proposta provavelmente teria um aumento
nos tempos de resposta, pois e de se esperar que neste cenario servidor e cliente estejam
em maquinas diferentes, e com isso tambem sofram com a latencia da rede.
Mas para provar que uma resolucao, mesmo em um ambiente real, na maioria das
vezes e mais rapida quando o registro encontra-se em cache, foi feito um teste com o
programa DNS Benchmark [2].
O DNS Benchmark e um aplicativo que permite efetuar testes de benchmark para
analisar e comparar o desempenho de varios servidores DNS.
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 requisicoes estavam em cache (Cached), se comparadas as resolucoes que
nao estavam em cache (Uncached).
4 Funcionamento do Prototipo e Testes 28
Figura 4.11: Comparativo de desempenho entre servidores DNS
Se compararmos os cenarios Com Cache e Cache Pastry, poderemos notar resultados
parecidos, como era esperado, haja vista que nao existe diferenca alguma no processo de
resolucao nesses dois cenarios.
Isso pode parecer estranho no primeiro momento, mas temos que ter em mente o que
foi dito da descricao do cenario Cache Pastry. O ganho da solucao acontece no instante
que um registro em cache expira; nesse momento a solucao proposta continua respondendo
com o tempo descrito no cenario Cache Pastry devido ao cache ser proativo, enquanto
uma solucao tradicional demoraria o tempo do cenario Sem Cache, pois se o registro
encontra-se espirado e como se ele nao estivesse em cache.
Capítulo 5
Conclusão e trabalhos futuros
As ferramentas que possibilitam o funcionamento da Internet nem sempre sao as me-
lhores solucoes conhecidas, isso pode ocorrer por varios motivos. Muitos servicos utilizados
por nos foram pensados em um ambiente totalmente diferente, dentro de universidades
ou de uso militar e hoje se encontram em uma rede mundial, que esta presente em todos
os continentes e com milhoes de usuarios.
Essa mudanca de contexto muitas vezes sobrecarrega esses servicos e sua migracao
para outras tecnologias nem sempre e tao simples. Podemos citar como exemplo a mi-
gracao do IPv4 para o IPv6, o primeiro rascunho do IPv6 esta descrito na RFC 1752 [8]
em 1994, e suas especificacoes foram oficializadas pelo IETF (Internet Engineering Task
Force) apenas em 2012, e sua migracao por completa se quer tem previsao de termino.
Mas essa dificuldade de adocao de novas tecnologias nao pode desencorajar os pes-
quisadores, pois varias dessas mudancas sao simplesmente inevitaveis para que a Internet
continue funcionando.
Temos hoje uma mudanca significativa no que diz respeito a utilizacao de valores de
TTL em cache DNS, que sao cada vez menores. Isso degrada o desempenho de servidores
DNS e comeca a tornar-se um problema. Na literatura temos varias implementacoes que
tentam resolver esse problema.
Muitas dessas implementacoes tiveram como preocupacao o esforco de migracao para
tal solucao, por isso podem nao ser a solucao mais eficaz no que diz respeito a desempenho.
Este trabalho nao julgou o criterio esforco de migracao em nenhum momento, por isso
a solucao partiu de alguns pressupostos que podem afasta-la de uma solucao real, mas o
objetivo era experimentar algo ainda nao estudado como base de inspiracao para novas
propostas.
5 Conclusao e trabalhos futuros 30
Por esse motivo, nao foram feitos testes de desempenho da ferramenta em ambientes
de alta carga de trabalho, e sim testes qualitativos para demonstrar a viabilidade da
solucao.
Porem, atraves dos resultados obtidos fica comprovada a hipotese de que e possıvel
implementar um cache DNS proativo de forma transparente ao usuario (ou seja, nao e
necessario efetuar modificacoes nos programas clientes) a fim de melhorar o desempenho
da resolucao de nomes atraves da solucao proposta.
Como o escopo do projeto contempla testes controlados fora de um ambiente real, seu
prototipo teve muitas implementacoes simplificadas, por isso existem varias sugestoes de
trabalhos futuros como:
• Melhoria do DNSHandler a fim de responder corretamente a erros de resolucao, alem
de responder a qualquer tipo de registros DNS.
• Criar um protocolo de comunicacao baseado em IP para comunicacao de uma apli-
cacao externa a interface de publicacao implementada.
• Incorporar o servico DNSHandler a todos os nos da rede Pastry para possibilitar a
simulacao em um ambiente distribuıdo.
• Melhorar a implementacao do cache DNS para que possa verificar a expiracao de
um registro, caso nao seja atualizado por uma publicacao antes de expirar.
• Aplicar e testar a ideia de cache proativo em redes CDN (Content Delivery Networks).
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 GenerationProtocol. RFC 1752, Internet Engineering Task Force, janeiro de 1995.
[9] Brisco, T. DNS Support for Load Balancing. RFC 1794, Internet Engineering TaskForce, abril de 1995.
[10] Castro, M., Druschel, P., Kermarrec, A. M., Rowstron, A. I. Scribe: alarge-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 InternationalConference on (2006), p. 40.
[12] Costa, M. V. Avaliacao de servicos para computacao em nuvem para implantacaode um servico de resolucao de nomes. Trabalho de conclusao de curso, UniversidadeFederal do Espırito Santo, Sao Mateus, 2012.
[13] Cugola, G., Jacobsen, H.-A. Using publish/subscribe middleware for mobilesystems. SIGMOBILE Mob. Comput. Commun. Rev. 6, 4 (outubro de 2002), p. 25–33.
[14] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., Stoica, I. Towardsa common api for structured peer-to-peer overlays. Em Proceedings of the 2nd In-ternational Workshop on Peer-to-Peer Systems (IPTPS03) (Berkeley, CA, February2003).
Referencias 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 EighthWorkshop on (may 2001), p. 75 – 80.
[16] Eugster, P. T., Felber, P. A., Guerraoui, R., Kermarrec, A.-M. Themany 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 ofcontent distribution networks. Em Proceedings of the 1st ACM SIGCOMM Workshopon 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 EngineeringTask 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, InternetEngineering 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 ofservice attacks. Em Dependable Systems and Networks, 2007. DSN ’07. 37th AnnualIEEE/IFIP International Conference on (june 2007), p. 450 –459.
[24] Ramasubramanian, V., Sirer, E. G. The design and implementation of a nextgeneration 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 EngineeringTask 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 theIFIP/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 theThird 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 serverselection. Em INFOCOM 2001. Twentieth Annual Joint Conference of the IEEEComputer and Communications Societies. Proceedings. IEEE (2001), vol. 3, p. 1801–1810 vol.3.
[29] Tanenbaum, A. Redes de Computadores. Campus, 2003.
Referencias 3
[30] Vlajic, N., Andrade, M., Nguyen, U. The role of dns ttl values in potentialddos attacks: What do the major banks know about it? Procedia Computer Science10, 0 (2012), p. 466 – 473. ANT 2012 and MobiWIS 2012.
