Universidade Federal do Esp´                           ırito Santo              TIAGO RIGO GUASTIUtilização do paradigma P...
Universidade Federal do Esp´                           ırito Santo               TIAGO RIGO GUASTIUtilização do paradigma ...
Utiliza¸ao do paradigma Publish/Subscribe para a cria¸ao de um cache        c˜                                            ...
”Nunca soube o que era medo; tenho o m´gico segredo de conquistar o imposs´                                      a        ...
Resumo     V´rias solu¸oes na ´rea de tecnologia da informa¸ao est˜o sendo implantadas para       a         c˜      a     ...
AbreviaçõesAPI       : Application programming interfaceCDN       : Content Delivery NetworkDDoS      : Distributed Denial...
SumárioLista de Figuras                                                                             viLista de Tabelas    ...
Lista de Figuras1.1   Diagrama da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . .       32.1   Exemplo de...
Lista de Tabelas4.1   Tabela com resultado dos testes . . . . . . . . . . . . . . . . . . . . . . . . 27
Capítulo 1Introdução   A Internet como ´ conhecida hoje ´, sem d´vida, uma ferramenta indispens´vel para a                ...
1 Introdu¸˜o         ca                                                                            2propostas algumas solu...
1 Introdu¸˜o         ca                                                                            3                     F...
Capítulo 2Conceitos Básicos   Este cap´           ıtulo visa proporcionar o entendimento b´sico dos conceitos relacionados...
2.1 O Protocolo DNS                                                                 5para implementar esse esquema de nome...
2.2 Publish/Subscribe                                                                  6                             Figur...
2.2 Publish/Subscribe                                                                  7                            Figura...
2.2 Publish/Subscribe                                                               8de grandes quantidades de dados, al´m...
2.2 Publish/Subscribe                                                   9                        Figura 2.5: Diagrama da a...
Capítulo 3Implementação   Para demonstrar a viabilidade da solu¸˜o proposta neste documento, foi implementado             ...
3.1 Scribe                                                                          11respons´vel pelo papel de produtor. ...
3.1 Scribe                                                                             12ser˜o usados ao se referir ao ide...
3.1 Scribe                                                                            13                           Figura ...
3.1 Scribe                                                                                     14             Procedimento...
3.1 Scribe                                                                                15  1. Classe MyScribeContent   ...
3.2 DNSHandler                                                                           16      Foi modificada para tamb´m...
3.2 DNSHandler                                          17                 Figura 3.3: Fluxograma do DNSHandler
3.3 Interface de Publica¸˜o (Publish)                        ca                                                           ...
3.3 Interface de Publica¸˜o (Publish)                        ca                                             19            ...
Capítulo 4Funcionamento do Protótipo e Testes   Com o objetivo de averiguar a viabilidade da solu¸ao proposta, foram execu...
4 Funcionamento do Prot´tipo e Testes                       o                                                             ...
4 Funcionamento do Prot´tipo e Testes                       o                                                             ...
4 Funcionamento do Prot´tipo e Testes                       o                                                  23         ...
4 Funcionamento do Prot´tipo e Testes                       o                                              24             ...
4 Funcionamento do Prot´tipo e Testes                       o                                                            2...
4 Funcionamento do Prot´tipo e Testes                       o                                                             ...
4 Funcionamento do Prot´tipo e Testes                       o                                                             ...
4 Funcionamento do Prot´tipo e Testes                       o                                                            2...
Capítulo 5Conclusão e trabalhos futuros    As ferramentas que possibilitam o funcionamento da Internet nem sempre s˜o as m...
5 Conclus˜o e trabalhos futuros         a                                                                            30   ...
Referências [1] Alexa top sites in brazil. http://www.alexa.com/topsites/countries/BR. aces-     sado: 15/01/2013. [2] Dom...
Referˆncias     e                                                                                2[15] Druschel, P., Rowst...
Referˆncias     e                                                                           3[30] Vlajic, N., Andrade, M.,...
Próximos SlideShares
Carregando em…5
×

Utilização do paradigma Publish/Subscribe para a criação de um cache DNS proativo

980 visualizações

Publicada em

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
980
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
11
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Utilização do paradigma Publish/Subscribe para a criação de um cache DNS proativo

  1. 1. Universidade Federal do Esp´ ırito Santo TIAGO RIGO GUASTIUtilização do paradigma Publish/Subscribe para a criação de um cache DNS proativo ˜ SAO MATEUS/ES 2013
  2. 2. Universidade Federal do Esp´ ırito Santo TIAGO RIGO GUASTIUtilizaçã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. 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. caAprovada 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. 4. ”Nunca soube o que era medo; tenho o m´gico segredo de conquistar o imposs´ a ıvel” Dom Quixote.
  5. 5. Resumo V´rias solu¸oes na ´rea de tecnologia da informa¸ao est˜o sendo implantadas para a c˜ a c˜ asuprir 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 aterem TTL baixo). Este trabalho tem como objetivo analisar a viabilidade da utiliza¸˜o cado 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 cafoi implementada uma solu¸˜o baseada em uma rede P2P (Peer-to-peer ) Pastry onde foi caposs´ executar o servi¸o publish/subscribe al´m de um servidor DNS que faz uso dos ıvel c eservi¸os publish/subscribe para dar caracter´ c ıstica proativa ao seu cache. Os resultadosforam 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 eproativo.Palavras-chave: Cache, DNS, Domain Name System, Internet, Pastry, Peer-to-Peer,Publish/Subscribe, Servi¸o de Resolu¸˜o de Nomes. c ca
  6. 6. AbreviaçõesAPI : Application programming interfaceCDN : Content Delivery NetworkDDoS : Distributed Denial of ServiceDIG : Domain Information GroperDNS : Domain Name SystemIDE : Integrated development environmentIETF : Internet Engineering Task ForceIP : Internet ProtocolMD5 : Message-Digest Algorithm 5P2P : Peer-To-PeerSRI-NIC : Stanford Research Institute - Network Information CenterTTL : Time To Live
  7. 7. SumárioLista de Figuras viLista de Tabelas vii1 Introdução 12 Conceitos Básicos 4 2.1 O Protocolo DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 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 ca4 Funcionamento do Protótipo e Testes 205 Conclusão e trabalhos futuros 29Referências 1
  8. 8. Lista de Figuras1.1 Diagrama da Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . 32.1 Exemplo de ´rvore DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 52.2 Consulta sem cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Consulta com cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Diagrama das entidades envolvidas . . . . . . . . . . . . . . . . . . . . . . 82.5 Diagrama da arquitetura proposta. . . . . . . . . . . . . . . . . . . . . . . 93.1 Diagrama da arquitetura implementada . . . . . . . . . . . . . . . . . . . . 113.2 Exemplo de anel Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Fluxograma do DNSHandler . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Formul´rio de publica¸ao de um t´pico . . . . . . . . . . . . . . . . . . . . 19 a c˜ o3.5 Formul´rio de publica¸ao de um IP . . . . . . . . . . . . . . . . . . . . . . 19 a c˜4.1 Interface da ferramenta DIG . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Janela indicando o IP atual . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Interface da IDE Eclipse rodando o prot´tipo . . . . . . . . . . . . . . . . 23 o4.4 Tempo de duas consultas consecutivas . . . . . . . . . . . . . . . . . . . . 244.5 Console indicando consultas . . . . . . . . . . . . . . . . . . . . . . . . . . 244.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 c4.10 Mudan¸a no IP mostrada pelo Console . . . . . . . . . . . . . . . . . . . . 26 c4.11 Comparativo de desempenho entre servidores DNS . . . . . . . . . . . . . 28
  9. 9. Lista de Tabelas4.1 Tabela com resultado dos testes . . . . . . . . . . . . . . . . . . . . . . . . 27
  10. 10. Capítulo 1Introdução A Internet como ´ conhecida hoje ´, sem d´vida, uma ferramenta indispens´vel para a e e u adissemina¸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- adade de permanˆncia indeterminada de toda informa¸˜o publicada, mudou os paradigmas e camodernos de propaga¸ao de conte´do, baseado apenas em um fluxo cont´ c˜ u ınuo, unilaterale 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 apessoas. A cada nova tecnologia, algo que antes era feito utilizando meios f´ ısicos, passa aser realizado pelo meio digital. Por isso, vem crescendo a dependˆncia da sociedade das enovas 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 epara 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 aexpirado) acelerando as requisi¸oes pois ´ poss´ gerar uma resposta de imediato, sem c˜ e ıveldepender 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, agrandes portais de conte´do ficaram impossibilitados de rodar em apenas uma m´quina, u aocasionando uma distribui¸˜o do conte´do na rede, ao mesmo tempo em que ataques ca ude nega¸ao de servi¸o (DDoS ) vˆm se tornando um problema frequentemente enfrentado c˜ c epelas equipes de TI ao redor do mundo. Com o intuito de evitar estes problemas, foram
  11. 11. 1 Introdu¸˜o ca 2propostas algumas solu¸oes que hoje est˜o sendo utilizadas. Dentre elas, destacam-se o c˜ aRound-Robin DNS [9], o uso de CDN (Content Delivery Networks), [18] al´m de t´cnicas e edescritas 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) comoparˆmetro para estipular por quanto tempo eles poder˜o manter uma entrada em seu a acache. Assim, ´ evidente pensar que a eficiˆncia do cache DNS dependa de valores altos e ede 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 umadeficiˆncia no desempenho dos caches DNS [11], pois h´ um aumento significativo nas e afalhas de cache devido ao pouco tempo em que um registro pode permanecer armazenadolocalmente. Neste cen´rio, seria interessante a utiliza¸˜o de um cache DNS proativo capaz de se a caanteceder ` requisi¸ao de um cliente (atualizando conte´dos dinˆmicos) evitando assim a c˜ u afalhas 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- caca¸˜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 emanifestar o seu interesse em um evento ou um padr˜o de eventos, a fim de ser notificado de aqualquer conte´do gerado por uma fonte que publica algo correspondente ao seu interesse. uEm outros termos, os produtores publicam informa¸˜es em um canal de software (um cogestor de eventos) e consumidores se inscrevem em informa¸˜es que querem receber do corespectivo canal [16]. Na Figura 1.1 podemos observar que o gestor de eventos seria implementado pelospr´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 DNSparticipantes da rede. Desta forma, ao haver mudan¸as em algum nome dos hosts participantes da rede, eles cse encarregariam de disparar mensagens de publica¸oes ` rede P2P, que por sua vez faria c˜ anotifica¸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. 12. 1 Introdu¸˜o ca 3 Figura 1.1: Diagrama da Arquitetura Propostaimplementado um prot´tipo constitu´ de uma rede P2P capaz de gerir as funcionalidades o ıdopublish/subscribe, al´m de um servidor DNS juntamente com uma interface onde ´ poss´ e e ıvelefetuar publica¸oes nesta rede. c˜ Atrav´s do prot´tipo foram realizados testes com o intuito de demonstrar que ´ pos- e o es´ 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- esentada uma vis˜o geral sobre DNS e publish/subscribe. O cap´ a ıtulo 3 faz uma abordagemsobre a implementa¸ao do prot´tipo desenvolvido. No cap´ c˜ o ıtulo 4 s˜o apresentados os tes- ates e resultados obtidos e, por fim, s˜o apresentadas as conclus˜es e trabalhos futuros no a ocap´ ıtulo 5.
  13. 13. Capítulo 2Conceitos Básicos Este cap´ ıtulo visa proporcionar o entendimento b´sico dos conceitos relacionados ao aDNS e publish/subscribe.2.1 O Protocolo DNS Com o grande crescimento da Internet, em 1987 Mokapetris [21] [22] criou o conceitode 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 adaquela rede em endere¸os IP (Internet Protocol ). Estes arquivos eram gerenciados cen- ctralmente pelo SRI-NIC (Stanford Research Institute - Network Information Center ) e,periodicamente, cada computador na rede deveria atualizar seus arquivos para mantertudo funcionando. Tal solu¸ao logo se tornou invi´vel devido ` sua natureza n˜o escal´vel. Por isso, c˜ a a a afoi 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 ausados pela camada de rede para determinar, sem ambiguidades, a localiza¸˜o de algum cadispositivo dentro de uma mesma rede. A nomea¸ao oferecida pelo DNS ´ usada para c˜ elocaliza¸ao de computadores e servi¸os atrav´s da utiliza¸˜o de nomes mnemˆnicos. Por c˜ c e ca oexemplo, para o usu´rio ´ muito mais f´cil gravar o nome www.ufes.br do que o endere¸o a e a cIP 172.20.3.121. Segundo Tanenbaum [29] “a essˆncia do DNS ´ a cria¸˜o de um esquema hier´rquico de e e ca aatribui¸ao de nomes baseados no dom´ c˜ ınio de um sistema de banco de dados distribu´ ıdo
  14. 14. 2.1 O Protocolo DNS 5para implementar esse esquema de nomenclatura”. A estrutura hier´rquica do DNS ´ a eilustrada 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 cm´ ı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 aum 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- akley.edu, queira acessar o host www.cs.colorado.edu, e que o servidor de nomes localnunca tenha recebido uma consulta referente ao respectivo dom´ ınio e n˜o saiba nada so- abre ele. O processo de resolu¸˜o de nomes se dar´ nas seguintes etapas: o resolvedor ca apoder´ consultar alguns servidores que ele j´ tenha conhecimento anterior, mas supondo a aque nenhum deles tenha informa¸˜es referentes ao destino procurado, ele encaminhar´ o co apedido ao servidor edu (seta 1), por sua vez, o servidor edu conhece os seus endere¸os cfilhos, e dentre eles, est´ o servidor colorado.edu (seta 2), que por sua vez conhece o aservidor 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 segueo caminho inverso (setas 4,5,6) at´ chegar ao resolvedor. Esse m´todo de resolu¸˜o de e e canomes ´ denominado consulta recursiva. e
  15. 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 arespeitando campo TTL inclu´ no registro de resposta. Se algum outro pedido de ıdoresolu¸˜o de nomes referente ao host cs.colorado.edu for efetuado no mesmo servidor calocal, 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 aassim 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 eque isso s´ ´ poss´ se tivermos um valor de TTL alto, entre 1 e 24 horas [11]. oe ıvel2.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. Oparadigma 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 sendopublicados 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. 16. 2.2 Publish/Subscribe 7 Figura 2.3: Consulta com cachedores podem fazer inscri¸oes em v´rios conte´dos, definidos como t´picos. A partir deste c˜ a u omomento, 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˜ ceventos para armazenamento e gest˜o de assinaturas e entrega eficiente de mensagens, adenominado 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 an˜o necessitam conhecer os publicadores, removendo o acoplamento entre as entidades. De aacordo 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]. Aprimeira ´ centralizada com um unico servi¸o de notifica¸˜o, respons´vel por manter todos e ´ c ca aos registros de interesse, al´m de disseminar todas as publica¸oes geradas. A segunda ´ e c˜ edistribu´ onde v´rios servidores est˜o interconectados e a carga de servi¸o ´ distribu´ ıda, a a c e ıdaentre 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- etura distribu´ ´ a escolha mais adequada para aplica¸˜es que requerem processamento ıda e co
  17. 17. 2.2 Publish/Subscribe 8de grandes quantidades de dados, al´m de ser uma arquitetura escal´vel [17], ou seja, e aquando h´ necessidade de se melhorar o desempenho do sistema, devido ` inclus˜o de a a anovos 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 ea API (Application programming interface) proposta por Darek et al. [14], especificandoservi¸os de roteamento de mensagens, notifica¸˜o de eventos, busca e armazenamento c cadistribu´ ıdo, baseada na rede P2P Pastry [26]. Temos ent˜o trˆs entidades, Broker, produtor e consumidor. Os consumidores re- a egistram interesse em t´picos, o produtor faz publica¸oes em um determinado t´pico e o c˜ oo broker fica respons´vel tanto por gerenciar as inscri¸˜es dos consumidores, quanto de a codespachar 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 ıvelsuas respectivas mensagens. Ainda podemos ver um ciclo completo de funcionamento dopublish/subscribe. Primeiramente, o consumidor se registra em um t´pico, Subscribe (mensagem 1); oposteriormente 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 servidoresDNS participantes da rede, enquanto o Consumidor (subscriber ) seria o servidor DNSproposto.
  18. 18. 2.2 Publish/Subscribe 9 Figura 2.5: Diagrama da arquitetura proposta.
  19. 19. Capítulo 3Implementação Para demonstrar a viabilidade da solu¸˜o proposta neste documento, foi implementado caum 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 eum servidor DNS funcional, o que pode ser notado na Figura 1.1. Para simplificar otrabalho, esta proposta foi modificada de forma que um m´dulo externo que implementa oo servi¸o DNS tenha acesso a um n´ espec´ c o ıfico da rede e possa trocar as mensagens deinscri¸ao e notifica¸ao conforme a Figura 3.1. Dessa forma, os outros n´s n˜o implementam c˜ c˜ o ao servi¸o DNS. Estas altera¸oes n˜o invalidam os resultados obtidos nos testes, uma vez c c˜ aque 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 disponibilizadospelos 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 caque 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 linhatracejada (que representa a implementa¸˜o efetuada no trabalho), que seriam os usu´rios ca ae o servidor DNS externo, segue a especifica¸˜o padr˜o definida na RFC 1035 [22]. Com ca aisso, ´ 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 adisponibilizar 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. 20. 3.1 Scribe 11respons´vel pelo papel de produtor. a Figura 3.1: Diagrama da arquitetura implementada3.1 Scribe3.1.1 Visão Geral Scribe [10], ´ uma implementa¸˜o distribu´ do publish/subscribe rodando em cima e ca ıdada rede P2P Pastry (implementada por FreePastry [4]). Ela foi escolhida por trazeruma API bem documentada, de f´cil entendimento e que possu´ todas as caracter´ a ıa ısticasdesejadas para o desenvolvimento deste trabalho Al´m de ser escrita em Java [5], o que efacilitou a reutiliza¸ao do servi¸o DNSHandler utilizado neste trabalho e explicado na c˜ cse¸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 oinforma¸ao que ela armazena s˜o identificados em um espa¸o de endere¸amento compar- c˜ a c ctilhado, 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 ainforma¸ao e um n´ apenas pelo seu identificador. Por quest˜es did´ticas, nodeId e chave c˜ o o a
  21. 21. 3.1 Scribe 12ser˜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 cdores circulares. Uma chave ´ mapeada para um n´ cujo nodeId est´ numericamente mais e o apr´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 cahash 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] caque ´ um algoritmo de hash de 128 bits. Ao aplicar a fun¸˜o ao IP “172.31.24.44” temos e cacomo resultado a chave " 6e26e8fa9c28c702092c87659ffcfcd4", seu objetivo ´ identificar o en´ 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 amant´m, entre outras informa¸˜es, o nodeId de seus n´s adjacentes (ou n´s vizinhos) e uma e co o otabela de roteamento que possui registros de outros n´s da rede localizados mais distantes ono anel (a fim de diminuir o n´mero de saltos no encaminhamento das mensagens na urede). Quando um n´ com nodeId A recebe uma mensagem com chave D, ele verifica se A ´ o eo nodeId mais pr´ximo de D, baseado no nodeId de seus vizinhos (sucessor e antecessor). oCaso ele seja efetivamente o n´ mais pr´ximo, ser´ o respons´vel pela chave D. Caso o o a acontr´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 eum n´ decide o que fazer com uma mensagem. O funcionamento da tabela e seu processo ode preenchimento fogem do escopo deste texto, e por isso, n˜o ser˜o abordados. Seu a afuncionamento pode ser encontrado na referˆncia [26]. e A Figura 3.2, exemplifica um processo de roteamento, o n´ 65a1fc recebe uma mensa- ogem 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 oEsse 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. 22. 3.1 Scribe 13 Figura 3.2: Exemplo de anel Pastryentre 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 oidentifica que ´ o respons´vel pela chave procurada. e a Como dito anteriormente, este documento fez uso da SCRIBE, capaz de gerir asfuncionalidades do publish/subscribe sobre a rede Pastry. Para tal foi utilizado a API dedesenvolvimento 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. 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. o3.1.2 Modicações A implementa¸˜o foi baseada no c´digo de exemplo dispon´ em [7]. Esta imple- ca o ıvelmenta¸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. 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. 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- os˜o de curso do aluno Matheus Vieira Costa [12], seu funcionamento ´ ilustrado na Figura a e3.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 eUDP durante a comunica¸ao. Esta funcionalidade ´ implementada pela classe DNSHan- c˜ edlerServer. Ao receber uma requisi¸˜o, o objeto DNSHandlerServer dispara uma thread, defi- canida pela classe DNSHandlerResponse. A partir deste momento, o aplicativo extrai asinforma¸oes contidas na requisi¸˜o. Inicialmente a unica informa¸ao necess´ria ´ o campo c˜ ca ´ c˜ a enome, por´m o formato do nome n˜o era adequado para uso, o que exigiu um tratamento e asobre 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, querepresentam mudan¸as de n´ c ıveis na ´rvore hier´rquica do DNS, substitu´ a a ıdos por n´meros uque 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. 26. 3.2 DNSHandler 17 Figura 3.3: Fluxograma do DNSHandler
  27. 27. 3.3 Interface de Publica¸˜o (Publish) ca 18´ implementado pela classe DNSCache, esta classe apenas faz o encapsulamento de umaeHashtable que cont´m como ´ e ındice uma string que representa um nome de dom´ ınio eseu conte´do ´ um IP. u e Note que em uma implementa¸˜o real de cache, se faz necess´rio o armazenamento ca ade mais dados como TTL e informa¸oes para que seja poss´ c˜ ıvel verificar se o registroarmazenado 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˜ casolu¸˜o. ca Se a resposta do cache for positiva (isso quer dizer que o retorno ´ um IP), o programa eenvia uma resposta ` requisi¸ao. Caso contr´rio, o cache responder´ com NULL, indicando a c˜ a aque n˜o possui o registro solicitado. a Caso a resposta do cache seja negativa (NULL), o programa far´ o pedido de inscri¸˜o a cano t´pico referente ao nome solicitado ` rede Pastry. Neste momento, o cache estar´ apto o a aa 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 ade DNS externo. Ao receber a resposta, o programa extrai o IP da solicita¸˜o inicial cae 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˜ aassume-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 odefini¸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 ıcioprocesso.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 orepresenta 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 ublico dispon´ por um n´ em espec´ ıvel o ıfico da rede Pastry (este n´ ´ escolhido, descrita no oeitem 3.2.1) que ser´ entregue ao servi¸o DNS atrav´s de uma mensagem de notifica¸ao. a c e c˜
  28. 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. 29. Capítulo 4Funcionamento 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 aforam executados dentro de um ambiente controlado, o que facilita o entendimento dosresultados 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. 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 ılioGroper ). Com ela podemos levantar o tempo que uma consulta DNS demora para serrespondida, 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 ”, issoquer 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 ade resolu¸˜o do nome e o IP associado ao dom´ ca ınio. Neste caso, temos dois endere¸os IP cassociados. Na Figura 4.2, podemos observar o IP 172.31.24.44 associado ` m´quina onde foram a arealizados 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. 31. 4 Funcionamento do Prot´tipo e Testes o 22 Figura 4.2: Janela indicando o IP atualplementado e testado utilizando a IDE (Integrated Development Environment) Eclipse nasua vers˜o Juno [3]. a Podemos observar no Console algumas sa´ ıdas geradas pelo Freepastry, elas indicamque 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˜ canomes. Para demonstrar todas as funcionalidades do prot´tipo, foram executadas as seguintes otarefas, 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. 32. 4 Funcionamento do Prot´tipo e Testes o 23 Figura 4.3: Interface da IDE Eclipse rodando o prot´tipo o
  33. 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. 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. 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, emJaneiro de 2013, por um estudo realizado pelo site Alexa [1] da Amazon. Cada nome foiconsultado 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- amento da avalia¸ao e por isso um n´mero maior de repeti¸oes n˜o traria acr´scimo de c˜ u c˜ a einforma¸oes relevantes. c˜ A Tabela 4.1 mostra os resultados obtidos para cada caso testado com a sua referidam´dia e desvio padr˜o. e a Sobre os resultados obtidos, podemos observar um leve aumento no tempo de respostase compararmos os casos Direto e Sem Cache. Isso se deve ao fato de haver um atrasodevido ao processamento interno do prot´tipo ` requisi¸ao. o a c˜
  36. 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 anotar um grande salto de desempenho, isso deve-se principalmente ` latˆncia da rede, pois a eao fazer uma consulta externa, temos que considerar a infraestrutura da rede, a distˆncia af´ ısica entre o cliente e o servidor DNS, dentre outros fatores. Essa latˆncia prejudica uma eresolu¸˜o sem cache. ca Em contrapartida, na resolu¸ao em cache, a latˆncia de rede verificada nos experimen- c˜ etos praticamente n˜o existe, pois tanto o servidor DNS quanto o cliente est˜o rodando na a amesma m´quina. a Em um ambiente real, mesmo a solu¸˜o proposta provavelmente teria um aumento canos tempos de resposta, pois ´ de se esperar que neste cen´rio servidor e cliente estejam e aem 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 cavezes ´ mais r´pida quando o registro encontra-se em cache, foi feito um teste com o e aprograma DNS Benchmark [2]. O DNS Benchmark ´ um aplicativo que permite efetuar testes de benchmark para eanalisar e comparar o desempenho de v´rios servidores DNS. a Na Figura 4.11, podemos notar que o servidor (exceto o local, mostrado em primeiroda lista), com melhor desempenho (destacado na Figura) teve um desempenho 3 vezesmaior 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. 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 aparecidos, como era esperado, haja vista que n˜o existe diferen¸a alguma no processo de a cresolu¸˜o nesses dois cen´rios. ca a Isso pode parecer estranho no primeiro momento, mas temos que ter em mente o quefoi dito da descri¸˜o do cen´rio Cache Pastry. O ganho da solu¸˜o acontece no instante ca a caque 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 auma solu¸ao tradicional demoraria o tempo do cen´rio Sem Cache, pois se o registro c˜ aencontra-se espirado ´ como se ele n˜o estivesse em cache. e a
  38. 38. Capítulo 5Conclusão e trabalhos futuros As ferramentas que possibilitam o funcionamento da Internet nem sempre s˜o as me- alhores solu¸˜es conhecidas, isso pode ocorrer por v´rios motivos. Muitos servi¸os utilizados co a cpor n´s foram pensados em um ambiente totalmente diferente, dentro de universidades oou de uso militar e hoje se encontram em uma rede mundial, que est´ presente em todos aos 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 agra¸˜o do IPv4 para o IPv6, o primeiro rascunho do IPv6 est´ descrito na RFC 1752 [8] ca aem 1994, e suas especifica¸˜es foram oficializadas pelo IETF (Internet Engineering Task coForce) 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 aquisadores, pois v´rias dessas mudan¸as s˜o simplesmente inevit´veis para que a Internet a c a acontinue funcionando. Temos hoje uma mudan¸a significativa no que diz respeito ` utiliza¸˜o de valores de c a caTTL em cache DNS, que s˜o cada vez menores. Isso degrada o desempenho de servidores aDNS e come¸a a tornar-se um problema. Na literatura temos v´rias implementa¸˜es que c a cotentam 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 caa solu¸ao partiu de alguns pressupostos que podem afast´-la de uma solu¸˜o real, mas o c˜ a caobjetivo era experimentar algo ainda n˜o estudado como base de inspira¸˜o para novas a capropostas.
  39. 39. 5 Conclus˜o e trabalhos futuros a 30 Por esse motivo, n˜o foram feitos testes de desempenho da ferramenta em ambientes ade alta carga de trabalho, e sim testes qualitativos para demonstrar a viabilidade dasolu¸˜o. ca Por´m, atrav´s dos resultados obtidos fica comprovada a hip´tese de que ´ poss´ e e o e ıvelimplementar um cache DNS proativo de forma transparente ao usu´rio (ou seja, n˜o ´ a a enecess´rio efetuar modifica¸˜es nos programas clientes) a fim de melhorar o desempenho a coda 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, seuprot´tipo teve muitas implementa¸oes simplificadas, por isso existem v´rias sugest˜es de o c˜ a otrabalhos 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. 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. 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. 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.

×