UNIVERSIDADE ESTADUAL DO CEARÁ
CENTRO DE CIÊNCIA E TECNOLOGIA
DEPARTAMENTO DE ESTATÍSTICA E COMPUTAÇÃO
CURSO CIÊNCIA DA COMPUTAÇÃO
U M E S T U D O D A S N O V A S T E C N O L O G I A S E M
R E D E S P2P E U M A P R O P O S T A P A R A U S O E M
T E L E F O N I A I P .
ALUNO: André Pontes Sampaio
ORIENTADOR: Joaquim Celestino Júnior
CO-ORIENTADOR: André Ribeiro Cardoso
Fortaleza, Ceará
Março de 2006.
2
ANDRÉ PONTES SAMPAIO
UM ESTUDO DAS NOVAS TECNOLOGIAS
EM REDES P2P E UMA PROPOSTA PARA
USO EM TELEFONIA I P .
Monografia apresentada como exigência para obtenção do título de Graduação em Ciência da Computação, à Comissão Julgadora da Universidade Estadual do Ceará, sob a orientação do Prof. Dr. Joaquim Celestino Júnior.
Fortaleza, Ceará
Março de 2006.
3
Catalogação Internacional na Publicação - CIP
S192 Sampaio, André Pontes Um estudo das novas tecnologias em redes P2P e uma proposta
para uso em telefonia IP / André Pontes Sampaio; __ Fortaleza; 2006. 92 p.: il. Orientador: Prof. Dr. Joaquim Celestino Júnior Monografia (Graduação em Ciência da Computação) -
Universidade Estadual do Ceara, Centro de Ciência e Tecnologia. 1. Redes Peer-to-Peer. 2. Telefonia IP (VoIP). 3. Sistemas
Distribuidos. Universidade Estadual do Ceará, Centro de Ciência e Tecnologia
CDD
004.09
Endereço: Universidade Estadual do Ceará – Itaperi Rua Paranjana, 1700 – Fortaleza - CE Cep: 60740-000
4
ANDRÉ PONTES SAMPAIO
UM ESTUDO DAS NOVAS TECNOLOGIAS
EM REDES P2P E UMA PROPOSTA PARA
USO EM TELEFONIA I P .
Data da Defesa: 03/03/2006
BANCA EXAMINADORA
Prof. Dr. Joaquim Celestino Júnior
Prof. Dr. Antônio de Barros Serra
Prof. Dr. Marcial Porto Fernandez
5
AGRADECIMENTOS
Gostaria de agradecer em primeiro lugar a Deus, pois com Ele
encontramos toda a força que precisamos para enfrentar os nossos
desafios. Aos meus pais Luiz Guilherme e Sandra por toda a paciência e
investimento que fizeram em mim e por compartilhar comigo todos os
sentimentos, momentos felizes, emoções, pensamentos, desejos,
necessidades, expectativas, sonhos e esperanças. A minha irmã Larissa
por todo seu amor e incentivo com palavras e mãos acolhedoras que me
ajudaram a enfrentar todos os problemas. Aos professores: Celestino,
André, Marcial e Serra por terem se dedicado nesta orientação com toda a
paciência, fazendo-se depositários das minhas ansiedades, dúvidas e
questionamentos. Aos amigos e familiares pelos momentos felizes
compartilhados.
6
“Feliz o ignorante que não conhece as complexidades de um simples problema”
Autor desconhecido
7
SUMÁRIO
Resumo.................................................................................... 09 Abstract ................................................................................... 10 Lista de Figuras......................................................................... 11 Lista de Tabelas ........................................................................ 12 1. Introdução............................................................................ 13
1.1. Introdução às redes peer-to-peer ..................................... 13 1.2. Objetivo e contribuição.................................................... 14 1.3. Trabalhos relacionados .................................................... 15 1.4. Estrutura deste trabalho .................................................. 15
2. Início da Tecnologia P2P ......................................................... 17 2.1. P2P x Arquiteturas existentes ........................................... 17
2.1.1. Redes P2P x Modelo Cliente-Servidor.......................... 17 2.1.2. Redes P2P x Redes Overlay ....................................... 18 2.1.3. Redes P2P x Grades (Grids)....................................... 19
2.2. Uma arquitetura abstrata de rede p2p............................... 20 3. Arquiteturas P2P clássicas....................................................... 22
3.1. Categoria de busca ......................................................... 22 3.2. Modelos clássicos............................................................ 23
3.2.1. Napster – busca centralizada..................................... 23 3.2.2. Gnutella – busca por inundação ................................. 25 3.2.3. Tabelas Hash Distribuídas - DHT ................................ 31
4. Redes P2P Estruturadas e Descentralizadas............................... 34 4.1. CAN: Content Addressable Network................................... 34 4.2. CHORD.......................................................................... 37 4.3. TAPESTRY...................................................................... 42
4.3.1. Aplicabilidade do Sistema Tapestry............................. 43 4.3.1.1. Sistema OceanStore...................................... 43 4.3.1.2. Sistema SpamWatch ..................................... 44
4.4. PASTRY ......................................................................... 46 4.4.1. Aplicabilidade do Sistema Pastry ................................ 48
4.4.1.1. Sistema Scribe ............................................. 48 4.4.1.2. Sistema Past ................................................ 48 4.4.1.3. Sistema Squirrel ........................................... 49 4.4.1.4. Sistema SplitStream...................................... 49 4.4.1.5. Sistema Post ................................................ 49 4.4.1.6. Sistema Scrivener ......................................... 49
5. Redes P2P Estruturadas e Descentralizadas............................... 51 5.1. FreeNet ......................................................................... 51 5.2. Gnutella 2...................................................................... 55
5.2.1. Comunicação hub-folha otimizada .............................. 58 5.2.2. Comunicação hub-hub otimizada................................ 59
5.3. Fast Track / Kazza .......................................................... 60 5.4. Bit Torrent ..................................................................... 65
8
5.5. Emule / Edonkey 2000/ Overnet ....................................... 68 6. Novas Tecnologias em Redes P2P ............................................ 72
6.1. Telefonia na internet versus compartilhamento de arquivos.. 73 6.2. Modelos de telefonia centralizados .................................... 74
6.2.1. SIP......................................................................... 74 6.2.2. H.323..................................................................... 77
6.3. Modelo de uma plataforma de Telefonia IP baseado em Redes P2P (Modelo Descentralizado) ....................................................... 80
6.3.1. Configuração Automática .......................................... 80 6.3.2. Peers Heterogêneos ................................................. 81 6.3.3. Busca Eficiente ........................................................ 82
7. Conclusão ............................................................................. 86
9
RESUMO
Neste trabalho é feito um estudo comparativo entre diversas arquiteturas
P2P existentes e outras que ainda estão em desenvolvimento.
Inicialmente, é feito um paralelo entre a estrutura P2P e seguintes
arquiteturas: Modelo Cliente-Servidor, Redes Overlay e Grades. Mostra-se
que os sistemas podem ser classificados em relação ao modelo de busca
utilizado. São apresentados os modelos que deram inicio ao estudo de
redes P2P (Napster e Gnutella). Serão também apresentadas as buscas
baseadas em DHT: Chord, Pastry, Tapestry e CAN. Para finalizar o
trabalho, um estudo sobre redes de voz sobre IP (Tecnologia VoIP) é
desenvolvido. Apresentam-se os protocolos IETF SIP e ITU-T H.323 e
estudaremos as características de um modelo de telefonia IP baseado em
redes P2P (modelo descentralizado).
10
ABSTRACT
In this work a comparative study between diverse existing P2P
architectures and others P2P architectures that are in development is
done. Initially, a comparison is made between P2P structures and the
following architectures: Client-Server Model, Overlay Networks and Grids.
This work shows that systems can be classified in relation to the model of
search that they use. After that, it shows the first models on the study of
P2P Networks (Napster and Gnutella). This work also shows DHT based
searches: Chord, Pastry, Tapestry and CAN. To finalize the work, a study
of Voice Over IP Networks (VoIP Technology) is developed. The protocols
IETF SIP and ITU-T H.323 are showed and we study the features that a
model for IP telephony based on P2P networks (decentralized model)
might have.
11
L I S T A D E I L U S T R A Ç Õ E S
Figura 1 - Topologia Cliente-Servidor e P2P ............................... 17 Figura 2 - Modelo de Arquitetura Três Camadas ......................... 18 Figura 3 - Rede de Cobertura (Overlay) ..................................... 19 Figura 4 - Modelo de Arquitetura P2P ......................................... 21 Figura 5 - Funcionamento do Sistema Napster ............................ 24 Figura 6 - Tamanho das mensagens Gnutella .............................. 26 Figura 7 - Funcionamento da Rede Gnutella ................................ 27 Figura 8 - Serventes da Rede Gnutella ....................................... 27 Figura 9 - Protocolo Gnutella (23 bytes) ..................................... 29 Figura 10 - Resposta as Mensagens Ping e Query ......................... 30 Figura 11 - Tipos de Mensagens na rede Gnutella ......................... 31 Figura 12 - Arquitetura DHT....................................................... 32 Figura 13 - Zona dos Dispositivos (CAN)...................................... 34 Figura 14 - Atribuição de Zonas de Maneira Dinâmica ................... 35 Figura 15 - Algoritmo CAN: guarda {chave, valor} ....................... 36 Figura 16 - Algoritmo CAN: recupera {chave, valor}..................... 36 Figura 17 - Exemplo de um Anel de Chord ................................... 38 Figura 18 - Localização de Chave Simples.................................... 40 Figura 19 - Localização de Chave Escapável ................................. 41 Figura 20 - Roteamento em uma rede Tapestry............................ 42 Figura 21 - Sistema SpamWatch (Outlook Toolbar)....................... 45 Figura 22 - Tabela de Roteamento .............................................. 46 Figura 23 - Conjunto de Vizinhança ............................................ 47 Figura 24 - Conjunto de Folhas................................................... 47 Figura 25 - Elementos de um peer Pastry .................................... 47 Figura 26 - Funcionamento da rede Freenet ................................. 53 Figura 27 - Interface do Cliente Freenet ...................................... 54 Figura 28 - Topologia Gnutella² .................................................. 57 Figura 29 - Comunicação Hub-Hub (Gnutella²) ............................. 60 Figura 30 - Componentes da Rede Kazaa..................................... 61 Figura 31 - Conexão com o NAT ou FIREWALL.............................. 62 Figura 32 - Estabelecimento da Conexão ..................................... 64 Figura 33 - Componentes do BitTorrent ....................................... 66 Figura 34 - Informações sobre o arquivo .torrent.......................... 67 Figura 35 - Transferência de Arquivos ......................................... 67 Figura 36 - Arquitetura SIP ........................................................ 76 Figura 37 - Arquitetura H.323 .................................................... 78 Figura 38 - Modelo Descentralizado baseado no Anel de Chord....... 81 Figura 39 - Peers Heterogêneos (SN e ON) .................................. 82 Figura 40 - Registros em Múltiplos Servidores .............................. 83 Figura 41 - Anel de Chord composto por servidores ...................... 84 Figura 42 - Anel de Chord composto pelos usuários ...................... 84 Figura 43 - Anel de chord composto por SNs................................ 84
12
L I S T A D E T A B E L A S
Tabela 1 - Mensagens da Rede Gnutella ..................................... 28 Tabela 2 - Comparação entre as Redes P2P Estruturadas e Descentralizadas ....................................................................... 50 Tabela 3 - Comparação entre as Redes P2P Não Estruturadas e Descentralizadas ....................................................................... 71 Tabela 4 - Telefonia na internet X Compartilhamento de arquivos.. 73
13
1 . I N T R O D U Ç Ã O
1.1. I N T R O D U Ç Ã O À S R E D E S P E E R - T O - P E E R
As aplicações atuais estão cada vez mais complexas e requerem um
poder de processamento cada vez maior, além de mecanismos de
comunicação cada vez mais eficientes. Esta demanda trouxe um grande
interesse nas novas redes peer-to-peer (P2P), que até então foram
bastante utilizadas para compartilhamento e troca de arquivos. Além
disso, aplicações P2P que ganharam bastante destaque foram as de Troca
de Mensagens, por exemplo, o MSN Messenger [1] ou Yahoo Messenger
[2].
As principais motivações para a utilização de redes P2P são:
� Cria-se um ambiente onde é possível o compartilhamento de arquivos imensos.
� Distribuição de conteúdo de forma paralela.
� Utilização de um mecanismo eficiente de localização de recursos ou
dispositivos na rede.
� Replicação dos dados (redundância).
� Conceitos de confiança, autenticação e anonimato.
Redes P2P geralmente oferecem uma arquitetura de roteamento
bastante eficiente. Tal arquitetura é altamente escalável (possui a
capacidade de crescer de forma controlada e auto-organizável, sem
comprometer a qualidade da rede), possui robustez em ambientes WANs
(Wide Area Network) combinando aspectos de tolerância a falhas,
balanceamento de cargas e mecanismos de localização.
14
Portanto, Redes P2P são sistemas distribuídos com a característica
de não haver uma organização hierárquica entre os participantes. As
máquinas (peers) formam uma topologia auto-organizável no nível de
aplicação usando a infra-estrutura da camada de rede IP (este fato é
chamado de overlay de rede no nível de aplicação, como veremos no
Capítulo 2). Sistemas peer-to-peer (P2P) vão além dos serviços oferecidos
em um modelo Cliente-Servidor, pois existe uma simetria nos papéis,
onde um dispositivo pode em um instante desempenhar o papel de
cliente, e em outro instante, o papel do servidor.
1 . 2 . O B J E T I V O E C O N T R I B U I Ç Ã O
Diversos trabalhos sobre P2P estão sendo desenvolvidos no Brasil e
no mundo. Este trabalho tem por objetivo estudar as características das
principais arquiteturas de Rede P2P, fornecendo uma visão geral das
possibilidades para novas aplicações e tecnologias utilizando a abordagem
P2P.
Tem por objetivo explicar o funcionamento de redes P2P com uma
linguagem didática e com diversos exemplos, de forma que seja fácil o
entendimento dos conceitos aqui apresentados. Apresentamos diversos
sistemas que ainda estão em fase de desenvolvimento, como por
exemplo, OceanStore[28], SpamWatch[30], Squirrel[35],
SplitStream[36], que contribuirão para o desenvolvimento de aplicações
P2P. Também explicamos o funcionamento de sistemas bastante utilizados
para troca de arquivo como o Gnutella2[42], FastTrack/Kazaa[46],
BitTorrent[53], dentre outros. Finalmente, analisamos os conceitos
necessários para o desenvolvimento de aplicações P2P no mundo de Voz
sobre IP (VoIP).
15
1 . 3 . T R A B A L H O S R E L A C I O N A D O S
No Brasil, destaca-se o Grupo de Trabalho em Computação
Colaborativa (GT-P2P) da Universidade Federal de Pernambuco (UFPE).
Este grupo foi criado com o objetivo de avaliar os benefícios da
implantação de um serviço de suporte a sistemas P2P na RNP e
instituições conectadas, bem como analisar o impacto da utilização de tais
sistemas no desempenho da rede. Portanto, o GT-P2P trabalha na
construção de um middleware que fornecerá a infra-estrutura para o
desenvolvimento de aplicações P2P [3].
No Mundo, este trabalho está vinculado ao projeto “Le Déploiement
Dynamique des Services pour les Réseaux Actifs” entre ENST-Paris e
France Télécom R&D. Tal tese, desenvolvida pelo co-orientador desta
monografia, busca a perfeita sinergia entre duas importantes
contribuições ao domínio de sistemas distribuídos: redes ativas e redes
Peer-to-Peer (P2P). Assim, será definido um novo sistema P2P que,
através do compartilhamento de recursos (atributos) dos nós, permitirá a
distribuição dinâmica de serviços nas redes ativas que, por sua vez,
fornecerão a infra-estrutura de base para identificação e otimização do
tráfego das conexões entre pares nas redes P2P.
1 . 4 . E S T R U T U R A D E S T E T R A B A L H O
No Capítulo 2 é feito um estudo comparativo entre as algumas
arquiteturas e a arquitetura P2P. Discutem-se as características de
algumas arquiteturas, por exemplo, arquitetura Cliente-Servidor. Define-
se o que são Redes Overlay e observam-se algumas similaridades entre a
Rede P2P e as Grades (Grids). No final do capítulo, define-se uma
arquitetura abstrata de Rede P2P baseada no trabalho de [4].
No Capítulo 3 são apresentadas as arquiteturas clássicas das redes
16
P2P. Mostra-se que os sistemas podem ser classificados em relação ao
modelo de busca utilizado (Buscas Centralizadas; Busca
Descentralizada Não Estruturada por Inundação e Busca
Descentralizada Estruturada por Tabela Hash Distribuída). Em
seguida, são apresentados os modelos que deram inicio ao estudo de
redes P2P.
No Capítulo 4 são apresentadas as redes estruturadas baseadas
em buscas descentralizadas. Este tipo de sistema não possui um
servidor centralizado, mas existe uma estruturação significativa entre os
nós. A topologia da rede é controlada, e os documentos/arquivos são
posicionados em locais que posteriormente tornam fácil a sua localização.
Esse tipo de arquitetura em geral utiliza busca baseada em DHT[11].
Exemplos dessa arquitetura são os sistemas Chord[21], Pastry[31],
Tapestry[25] e CAN[18].
No Capítulo 5 são apresentadas as redes não estruturadas
baseadas em buscas descentralizadas ou híbridas (também
chamadas de semi-centralizadas). Este tipo de sistema não possui um
servidor centralizado, nem controle preciso sobre a topologia e
localização/busca de documentos. Exemplos da utilização desta
arquitetura são as redes FreeNet[39], Gnutella2[42], FastTrack/
Kazaa[46], BitTorrent[53], eDonkey2000[55]/Overnet[56]/
eMule[57].
No Capítulo 6, um estudo sobre redes de voz sobre ip (Tecnologia
VoIP) é desenvolvido. Apresenta-se os protocolos IETF SIP[61] e ITU-T
H.323[62] que são modelos que dependem da arquitetura cliente-
servidor, pois os servidores são utilizados para registrar os usuários e
fornecer os serviços de localização. Estudaremos as características de um
modelo de telefonia IP baseado em redes P2P (modelo descentralizado).
17
2 . I N Í C I O D A T E C N O L O G I A P 2 P
Neste capítulo, iremos iniciar o estudo sobre as arquiteturas de redes
P2P, comparando-as com alguns modelos já existentes, destacando
similaridades, vantagens ou desvantagens.
2 . 1 . P 2 P X A R Q U I T E T U R A S E X I S T E N T E S
Muitos modelos e arquiteturas atuais contêm conceitos similares aos das
redes P2P e é importante identificar em que momento estas arquiteturas são
parecidas para propor melhorias.
2 . 1 . 1 . R E D E S P 2 P X M O D E L O C L I E N T E - S E R V I D O R
O modelo Cliente-Servidor é o mais usado atualmente na Internet e no
desenvolvimento de muitas aplicações. Este modelo requer que os servidores
suportem uma alta taxa de requisição, e se o servidor não estiver preparado
para responder muitas requisições, isto pode ser um gargalo. Portanto, ele não
explora a real capacidade da rede, nem o potencial uso de processamento
distribuído. Já a rede P2P permite que os recursos e serviços computacionais
sejam compartilhados e acredita-se que tais redes serão utilizadas em uma
ampla gama de soluções de comunicação, onde os dispositivos (peers) possam
construir redes cooperativas auto-organizáveis (Figura 1).
F I G U R A 1 - T O P O L O G I A C L I E N T E - S E R V I D O R E P 2 P
18
O modelo Cliente-Servidor é constituído de três camadas: a camada de
interface, a camada de controle e a camada de dados (Figura 2). A
primeira camada do modelo Cliente-Servidor será o modo como o usuário
poderá interagir com o sistema, ou seja, a interface do usuário (provedora de
serviços para o usuário). A segunda camada (camada de controle ou regra de
negócios) poderá ser implementada de diversas maneiras, mas duas regras
caracterizam esta camada: a não existência de interface com o usuário e a
existência de dados voláteis, utilizados durante a fase de processamento do
sistema. A terceira camada (a camada de serviços de dados) consiste na
manutenção dos dados e do relacionamento entre eles. Geralmente é provido
através da utilização de um SGBD (Sistema Gerenciados de Banco de Dados)
[5].
F I G U R A 2 - M O D E L O D E A R Q U I T E T U R A T R Ê S C A M A D A S [ 5 ]
2 . 1 . 2 . R E D E S P 2 P X R E D E S O V E R L A Y
Rede Overlay é uma rede criada de forma abstrata (lógica ou virtual)
sobre uma rede já existente. Pode ser chamada também de Redes de
Cobertura. A rede overlay cria uma arquitetura com nível mais alto de
abstração, de modo a solucionar vários problemas que, em geral, são difíceis
de serem tratados ao nível de roteadores da rede (camada de rede). Um
exemplo clássico de rede overlay é a própria sub-rede IP, que é constituída
como uma rede lógica sobre as redes Frame Relay, ATMs e Ethernet [6].
Por sua vez, redes P2P podem utilizar o recurso de Overlay de redes para
se preocupar com o tratamento de problemas mais difíceis como a tolerância à
falhas, segurança e disponibilidade dos dados, criando uma abstração dos
19
níveis mais baixos. Preocupações como a entrega dos dados de maneira
confiável e a entrega de pacotes pelo menor caminho da rede são deixadas
para a camada de transporte/rede respectivamente (TCP/IP). Portanto, toda
Rede P2P é um tipo de rede Overlay, mas nem toda Rede Overlay é um tipo de
Rede P2P.
F I G U R A 3 - R E D E D E C O B E R T U R A ( O V E R L A Y )
Na Figura 3, tem-se um exemplo de uma rede overlay. Supondo que
exista uma rede física (mostrada na parte inferior da figura) e alguns
dispositivos desejem constituir um grupo P2P para o compartilhamento de
arquivos, uma possível topologia (virtual) seria a da parte superior da figura,
denotada por Rede de Cobertura. A aplicação estaria preocupada com os
serviços para o compartilhamento de arquivos, e não com o transporte dos
dados através da topologia (envolvendo mais nós que os existentes na rede
P2P).
2 . 1 . 3 . R E D E S P 2 P X G R A D E S ( G R I D S )
O foco de cada uma das arquiteturas é bem diferente. Enquanto as redes
P2P foram inicialmente criadas para o compartilhamento de recursos, os Grids
20
foram criados para fornecer uma arquitetura de computação de alto
desempenho. A idéia de um sistema de Grid é usar os computadores que estão
ociosos (Slaves) e fazê-los com que possam processar uma tarefa atribuída por
outro computador (Master). [7]
A vantagem de identificar algumas semelhanças entre tais arquiteturas é
imaginar os ambientes onde esta sinergia (o melhor de cada mundo) possa ser
utilizada como um mecanismo elegante na resolução de problemas. Algumas
semelhanças entre as duas arquiteturas:
� Alta dispersão geográfica: Tanto as redes P2P, como os Grids tem a
característica de trabalhar em escala global, agregando serviços localizados em varias partes do planeta.
� Controle distribuído: Não há uma única entidade que tenha poder
sobre todo o sistema. Isso é um reflexo da dispersão dos seus componentes, pois cada instituição pode implementar sua política em seus recursos locais.
� Compartilhamento: Tanto na arquitetura P2P como em Grid, tem-se a
idéia de compartilhamento de recursos. A principio, as redes P2P compartilhavam arquivos, e os Grids foram projetados para compartilhar o processamento, mas com um pouco de atenção notamos que ambos são exemplos de recursos.
2 . 2 . U M A A R Q U I T E T U R A A B S T R A T A D E R E D E P 2 P
Este tópico ilustra os componentes de uma arquitetura abstrata de uma
rede P2P encapsulada pela infra-estrutura da camada de rede IP, baseada no
modelo proposto por E. K. Lua, J. Crowcroft e M. Pias, University of
Cambridge; R. Sharma e N. Ang [4].
21
F I G U R A 4 – M O D E L O D E A R Q U I T E T U R A P 2 P [ 4 ]
Para o desenvolvimento de aplicações P2P, deve-se entender como
funciona a organização e o modelo da arquitetura P2P. Uma arquitetura
abstrata de uma rede P2P é mostrada na Figura 4.
Analisando as camadas inferiores primeiro, temos que a Camada de
Comunicação de Rede descreve as características das conexões e deve tratar
as conexões de tais dispositivos. A Camada de Gerenciamento dos Nós é
responsável pelo gerenciamento dos dispositivos (peers), o qual inclui a
localização de dispositivos e a otimização dos algoritmos de roteamento. A
Camada de Gerenciamento das Características trata dos requisitos de
segurança, confiabilidade, tolerância à falhas, dentre outros fatores que
garantam a robustez do sistema P2P como o gerenciamento dos acessos aos
recursos. A Camada Específica dos Serviços sustenta a infra-estrutura da
rede P2P e os componentes específicos da aplicação. A Camada de Aplicação
diz respeito às aplicações e os serviços que são implementados sobre a infra-
estrutura de rede P2P.
Neste capítulo foi feito um estudo comparativo entre as algumas
arquiteturas e a arquitetura P2P. No final do capítulo, define-se uma
arquitetura abstrata de Rede P2P.
22
3 . A R Q U I T E T U R A S P 2 P C L Á S S I C A S
Após uma análise das diferentes arquiteturas propostas e existentes na
atualidade, as aplicações P2P podem ser classificadas, em relação ao modelo
de busca, como aplicações de Busca Centralizada, Busca Descentralizada Não
Estruturada por Inundação e Busca Descentralizada Estruturada por Tabela
Hash Distribuída (DHT) [8].
3 . 1 . C A T E G O R I A D E B U S C A
Na Busca Centralizada, existe no sistema um ponto central de busca e,
para encontrar qualquer recurso do sistema, os nós precisam consultar o ponto
central. Depois de consultar este índice global, os nós podem trocar
informações diretamente uns com os outros.
Já na Busca Descentralizada Não Estruturada por Inundação, a
rede contém nós totalmente independentes, onde normalmente a busca é
encaminhada de um peer para o seu vizinho. Este sistema possui a
interessante idéia de ser totalmente independente de uma unidade central,
mas quando a rede é muito grande, pode apresentar baixo desempenho.
Finalmente, na Busca Descentralizada Estruturada por Tabela Hash
Distribuída (DHT), a rede contém certa autonomia pelo fato de usar uma
tabela hash para encontrar os elementos na rede. Separa-se o espaço de
busca entre os nós do sistema de forma que as mensagens são controladas e
as pesquisas não são feitas em dispositivos randômicos. As pesquisas são
feitas em locais específicos de acordo com uma Função Hash.
23
3 . 2 . M O D E L O S C L Á S S I C O S
São apresentados agora os modelos clássicos das redes P2P. Inicialmente, o
sistema do Napster[9] é discutido, representando uma Categoria Hierárquica
Centralizada, onde as buscas são feitas no servidor Central. Em seguida, o
sistema Gnutella[10] é apresentado, representando a idéia de buscas
descentralizada, onde as buscas são feitas por inundação e não há uma
hierarquia entre os nós. Estes dois modelos são muito importantes por
representar as principais arquiteturas que deram origem às idéias das redes
P2P. Finalmente, apresenta-se a idéia central dos algoritmos baseados em
Busca por Tabela Hash[11]. Estas idéias serão bastante utilizadas no
desenvolvimento das futuras aplicações P2P baseadas nos modelos CAN[18],
Chord[21], Pastry[31] e Tapestry[25] que serão apresentadas no próximo
capítulo.
3 . 2 . 1 . N A P S T E R – B U S C A C E N T R A L I Z A D A
Em 1999, o Napster[9] trouxe a idéia pioneira do compartilhamento de
arquivos com um provedor central que continha todos os índices dos arquivos
disponíveis. Um usuário se conecta ao servidor usando o programa cliente do
Napster. Em seguida, o programa cliente atualiza o servidor com os índices das
músicas que ele contém, ou seja, que existem no computador local. Quando o
usuário deseja efetuar uma consulta, para posteriormente fazer o download de
uma música, o cliente se comunica com o servidor, e faz a requisição pela
música. Em seguida, o servidor fornece ao cliente os endereços de outros
clientes que contenham a música.
A idéia é parecida com a arquitetura Cliente-Servidor[3], mas o servidor
Napster é usado somente para armazenar os índices dos arquivos (em quais
clientes os arquivos estão armazenados). Portanto, não existe o arquivo
fisicamente no servidor. Pela primeira vez, tinha-se um sistema distribuído em
que a transferência não acontecia do servidor para o cliente, mas sim de
clientes para clientes onde o provedor só funciona para a consulta (índice
24
global).
O sistema Napster é escalável, pois à medida que novos clientes entram
no sistema, eles contribuem com mais fontes de origem dos arquivos, e as
consultas introduzidas pelos novos clientes não geram um tráfego tão pesado
para o servidor. O problema com este sistema é que se o servidor estiver
indisponível, o sistema para de funcionar (ponto único de falha). O fato de
existir uma unidade central de controle também cria uma discussão sobre a
liberdade ou não do sistema, já que o controle do sistema é totalmente do
Sistema Napster. Acrescido a isso, existem diversas críticas ao fato do sistema
ser sujeito a congestionamento e não prover nenhum mecanismo de
segurança.
No final do ano de 1999, o Napster enfrentou o primeiro processo na
justiça e em 2001 um juiz ordenou que o sistema fosse fechado. Durante este
ano, outras redes P2P já começavam a crescer, por exemplo, as redes Gnutella
e Morpheus, e mais tarde quando o Napster foi reaberto, ele ofereceu seus
serviços de forma paga. A Figura 5 ilustra o funcionamento do Napster.
F I G U R A 5 - F U N C I O N A M E N T O D O S I S T E M A N A P S T E R [ 9 ]
25
3 . 2 . 2 . G N U T E L L A – B U S C A P O R I N U N D A Ç Ã O
Já o Gnutella[10] (também chamadado de Gnutella¹) foi inicialmente
desenvolvido pela Nullsoft (criadora do Winamp) no final de 1999. Quando a
Nullsoft foi comprada pela AOL (mais tarde AOL-Time Warner), o protocolo se
tornou um problema sério para a empresa, pois já se via neste tipo de
aplicação, uma grande ameaça aos direitos autorais e a industria fonográfica.
Em 2000, o programa foi disponibilizado em licença GNU[13] no servidor
da Nullsoft, mas o mesmo foi retirado algumas horas depois. Já era tarde
demais, o código já tinha sido baixado por milhares de usuários, e usando
técnicas de engenharia reversa, o protocolo foi descoberto. Outros clientes
foram logo disponibilizados, e o Gnutella se popularizou rapidamente.
O protocolo é do tipo descentralizado, onde tanto as pesquisas como os
downloads são feitos de forma distribuída em uma rede no nível de aplicação
(rede overlay). Este foi o primeiro sistema que usou uma rede no nível de
aplicação de forma desestruturada, onde os nós de rede poderiam entrar na
rede Gnutella sem precisar ter nenhum conhecimento prévio sobre a topologia
da rede.
A pesquisa por recursos da rede Gnutella é feita por meio de um
mecanismo de encaminhamento para os vizinhos. Quando um vizinho recebe
uma requisição para um arquivo que possui, ele manda uma resposta para o
peer que originou a requisição do arquivo. Uma desvantagem é que os nós
mantém conexões TCPs abertas uns com os outros, e como já é de se esperar,
se cada vizinho mandar a requisição para todos os seus vizinhos, gera-se uma
enorme quantidade de tráfego.
O tamanho de pacote IP é de 20 bytes, o de um segmento TCP é de 20
bytes, o do protocolo Gnutella é de 23 bytes e uma solicitação por um arquivo
tem um tamanho de 19 bytes. Somando-se todos os tamanhos, a solicitação é
enviada com um tamanho total de 83 bytes pela rede (camada 3). Quando o
26
número de peers cresce, a largura de banda utilizada também cresce. A Figura
6 abaixo demonstra tal fato: [14]
F I G U R A 6 - T A M A N H O D A S M E N S A G E N S G N U T E L L A [ 1 4 ]
O protocolo funciona bem para arquivos que estão replicados em
diversos computadores, mas para arquivos raros o protocolo não é tão
eficiente, já que o consumo de banda cresce linearmente com o tamanho de
nós na rede e com a quantidade de pesquisas que a rede está tratando. As
vantagens de uma rede desestruturada estão no fato que elas permitem uma
pesquisa de forma anônima e que não dependem de um servidor central.
A rede Gnutella foi bastante difundida por trazer a idéia de liberdade e
anonimato, diferente de redes com servidor centrais em que uma empresa
poderia verificar qual o conteúdo ou artista está sendo mais procurado para
tirar vantagem em uma campanha de marketing.
A Figura 7 ilustra um exemplo. O dispositivo 1 deseja encontrar um
recurso que só estará disponível nos dispositivos 5 e 7. O dispositivo 1 inicia
enviando uma mensagem de solicitação para o dispositivo 2. Em seguida, o
dispositivo 2 envia uma mensagem aos dispositivos 3 e 4, informando que o
dispositivo 1 esta requisitando tal recurso. O dispositivo 4 envia a mesma
mensagem aos dispositivos 6 e 7, e o dispositivo 3 envia a mensagem ao
dispositivo 5. O dispositivo 5 e o dispositivo 7 possuem tal recurso e
respondem à solicitação do dispositivo 1. Finalmente, o recurso é
compartilhado.
27
Portanto, o protocolo Gnutella baseia-se em pesquisas distribuídas de
forma descentralizada em que todos os peers estão no mesmo nível de
hierarquia e são denominados serventes (servents) [15], conforme mostra a
Figura 8.
F I G U R A 8 - S E R V E N T E S D A R E D E G N U T E L L A [ 1 5 ]
F I G U R A 7 - F U N C I O N A M E N T O D A R E D E G N U T E L L A
28
A comunicação entre os serventes é feita a partir de um conjunto de
regras definidas pelo protocolo, as principais são mostradas na Tabela 1.
Comando Descrição
Ping
Usado ativamente para descobrir peers na rede. Um servente que recebe um comando Ping deve responder com o comando Pong
Pong Este comando é usado para responder um Ping. Na resposta é enviado o endereço do servente e a quantidade de dados que ele está disponibilizando para a rede.
Query
Mecanismo de localização na rede distribuída. Quando um servente recebe um comando Solicitação (Query), ele deve verificar se contém o arquivo, e caso ele tenha, responde com um comando Acerto na Solicitação (QueryHit)
QueryHit Este comando é usado para responder um Query. Na resposta são enviadas todas as informações necessárias para que o solicitante obtenha os dados desejados.
Push Mecanismo que permite com que um servente que esteja por trás de um firewall possa contribuir com a rede.
T A B E L A 1 - M E N S A G E N S D A R E D E G N U T E L L A
Um servente se conecta na rede Gnutella através do estabelecimento de
uma conexão com outro servente que já pertença à rede. Para obter uma
conexão, o servente deve mandar a seguinte mensagem:
GNUTELLA CONNECT/<string com a versão do protocolo>\n\n
Por exemplo:
GNUTELLA CONNECT/GNUTELLA CONNECT/0.6\n\n
A figura 9 identifica a quantidade de bytes que cada campo do protocolo
usa. O campo Description_ID é o identificador da mensagem. Em seguida, o
campo Payload_Descriptor identifica qual das seguintes mensagens está
29
sendo transportada: Ping, Pong, Query, QueryHit ou Push. O campo TTL
(Time-to-Live) controla o tempo que este pacote ficará na rede antes de ser
descartado. Cada servente que recebe a mensagem faz o decremento do TTL,
e quando este campo chega a zero a mensagem é descartada. O campo Hops
guarda o número de peers que mensagem passou, e cada peer incrementa
este campo ao enviar a mensagem ao próximo. Finalmente, o
Payload_lenght se refere ao tamanho da mensagem que está sendo
transmitida (encapsulada) pelo protocolo Gnutella.
F I G U R A 9 - P R O T O C O L O G N U T E L L A ( 2 3 B Y T E S ) [ 1 5 ]
O processo de roteamento das mensagens pela rede Gnutella tem um
comportamento bem definido. Mensagens do tipo Pong só podem ser enviadas
pelo caminho em que a mensagem de Ping tenha passado, já que o Pong é
uma resposta ao Ping. Isto garante que somente os peers que tenham visto a
mensagem de Ping vejam a resposta. Se um servente recebe uma mensagem
Pong cujo Description_ID ele não tenha visto, a mensagem é descartada. A
mesma lógica é aplicada a mensagens do tipo QueryHit, que só atravessam
um caminho pelo qual uma mensagem Query tenha passado. Este
comportamento é ilustrado pela Figura 10.
30
F I G U R A 1 0 - R E S P O S T A A S M E N S A G E N S P I N G E Q U E R Y
Quando um servente recebe uma mensagem do tipo Ping e Query, ele
encaminha a mensagem a todos os serventes diretamente conectados, com
exceção do servente que enviou a mensagem. Também é interessante o fato
que se um servente receber uma mensagem cujo Descriptor_ID já tenha
sido recebido anteriormente, ele não encaminha a mensagem para evitar laços
(loops) de mensagens.
Quando um servente recebe uma mensagem QueryHit (resposta a
solicitação de algum arquivo pedido anteriormente) ele pode iniciar o
download. Uma conexão é estabelecida entre origem e destino.
Para fazer o download, o protocolo utilizado pelos serventes é o HTTP
utilizando o método GET e enviando o nome do arquivo como parâmetro. O
formato da mensagem segue o modelo abaixo:
Onde os campos <File Index> e <File Name> são campos retornados na
mensagem QueryHit . Por exemplo:
31
Por último, vale lembrar que nem sempre é possível estabelecer uma
conexão direta entre serventes, por exemplo, quando um servente está
protegido por um Firewall que não permite receber conexões. Nestes casos, o
servente que deseja fazer o download do arquivo envia uma mensagem Push
Quando um servente recebe uma mensagem Push, ele tenta iniciar a conexão.
Caso esta conexão não possa ser estabelecida, é provável que os dois
serventes estejam protegidos por firewalls, e se este for o caso, a
transferência do arquivo não será possível.
A Figura 11 demonstra os tipos de mensagens da rede Gnutella e o
funcionamento do protocolo. O peer que está no centro da figura precisa que
sua mensagem seja encaminhada por todos os peers na rede (indicado na
figura por 1) até que chegue ao peer que contém o arquivo (indicado na figura
por 2) e então o peer pode baixar o arquivo (indicado na figura por 3).
F I G U R A 1 1 - T I P O S D E M E N S A G E N S N A R E D E G N U T E L L A
3 . 2 . 3 . T A B E L A S H A S H D I S T R I B U Í D A S - D H T
Redes P2P podem ser controladas de forma que as pesquisas não são
feitas em dispositivos randômicos, mas sim em locais específicos. Utilizando-se
32
Tabelas Hash Distribuídas (Distributed Hash Table – DHT) uma consulta por
um objeto ou valor é feita de maneira determinística, pois encontra
diretamente o dispositivo que está associado ao objeto procurado. Isto é feito
da seguinte maneira: um número randômico Node_ID é associado a cada
dispositivo (peer). Objetos recebem identificadores únicos chamados de chaves
(Keys) [4].
Cada Chave é mapeada pela camada de rede P2P para um único
dispositivo da rede. A rede suporta o armazenamento e localização do par
{key, value}. Os comandos disponíveis são: put(key, value) que coloca
uma chave associada a um certo valor, remove(key) que remove a
associação de uma chave a um certo valor e get(key) que fornece um
mecanismo de retornar um valor associado a uma certa chave. Tais operações
envolvem o roteamento dos pedidos ao dispositivo relacionado à chave (key).
Este esquema é mostrado na Figura 12.
F I G U R A 1 2 - A R Q U I T E T U R A D H T [ 4 ]
Cada dispositivo mantém uma pequena tabela com informações
referentes ao Node_ID e endereço IP dos vizinhos. Mensagens são
encaminhadas pela rede P2P (que usa a camada de rede tradicional) para o
Node_ID mais próximo da chave Key. O caminho real dos dispositivos no
33
nível físico pode ser totalmente diferente do caminho usado na rede P2P
utilizando a tabela de hash (DHT). Existem algoritmos bastante eficientes que
garantem que qualquer objeto pode ser localizado em O(logN), conforme é
demonstrado em [17].
Sistemas baseados em DHT são eficientes e suportam um rápido
desenvolvimento de uma grande variedade de aplicações que estão surgindo
no mundo da Internet, desde sistemas de localização de recursos até
multicasts no nível de aplicação.
Neste capítulo apresentamos as arquiteturas clássicas das redes P2P.
Mostramos que os sistemas podem ser classificados em relação ao modelo de
busca utilizado (Buscas Centralizadas; Busca Descentralizada Não
Estruturada por Inundação e Busca Descentralizada Estruturada por
Tabela Hash Distribuída). Também foram apresentados os modelos que
deram inicio ao estudo de redes P2P (Napster e Gnutella).
34
4 . R E D E S P 2 P E S T R U T U R A D A S E
D E S C E N T R A L I Z A D A S
O funcionamento desta classe baseia-se na atribuição de chave aos itens
de dados e na construção de um grafo com os dispositivos. Cada chave (que
representa um item de dado) é mapeada para um dispositivo (peer) do grafo.
Este grafo é usado para localizar os recursos da rede de forma eficiente. A
pesquisa é feita a partir de uma dada chave, localizando o dispositivo que terá
uma copia do recurso procurado, ou uma referência para o dispositivo que
contém tal recurso.
4 . 1 . C A N : C O N T E N T A D D R E S S A B L E N E T W O R K
O CAN[18] é uma infra-estrutura P2P descentralizada que funciona a
partir de tabelas hash. Este modelo foi desenvolvimento para ser escalável,
tolerante a falhas e auto-organizável. Ele é baseado em um espaço virtual de
coordenadas cartesianas com d dimensões onde cada dispositivo fica
responsável por uma porção do plano cartesiano (denominado de Zona do
dispositivo), conforme ilustra a Figura 13.
F I G U R A 1 3 - Z O N A D O S D I S P O S I T I V O S ( C A N )
zona do nó B
35
Na Figura 13, existem cinco dispositivo (A, B, C, D, E) em uma dimensão
2D. O plano é dividido de maneira que cada dispositivo é responsável por uma
zona (porção do plano). Por exemplo, o dispositivo B é responsável pela zona
0.5-1.0 (referente ao eixo X) ate 0.0-0.5 (referente ao eixo Y). A partição das
zonas é feito de forma dinâmica, portanto quando um novo nó é incluído na
rede, as posições das zonas são alteradas.
Cada peer que entra na rede deve ter seu próprio espaço de
coordenadas. Isto é feito dividindo-se a zona de um peer pela metade, onde
uma metade fica para o dono da zona, e a outra é reservada ao novo peer.
Numa rede CAN de duas dimensões, um peer seria escolhido de forma
randômica, e a sua zona seria dividida na dimensão X ou na dimensão Y.
A Figura 14 ilustra um exemplo dessa divisão randômica. Tem-se
inicialmente somente o peer 1. Quando o peer 2 deseja entrar, escolhe-se um
peer existente na rede e sua zona é dividida pela metade; como só existe o
peer 1 no sistema, uma metade fica para o peer 1 e a outra para o peer 2. O
processo continua até que a rede tenha 4 peers, onde as divisões são nos
eixos horizontais ou verticais. Tem-se no final do processo que os vizinhos do
peer 3 são os peers 1, 2, 4, e do peer 1 são os peers 2 e 3.
F I G U R A 1 4 - A T R I B U I Ç Ã O D E Z O N A S D E M A N E I R A D I N Â M I C A
Cada dispositivo que participa da rede mantém uma tabela com
informações sobre o endereço IP e as coordenadas da zona de cada vizinho.
Usando essas informações sobre os vizinhos, um peer é capaz de enviar
mensagens para outro, através de um esquema de melhor esforço (algoritmo
guloso), onde cada peer envia a mensagem ao peer cuja zona está mais
próxima do destino.
36
O espaço virtual de coordenadas é usado para armazenar o par {chave
K, valor V}. A chave K é mapeada de forma determinística para um ponto P
no espaço virtual de coordenadas usando uma função Hash. O dispositivo que
contém o ponto P em sua zona será o responsável por guardar o valor V
associado à chave K e responder as solicitações pelo par {K, V} [19]. O
algoritmo é ilustrado na Figura 15.
F I G U R A 1 5 - A L G O R I T M O C A N : G U A R D A { C H A V E , V A L O R }
Quando um outro dispositivo deseja recuperar o valor da chave K, ele
usa a função hash determinística e faz a requisição ao peer responsável pela
zona onde o par {K, V} está armazenado. Esta requisição é encaminhada por
toda a rede, através de um algoritmo guloso. Quando a solicitação é recebida
pelo peer que contém a chave desejada, ele responde a solicitação (Figura 16).
F I G U R A 1 6 - A L G O R I T M O C A N : R E C U P E R A { C H A V E , V A L O R }
37
Quando um peer deixa de existir na rede CAN, o processo de reassumir a
zona deste peer (denominado de Takeover) é iniciado. Este processo garante
que um dos vizinhos do peer que deixou a rede (por exemplo, por causa de
uma falha) assuma a zona. O peer atualiza então a sua tabela de vizinhos, e
também envia mensagens de atualização aos seus novos vizinhos para que
eles atualizem suas tabelas. O numero de vizinhos que um peer pode ter
depende somente da dimensão do espaço de coordenados (n = 2 x d) e é
independente do número de peers existentes na rede.
Uma melhoria ao modelo CAN pode ser feita se múltiplas instâncias de
coordenadas virtuais forem assumidas. Cada peer assume uma zona em cada
instância das coordenadas virtuais, portanto tendo vizinhos diferentes e
coordenada diferentes. Cada instância é chamada de realidade. Para uma rede
CAN com R realidades, cada peer recebe R coordenadas (R zonas) com
conjuntos de vizinhos diferentes (um para cada zona).
O conteúdo da tabela hash é replicado em cada realidade para aumentar
a disponibilidade dos dados. Uma requisição poderia ser pesquisada de forma
paralela em todas as realidades, reduzindo a latência da pesquisa e
aumentando a confiabilidade do sistema. Um par {K, V}, usando uma rede
com 3 realidades, seria mapeado para três locais diferente, um em cada
realidade, podendo ser armazenado em 3 peers distintos. Se uma pesquisa for
efetuada pelo par {K, V}, este só estaria indisponível se nenhuma das cópias
estiver disponível (tolerância à falha). A desvantagem seria o overhead
introduzido no sistema decorrente das várias realidades, usando maior espaço
de armazenamento e consumindo um maior poder de processamento. [20]
4 . 2 . C H O R D
O modelo do CHORD[21] tenta minimizar os efeitos causados pela ação
de um nó entrar ou sair da rede. Neste modelo, existe um espaço circular
(anel) onde os nós e as chaves são colocados em posições crescentes do anel.
O Node_ID é determinado através da função hash SHA-1(endereço_ip),
38
enquanto a Chave_ID é determinada através da função hash SHA-
1(valor_chave). Uma chave é mapeada para o primeiro Node_ID que seja
maior ou igual a Chave_ID (a chave é mapeada para o próximo peer no
sentido horário).
Para entender este conceito, vamos ao exemplo. Supondo que existam
dez dispositivos na rede, onde os dispositivos são representados na Figura 17
por círculos. Existem também cinco chaves e elas são representadas por
quadrados. Seja o endereço 200.253.251.32 o IP de um peer e ao utilizar a
função hash SHA-1(200.253.251.32) tal dispositivo tenha recebido
Node_ID = 56. Representa-se tal peer por N56. Agora, seja a chave
“musica1.mp3” de tal forma que ao usar a função hash SHA-
1(musica1.mp3), este arquivo tenha recebido Chave_ID com valor 54,
representando-o por K54. Observando a Figura 17, pode-se identificar que o
próximo peer (em sentido horário) a partir da chave K54 é o peer N56.
Portanto o mapeamento da chave K54 será feito para o peer N56.
F I G U R A 1 7 - E X E M P L O D E U M A N E L D E C H O R D
Da mesma forma, na Figura 17, os mapeamentos das chaves K24 e K30
serão feitos para N32. O peer N32 é chamado de sucessor do peer N21 já
39
que é o próximo peer em sentido horário do anel. O circulo onde os Node_ID’s
e Chave_ID’s estão armazenados é denominado Anel de Chord.
Cada peer é responsável por um conjunto de N chaves, e se o peer
deixar a rede, as chaves são atribuídas automaticamente ao próximo peer no
sentido horário do anel. Denomina-se de M o número de bits do Chave_ID e
Node_ID. [22]
Para que a consistência seja mantida quando um peer entra na rede,
algumas chaves serão mapeadas para este peer, pois ele está mais próximo
destas chaves. Da mesma forma, quando um peer sai da rede, chaves que
tinham como sucessor este peer, agora vão ter o próximo peer do anel
(sucessor do peer que acabou de sair). Por exemplo, ainda na Figura 17, se
um novo peer entrar com um valor N28, a chave K24 será atribuída a este
peer, e o sucessor do peer N21 será atualizado para o peer N28. Da mesma
forma, quando um peer sai da rede, as chaves que estavam mapeadas para
este peer serão mapeadas para o sucessor dele.
É importante observar que a atualização dessas informações é feita de
forma transparente para os peers, pois a própria organização da rede Chord é
responsável pela manutenção da topologia.
Para localizar uma chave na rede, uma estratégia que poderia ser
adotada é a de percorrer a rede em sentido horário procurando pela chave
desejada. No pior caso, para uma rede com N peers, a requisição seria
encontrada no peer N-1 (peer que é o predecessor do que esta iniciando a
pesquisa).
Na Figura 18, se o peer N8 deseja localizar a chave K54, a requisição é
enviada ao sucessor (N14), e cada peer reenvia a requisição ao seu sucessor,
percorrendo o anel até encontrar a chave. Neste exemplo, a chave está
localizada no N56 e tem uma complexidade O(N) para a localização da chave.
Neste esquema, cada peer só tem conhecimento de dois peers do anel, o seu
40
sucessor (para enviar ou encaminhar uma solicitação) e o seu predecessor
(para gerenciamento da rede, no caso de um peer sair da rede). A estrutura de
dado que dá suporte a este tipo de Anel de Chord é uma lista circular e a
vantagem desse esquema é a sua fácil implementação.
F I G U R A 1 8 – L O C A L I Z A Ç Ã O D E C H A V E S I M P L E S
Pode-se encontrar um algoritmo que tenha uma ordem de complexidade
melhor do que o de busca seqüencial mostrado anteriormente. O esquema
anterior é chamado de Localização de Chave Simples. O esquema que é
descrito agora é chamado de Localização de Chave Escapável. Nesse
algoritmo, cada peer mantém uma tabela de rotas com M registros, chamada
de Finger Table, conforme Figura 19. A vantagem desse esquema é a sua
eficiência na localização das chaves. [23]
41
F I G U R A 1 9 - L O C A L I Z A Ç Ã O D E C H A V E E S C A P Á V E L
Quando um peer entra no sistema, alguns registros da tabela finger
precisam ser atualizados para refletir a mudança do anel e garantir que o
mecanismo de localização possa funcionar corretamente. Usa-se um protocolo
de estabilização que é executado periodicamente em modo background para
atualizar os registros da tabela.
Quando o sucessor de um peer falha, o peer deve ser capaz de encontrar
um novo sucessor. Para isso, o peer deve manter uma lista de R sucessores.
Caso seu sucessor imediato não responda, o peer é capaz de contatar o
próximo sucessor a partir desta lista até que consiga se comunicar com algum.
Se cada peer tiver uma probabilidade P de falha, a probabilidade de falha em
todos os peers do sistema é de P elevado a R. Quanto maior for o valor de R
(lista de sucessores) maior a robustez do sistema e menor a probabilidade do
sistema falhar.
42
Aplicabilidade do Sistema Chord:
O Sistema Chord teria uma boa aplicabilidade se implementado para o
serviço DNS. Em [24] existe um estudo sobre a implementação do serviço de
DNS utilizando a tecnologia Chord e DHT. O DNS atual depende do uso de
servidores centrais (denominados root servers) e requer que os hosts sejam
organizados de maneira hierárquica, usando o conceito de domínio (máquinas
com uma administração comum); já o sistema Chord dispensaria a
configuração e utilização de qualquer servidor, pois não impõe nenhuma
estrutura aos nomes, além de poder ser usado para localizar não somente
hosts, mas também encontrar qualquer objeto na rede.
4 . 3 . T A P E S T R Y
Tapestry[25] foi um modelo criado com base em Plaxton[26], mas tem
mecanismos adicionais para prover escalabilidade, recuperação em caso de
falhas e ataques. Plaxton propôs uma estrutura de dados distribuída para
localizar objetos a partir de seus nomes, que estejam em um peer.
Diferentemente, Tapestry faz uso de múltiplos objetos, para evitar o problema
de um ponto de falha único.
O mecanismo de localização e roteamento é baseado em prefixo ou
sufixo do Node_ID. Um exemplo baseado em sufixo é mostrado na Figura 20.
F I G U R A 2 0 - R O T E A M E N T O E M U M A R E D E T A P E S T R Y
Suponha uma mensagem para o peer 4598 que tem como origem o peer
6789. Saindo do peer 6789, têm-se duas opções: peer B437 ou peer B4F8. A
43
pesquisa baseada em sufixo compara o ultimo numero (8) e encaminha a
mensagem para o peer B4F8. No próximo passo, a pesquisa compara os dois
últimos números (98) e a mensagem é encaminhada para o peer 9098.
Seguindo a mesma lógica, a mensagem é encaminhada para o peer 7598 após
comparar com os três últimos números, e finalmente a mensagem é entregue
ao peer 4598. A técnica descrita tem algumas similaridades com a hierarquia
do endereçamento IP usado atualmente.
Para aumentar a disponibilidade dos dados, no modelo de Tapestry os
dados são replicados e isso permite que a camada de aplicação determine
onde ir buscar o dado, já que existem varias fontes disponíveis. Isso
geralmente é feito baseado em alguma métrica, por exemplo, na localidade
mais próxima ou no peer com maior largura de banda.
Portanto, o sistema de Tapestry tenta resolver também o problema de
ser tolerante à falhas ao colocar várias réplicas do mesmo objeto na rede. A
distribuição dos objetos é feita usando o conceito de Roteamento
Incremental (Surrogate Routing). Esta técnica de roteamento provê um
mecanismo para mapear qualquer identificador para um único peer. [27]
O modelo alcança alguns pontos em relação à adaptação de falhas por
ser implementado em uma camada acima do TCP e do UDP. No caso de falha,
rotas de backup podem ser usadas para garantir a conectividade do sistema.
4 . 3 . 1 . A P L I C A B I L I D A D E D O S I S T E M A
T A P E S T R Y :
4 . 3 . 1 . 1 . S I S T E M A O C E A N S T O R E
OceanStore[28] é um sistema que tem o intuito de prover
armazenamento de arquivos de maneira persistente em servidores não
confiáveis. Qualquer computador pode entrar na infra-estrutura, contribuindo
no armazenamento, mas para isso o usuário deve estar registrado em um
44
provedor do serviço OceanStore. Tais provedores de serviço doam ou pedem
espaço uns aos outros, embora isso seja feito de maneira transparente ao
usuário.
Provedores de serviço podem criar réplicas locais dos dados a qualquer
momento. Tais réplicas servem para prover um acesso mais rápido aos dados,
reduzindo congestionamento da rede e garantindo a robustez do sistema. Cria-
se assim um modelo de tolerância à falhas para prover consistência entre
diversas réplicas do sistema.
A idéia do sistema OceanStore é guardar cada versão do objeto (dados)
de forma permanente com a permissão de somente leitura (read-only) por
centenas ou milhares de servidores. Um pequeno subconjunto dos fragmentos
do arquivo seria suficiente para reconstruir o objeto (dados) de forma que
somente um desastre com proporções globais poderia danificar máquinas
suficientes para que o objeto não fosse reconstruído. O sistema poderia se
adaptar aos ataques de negação de serviço ao migrar os dados para áreas que
não estejam sendo afetadas pelo ataque. [29]
4 . 3 . 1 . 2 . S I S T E M A S P A M W A T C H
SpamWatch[30] é um sistema colaborativo para a filtragem de spams
(mensagens de e-mails indesejáveis). O sistema é construído a partir da
arquitetura Tapestry, já que esta fornece infra-estrutura de roteamento e
localização da rede peer-to-peer.
O SpamWatch é um sistema Colaborativo, pois nele todos os usuários
da comunidade contribuem uns com os outros ao marcar certos e-mails como
sendo spam (tal técnica de marcação é denominada de tagging).
Os dispositivos que realmente participam da rede peer-to-peer são os
servidores de e-mail, liberando os usuários para serem somente clientes. A
arquitetura Tapestry garante a localização eficiente de e-mails marcados como
45
spam, para que estes sejam direcionados para a caixa de lixeira.
Os e-mails que são marcados como spam são identificados por seu
conteúdo. Técnicas usadas pelos spammers tais como um espaçamento
diferente entre as palavras do e-mail ou a cor usada no texto não irão enganar
o SpamWatch.
Atualmente, já estão implementados os programas WatchTower (que é
executado no servidor de e-mail e será o cliente da rede colaborativa P2P) e
SpamWatch Outlook Toolbar que é o aplicativo onde o usuário irá fazer a
marcação dos e-mails como spam, Figura 21.
F I G U R A 2 1 - S I S T E M A S P A M W A T C H ( O U T L O O K T O O L B A R )
46
4 . 4 . P A S T R Y
O Modelo Pastry[31] está em desenvolvimento pela Microsoft
Research[32], no intuito de construir uma plataforma para o desenvolvimento
de aplicações peer-to-peer descentralizadas, auto-organizáveis e tolerantes à
falhas. O modelo de Pastry é bem parecido com o modelo de Tapestry, pois
utiliza roteamento baseado em prefixo para construir redes overlay.
Cada peer do sistema Pastry possui um identificador de 128 bits
(Node_ID). Sempre que um novo peer entra no sistema, este número é
escolhido de forma única e aleatoriamente em um espaço de números de 0 até
2^128 – 1. Os peers que possuem Node_ID próximos estão distribuídos
próximos uns dos outros. Além disso, cada peer contém uma tabela de
roteamento, um conjunto de vizinhos e um conjunto de nós folhas.
A tabela de roteamento, Figura 22, é formada em relação aos prefixos
dos peers. O tamanho da tabela de roteamento que cada peer deve manter é
O(logN) , sendo N o número de peers ativos no sistema. Os registro da tabela
de roteamento contém os endereços IPs dos peers que estão mais próximos
entre si. Por exemplo, uma mensagem cuja chave seja K é roteada para o peer
cujo Node_ID seja numericamente o mais próximo de K.
F I G U R A 2 2 - T A B E L A D E R O T E A M E N T O
O conjunto de vizinhança, Figura 23, contém os Node_IDs dos peers
que estão mais próximos (de acordo com uma métrica de proximidade). O
conjunto de vizinhança é normalmente utilizado no roteamento das
47
mensagens.
F I G U R A 2 3 - C O N J U N T O D E V I Z I N H A N Ç A
O conjunto de folhas, Figura 24, é formado pelos peers sucessores e
peers predecessores mais próximos do nó.
F I G U R A 2 4 - C O N J U N T O D E F O L H A S
Para exemplificar, na Figura 25 é apresentado um nó Pastry cujo
Node_ID é 10233102. A figura ilustra o conjunto de folhas que contém os
nós que estão numericamente mais próximos do nó local. Ilustra também a
tabela de roteamento que é usada para rotear uma chave K para os peers
que tenham Node_ID mais próximos de K, e finalmente um conjunto de
vizinhos que estão mais próximos do nó local de acordo com a métrica de
proximidade.
F I G U R A 2 5 - E L E M E N T O S D E U M P E E R P A S T R Y
Caso haja interesse em replicação, o peer responsável por certa chave
48
envia uma mensagem para mapeá-lo em N peers do conjunto de nós folhas.
Considerando que estes nós estão espalhados por todo o mundo, um desastre
natural no Japão, por exemplo, não deixaria o sistema da África inoperante,
pois este não seria atingido, garantindo a disponibilidade dos dados. Portanto,
os sistemas Pastry guardam os dados replicados no conjunto de nós folhas.
Quando um novo peer entra no sistema Pastry, ele recebe um Node_ID
aleatório e em seguida precisa iniciar sua tabela de roteamento e avisar aos
vizinhos sobre sua existência. Existe um serviço de inicialização (bootstrap) na
rede, e o novo peer utiliza este serviço para fazer sua comunicação com o peer
mais próximo a ele. O peer mais próximo envia uma mensagem de Join para o
novo peer, e todos os peers que estão no caminho vêem esta mensagem.
Cada peer que recebe esta mensagem envia sua tabela de roteamento para o
novo peer. Desta forma, o novo peer povoa sua tabela de roteamento de
forma adequada, e os peers que receberam a mensagem de Join ficam cientes
da entrada do novo peer. [31]
4 . 4 . 1 . A P L I C A B I L I D A D E D O S I S T E M A P A S T R Y :
4 . 4 . 1 . 1 . S I S T E M A S C R I B E
Scribe[33] é um eficiente sistema de comunicação de grupo e notificação
de eventos. O sistema provê o envio de mensagens multicasts (entregue a um
grupo) ou anycasts (entregue a qualquer um dos membros).
4 . 4 . 1 . 2 . S I S T E M A P A S T
Past[34] é um sistema de larga escala utilizado no armazenamentos de
sistemas peer-to-peer de maneira escalável e de alta disponibilidade já que
fornece mecanismos de tolerância a falhas. Arquivos no Past são imutáveis e
podem ser compartilhados entre os usuários do sistema.
49
4 . 4 . 1 . 3 . S I S T E M A S Q U I R R E L
Squirrel[35] é um sistema cooperativo descentralizado utilizado para
prover web caching baseado na idéia de compartilhar as caches locais dos
navegadores dos usuários. O sistema aumenta a performance, melhora o uso
da largura de banda, diminui a latência e dispensa o uso de do servidor proxy.
4 . 4 . 1 . 4 . S I S T E M A S P L I T S T R E A M
SplitStream[36] é um sistema de distribuição de dados de alta
velocidade. Um pequeno número de nós interiores são responsáveis por
encaminhar mensagens multicasts. A idéia é dividir o conteúdo de um arquivo
entre várias árvores separadas de grupos multicasts, otimizando a
disponibilidade do arquivo.
4 . 4 . 1 . 5 . S I S T E M A P O S T
POST[37] é uma infra-estrutura de encaminhamento de mensagens. O
sistema está sendo usado para prover serviço de e-mail seguro (ePOST),
serviço de troca de mensagens seguras (imPOST – instant messaging), bem
como sistemas colaborativos como calendário e lembretes compartilhados.
4 . 4 . 1 . 6 . S I S T E M A S C R I V E N E R
Scrivener[38] é uma arquitetura que força o compartilhamento de
recursos em redes peer-to-peer ocorra de forma justa. Existem no sistema
conceitos econômicos que incentivam os peers a seguirem as regras,
penalizando usuários que sejam egoístas.
Neste capítulo apresentamos as redes estruturadas baseadas em
buscas descentralizadas. Esse tipo de arquitetura utiliza busca baseada em
DHT[11]. Exemplos dessa arquitetura são os sistemas Chord[21],
Pastry[31], Tapestry[25] e CAN[18].
50
Abaixo, a Tabela 2 ilustra as características entre as arquiteturas:
Redes P2P Estruturadas e Descentralizadas X CAN CHORD TAPESTRY PASTRY
Arquitetura
Baseado em um espaço virtual de
coordenadas cartesianas onde cada dispositivo fica responsável
por uma porção do plano.
Estrutura circular (Anel de Chord) onde os nós e as
chaves são colocados em
posições crescentes do
anel.
Estrutura de dados distribuída para
localizar objetos a partir de seus
nomes, baseado em sufixo.
Utiliza roteamento baseado em
prefixo onde cada peer contém cada peer contém uma
tabela de roteamento, um
conjunto de vizinhos e um
conjunto de nós folhas.
Mecanismo de Localização
A chave K é mapeada de forma determinística para
um ponto P. O dispositivo que
contém o ponto P em sua zona será
o responsável responder as
solicitações por este dado.
A chave é mapeada através de função hash para o primeiro
Node_ID que seja maior ou igual a
Chave_ID no Anel de Chord (a chave é mapeada para o próximo peer no sentido horário).
O mecanismo de localização e roteamento é
baseado em sufixo do Node_ID (determinado
através da função hash).
Utiliza o conjunto de folhas
(numericamente mais próximos), a
tabela de roteamento (peers
que tenham Node_ID mais
próximos a chave) e um conjunto de vizinhos (estão
mais próximos do nó local).
Confiabilidade e Tolerância à Falhas
Quando um peer deixa de existir na
rede CAN, o processo de
reassumir a zona deste peer é iniciado. Este
processo garante que um dos
vizinhos do peer que deixou a rede assuma a zona.
Quando o sucessor de um
peer falha, o peer deve ser capaz de encontrar um novo
sucessor. Para isso, o peer deve manter uma lista de sucessores. O peer é capaz de
contatar o próximo sucessor até que
consiga se comunicar com
algum.
Tenta resolver o problema de ser tolerante à falhas ao colocar várias
réplicas do mesmo objeto na rede. No
caso de falha, rotas de backup
podem ser usadas para garantir a
conectividade do sistema.
Utiliza a replicação de dados. O peer responsável por
certa chave envia uma mensagem
para mapeá-lo nos peers do conjunto
de nós folhas. Portanto, os
sistemas Pastry guardam os dados
replicados no conjunto de nós
folhas.
T A B E L A 2 - C O M P A R A Ç Ã O E N T R E A S R E D E S P 2 P
E S T R U T U R A D A S E D E S C E N T R A L I Z A D A S
51
5 . R E D E S P 2 P D E S C E N T R A L I Z A D A S E
N Ã O E S T R U T U R A D A S
Esta categoria organiza os peers de maneira randômica (não
estruturada). Nesta seção analisa as seguintes arquiteturas: FreeNet[39],
Gnutella2[42], FastTrack/ Kazaa[46], BitTorrent[53],
eDonkey2000[55]/Overnet[56]/ eMule[57].
5 . 1 . F R E E N E T
Freenet[39] é uma rede adaptativa P2P formada por um conjunto de
peers que armazenam e recuperam dados de forma anônima através da
atribuição de chaves. Cada peer tem apenas informações sobre quem são seus
vizinhos, e qualquer consulta é iniciada a partir deles. As principais
características da rede Freenet são:
� Contém mecanismos de segurança contra ataques de peers maliciosos.
� Mantém o tamanho total dos arquivos usados dentro de uma faixa
máxima alocada previamente pelo administrador de cada peer.
Na rede Freenet, ainda não está implementado um mecanismo de busca
idêntico ao que se está acostumado a usar nas redes de compartilhamento de
arquivos. Um dos principais objetivos da rede Freenet é tornar impossível a
localização exata de alguma informação. Nem mesmo um operador do peer
é capaz de determinar o conteúdo dos arquivos de seu próprio nó, pois todo o
conteúdo é guardado de maneira criptografada. Tais características tornam a
busca muito difícil.
A identificação de cada arquivo é feita a partir de uma chave binária
gerada a partir de uma função hash SHA-1. Existem três tipos de chaves na
rede Freenet:
52
� Keyword-Signed Key (KSK)
� Signed-Subspace Key (SSK)
� Content-Hash Key (CHK).
A KSK é a chave gerada a partir de uma descrição em formato texto
definido por um usuário. Por exemplo, caso a descrição de um arquivo seja a
cadeia de caracteres “/movie/Lord.of.the.Ring”, esta string é utilizada para
gerar um par de chaves, uma chave publica e outra privada. A chave pública é
utilizada na localização do arquivo. A chave privada é utilizada no mecanismo
de autenticação e integridade da arquitetura Freenet, pois existe uma
assinatura no arquivo que é feita com esta chave privada e quando este
arquivo for recuperado da rede, um teste de integridade e autenticidade é
feito.
Como uma descrição idêntica pode ser colocada em arquivos totalmente
distintos, deve-se ter um mecanismo que diferencie arquivos distintos com a
mesma descrição. Isto é feito com a chave SSK, que cria um contexto para
cada arquivo. Portanto, arquivos diferentes pertenceriam a contextos
diferentes e desta maneira se sabe que os arquivos não são iguais.
O terceiro tipo de chave – CHK - relaciona-se ao conteúdo do arquivo.
Esta chave é utilizada para dividir um arquivo em diversas partes, otimizando
assim a disponibilidade. Atribui-se as diversas partes de um arquivo para uma
mesma chave CHK, ou seja, as partes pertencem ao mesmo arquivo. O
mecanismo completo do funcionamento das chaves na rede Freenet é
estudado em [40].
Em cada pedido de arquivo, associa-se um número de Hops-To-Live
(HTL, similar ao TTL do protocolo IP) que é um mecanismo de controle para
que as mensagens não fiquem viajando pela rede por tempo indeterminado.
Para cada pedido, também se tem um identificador, pois se um pedido já foi
respondido anteriormente por um peer, ele não o responderá novamente,
protegendo a rede contra o problema de laços (loops). Quando um peer recebe
53
uma mensagem, ele encaminha para algum de seus vizinhos, e aguarda a
resposta (sucesso ou falha). Caso seja um sucesso, ele retorna ao peer que
iniciou o pedido o caminho completo de onde está o arquivo procurado. No
caso de o vizinho retornar uma falha, o peer envia a solicitação para outro de
seus vizinhos.
F I G U R A 2 6 - F U N C I O N A M E N T O D A R E D E F R E E N E T
Por exemplo, na Figura 26, o peer A inicia o pedido à um de seus
vizinhos (no caso, ele só contém um vizinho que é o peer B). Quando o peer B
recebe o pedido, ele manda o pedido à um de seus vizinhos (neste caso, para
o peer C). Como o peer C não contém o objeto requisitado, ele responde a
solicitação com um código de falha. O peer B envia a solicitação para outro de
seus vizinhos (peer E).
O peer E por sua vez, envia a solicitação para um de seus vizinhos (peer
F), que por sua vez envia a solicitação para seu vizinho peer B. Neste
momento, o peer B detecta que houve um loop, e responde a solicitação com
uma mensagem de falha para o peer F, que em seguida encaminha a
mensagem de volta ao peer E.
Finalmente, o peer E envia a solicitação para seu outro vizinho, peer D,
54
que contém o objeto desejado. O peer D responde ao peer E informando que
ele contém o objeto. Neste momento, o peer E responde ao peer B informando
que para chegar ao objeto procurado, ele deve seguir o caminho para os peers
E-D. Finalmente o peer B responde a solicitação do peer A informando que
para ele chegar ao objeto desejado ele deve seguir o caminho para os peers B-
E-D.
Para que um novo peer seja adicionado à rede, a única informação que
ele precisa ter é quem são seus vizinhos, pois todas as solicitações são
enviadas para eles. Quando se instala o programa cliente Freenet, ele faz o
download do arquivo seednodes.ref que contém diversos peers que
pertencem a rede.
A conexão na rede é extremamente lenta, mas como o próprio
desenvolvedor disse: “Freenet está preocupada em primeiro plano com o
anonimato e segurança, em segundo lugar está a performance” [41]. A
cada consulta, os peers mantêm os dados em sua memória cache, o que pode
melhorar a performance de consultas. Quando a memória cache está cheia,
substituem-se os objetos mais antigos (LRU – Least Recently Used). Na Figura
27, tem-se uma imagem da interface do usuário.
F I G U R A 2 7 - I N T E R F A C E D O C L I E N T E F R E E N E T
55
Algumas questões polêmicas surgem na rede Freenet, por exemplo, por
não existir um filtro, a rede permite:
� Conteúdo pornográfico de crianças
� Material usado por terroristas
A justificativa da rede é que a liberdade de expressão é total, portanto
não se deve barrar nenhum conteúdo. Esta filosofia está baseada que para
usar este serviço, o usuário deve ser a favor da liberdade da expressão,
portanto deve tolerar um discurso ou até mesmo arquivos cujo conteúdo ele
julga ser errado, por exemplo, pornografia infantil. Se o usuário não consegue
aceitar essa situação, ele não deve usar a rede Freenet, pois como todo o
conteúdo dos arquivos são criptografado e não se tem o controle de onde cada
arquivo está, pode ser que os arquivos com pornografia infantil estejam na
máquina deste usuário.
5 . 2 . G N U T E L L A 2
O protocolo conhecido como Gnutella² [42] foi desenvolvido por Michael
Stokes em 2002 baseado no procotolo Gnutella¹. O protocolo Gnutella² é
formado pela Rede Gnutella² e o Padrão Gnutella².
A rede Gnutella² é uma nova arquitetura de rede P2P de alta
performance que suporta uma variedade de aplicações distribuídas, dentre
elas, aplicações de compartilhamento de arquivos e aplicações de
comunicações.
Já o padrão Gnutella² é um conjunto de requisitos que devem ser
atendidos para que a construção de aplicações nesta rede seja possível. Este
padrão especifica as mínimas funcionalidades para que uma aplicação seja
compatível com a rede Gnutella², garantindo que o conjunto de serviços
56
básicos seja oferecido aos participantes da rede.
Os conceitos da rede Gnutella² baseiam-se em:
� Um novo protocolo.
� Uma nova arquitetura de transporte de dados.
� Serviços básicos que devem ser implementados, incluindo o serviço de
localização.
� A implementação de um padrão.
Na arquitetura original do Gnutella¹ (já estudada no Capítulo 3),
qualquer tipo de pesquisa tem um custo relativamente fixo e ocorre em uma
faixa de tempo relativamente fixa. Isso se deve ao fato do parâmetro TTL, pois
na prática é muito difícil percorrer grande parte da rede já que os valores de
TTL são geralmente baixos, e isso não dá oportunidade para se encontrar
arquivos raros na rede, que estejam distantes do peer que inicia a pesquisa.
A arquitetura Gnutella² apostou nas seguintes características:
� Deve-se garantir que se um objeto existe, ele pode ser encontrado.
� Existe um mecanismo capaz de identificar objetos que sejam raros, com
baixo custo para a rede.
� Em uma situação onde os recursos sejam limitados, prefere-se que seja
encontrada pelo menos uma instância de um objeto raro, do que todas
as instâncias de um objeto comum.
Ou seja, a principal diferença da abordagem da arquitetura Gnutella² para
sua versão anterior é o fato de se colocar o foco principal nos arquivos que
sejam raros na rede, já que eles serão os causadores da maioria dos
problemas enfrentados nas consultas.
Os projetistas da rede Gnutella² observaram que as consultas melhoram se
forem feitos a partir de mecanismos iterativos, e não mecanismos recursivos
57
como é o caso da Gnutella¹. Quando um peer deseja realizar uma pesquisa na
rede Gnutella², ele se comunica com cada peer até que todos os peers tenham
sido contatados ou quando se obtém o objeto procurado (esquema
iterativo). Acredita-se que o mecanismo de busca de Tabelas Hash
Distribuídas (DHT) será incorporado ao sistema no futuro para melhorar a
performance da busca. [43]
A solução usada pela arquitetura foi organizar os peers em dois níveis de
hierarquia: peers de alta capacidade (high capacity) e peers de baixa
capacidade (low capacity). Peers de alta capacidade são geralmente
chamados de SuperNós ou Ultrapeers, mas neste ambiente optou-se pelo
termo “Hubs”. Os peers de baixa capacidade são denominados de Folhas
(Leaves) e estão atrelados a algum Hub [44]. A topologia virtual de uma rede
Gnutella² é mostrada na Figura 28:
F I G U R A 2 8 - T O P O L O G I A G N U T E L L A ²
As funções de um Hub são as seguintes:
� Devem responder eficientemente as requisições de suas folhas
(peers que estão conectados ao Hub).
� Somente os Hubs precisam participar da consulta iterativa peer a peer,
deixando suas folhas livres deste processo.
� O contato com um peer que pertença ao conjunto de folhas de um Hub é
feito através do próprio Hub. Desta forma, aproveita-se a largura de
58
banda e aumenta a probabilidade de acerto em uma consulta.
� A troca de mensagem entre Hubs ocorre de uma forma mais controlada,
evitando tempestades de mensagens e congestionamento na rede.
É interessante notar que a idéia de agrupar um conjunto de nós abaixo de
um Hub não é uma idéia nova, utilizada, por exemplo, na topologia estrela na
Ethernet. O modelo centralizado (discutido no Capítulo 3) nada mais é do que
uma estrutura em que só existe um Hub (denominado servidor) para toda a
rede. Já o esquema onde existem diversos Hubs ou Supernós é denominado de
arquitetura híbrida, pois não é totalmente centralizada, nem totalmente
descentralizada.
O problema que surge agora é: Qual a quantidade ideal de Hubs em uma
arquitetura híbrida? Se o número de Hubs for pequeno, aumenta-se a
quantidade de folhas em cada Hub, e a pesquisa em um Hub tem uma grande
probabilidade de encontrar um peer que contenha o arquivo desejado, embora
seja exigido um alto poder de processamento dos Hubs. Já no caso de
existirem muitos Hubs, a densidade de folhas em cada Hub diminui e a
probabilidade de acertos em uma pesquisa é reduzida, acarretando um
aumento de mensagens. O mundo Gnutella está no segundo caso, e deve
haver um mecanismo para tratar essa desvantagem.
O protocolo Gnutella² resolve esse problema de existirem muitos Hubs de
duas maneiras:
5 . 2 . 1 . C O M U N I C A Ç Ã O H U B - F O L H A O T I M I Z A D A
A capacidade de performance do próprio hub é o fator que limita o número
de folhas que ele pode suportar. Características como a velocidade da CPU e a
largura de banda disponível para o hub são custos fixos, e a única maneira de
contorná-los é escolhendo um outro hub com melhor performance.
O tráfego entre as folhas e seu hub pode ser diminuído com um mecanismo
59
de compressão de dados. O algoritmo de compressão de tráfego entre o hub e
suas folhas é o Deflate Algorithm[45]. Isto consome o processamento e a
memória do hub devido ao overhead introduzido pelo algoritmo, mas é
compensado pela redução no consumo de largura de banda do link. Isto ajuda
a aumentar a média de folhas por hub da arquitetura Gnutella², reduzindo o
custo e o tempo das pesquisas de uma maneira geral.
5 . 2 . 2 . C O M U N I C A Ç Ã O H U B - H U B O T I M I Z A D A
Assumindo que o número total de hubs não pode ser reduzido, existe uma
maneira de reduzir o custo total de contatar cada hub, e dessa forma pode-se
reduzir o custo de comunicação entre hubs.
Quando um hub recebe uma solicitação de pesquisa, ele além de processar
a pesquisa de forma local (consultando suas folhas) também envia a
solicitação para seus hubs vizinhos. Tais vizinhos consultam suas folhas, mas
não encaminham a solicitação.
Este conceito significa que pelo custo de enviar uma solicitação para um
hub, um conjunto de hubs serão pesquisados. Por exemplo, se um hub contém
cinco vizinhos, uma pesquisa nesse hub será realizada em seis hubs e em suas
respectivas folhas de forma paralela, pois cada hub processa a solicitação.
Dessa forma, quanto maior for o número de vizinhos, maior o conjunto de
hubs que serão pesquisados em paralelos. A solicitação é feita através de
segmentos UDP para o primeiro hub e é encaminhada através de segmentos
TCP para seus vizinhos, Figura 29. Para continuar a pesquisar em outros hubs,
novas solicitações deverão ser feitas.
60
F I G U R A 2 9 - C O M U N I C A Ç Ã O H U B - H U B ( G N U T E L L A ² )
5 . 3 . F A S T T R A C K / K A Z Z A
A rede Kazaa[46] tem em média três milhões de usuários ativos,
compartilhando cerca de cinco Terabytes (1024 Gigabytes) de espaço em
disco. Por ser uma rede amplamente utilizada e difundida, o conhecimento do
protocolo, de sua arquitetura e dos seus mecanismos de sinalizações de
tráfego é de fundamental importância para a comunidade de pesquisa das
redes P2P. A maior dificuldade se deve ao fato de se tratar de um protocolo
proprietário com mecanismos de criptografia, em que a documentação e o
entendimento do seu funcionamento são bastante vagos.
A rede Kazaa é responsável por grande quantidade do tráfego gerado hoje
na internet. Para que os engenheiros de rede (responsáveis pelo
dimensionamento da rede) possam introduzir dispositivos que otimizem a
utilização da largura de banda, eles precisam entender o funcionamento desta
arquitetura. [47]
A rede Kazaa lembra o funcionamento da rede Gnutella em relação ao fato
de ambas funcionarem sem a existência de um servidor central para oferecer o
serviço de localização. Entretanto, a principal característica que diferencia da
Gnutella é o fato de nem todos os peers da rede Kazaa desempenharem o
mesmo papel. Existe o conceito de Super-Nó (SN) e o conceito de Nó-Comum
Peer
UDP
Peer Vizinho
Vizinho
Vizinho Vizinho
TCP TCP
TCP
TCP
61
(em inglês: Ordinary-Node ou ON). Os nós mais poderosos (em relação a
processamento e largura de banda) são promovidos a SN, e cada SN tem
vários ONs sob sua responsabilidade. A Figura 30 representa os componentes
da rede Kazaa.
F I G U R A 3 0 - C O M P O N E N T E S D A R E D E K A Z A A
Quando um ON executa a aplicação para entrar na rede Kazaa, ele
estabelece uma conexão TCP com um SN e em seguida atualiza o SN sobre
quais dados ele está compartilhando (chamados de meta-dados por se tratar
de informações sobre dados). Este mecanismo permite que o SN possa manter
informações sobre todos os arquivos que os ONs ligados a ele estão
compartilhando e o endereço IP de cada ON. Neste sentido, cada SN se torna
um miniservidor que lembra a rede Napster. Esse tipo de arquitetura é
híbrida, pois incorpora características da rede centralizadas (Napster) e
descentralizadas (Gnutella).
Uma importante característica explorarada pela rede Kazaa é a
heterogeneidade dos peers. Algumas diferenças entre os peers são:
� Permanência da conexão com a rede (up time)
� Largura de banda (velocidade da conexão)
� Poder de processamento
62
� Possuírem IPs públicos (alcançados na internet) ou privados (utilizando
NAT[48])
A melhor maneira de explorar tal heterogeneidade é agrupar os peers em
duas ou mais hierarquias, de forma que os peers das hierarquias mais altas
devam preencher requisitos como: permanecer mais tempo conectado ao
sistema, ter maior largura de banda e poder de processamento e não
utilizarem NAT. A Figura 31 ilustra o conceito de NAT ou Firewall.
F I G U R A 3 1 - C O N E X Ã O C O M O N A T O U F I R E W A L L
Para cada arquivo que o ON está compartilhando, o meta-dado sobre esse
arquivo inclui: nome do arquivo, tamanho do arquivo, descrição sobre o
arquivo, que são usados nas buscas. O arquivo também inclui uma assinatura
para identificá-lo, denominado ContentHash. Se um download falhar, o
campo ContentHash permite que o usuário possa procurar automaticamente
pelo mesmo arquivo na rede (arquivos idênticos possuem ContentHash
idênticos). [49]
Um peer da rede Kazaa deve ter os seguintes componentes:
� Um software de interface para o usuário (KMD – Kazaa Media
Desktop[46]).
63
� Informações de configuração do software colocadas no Registro do
Windows.
� Arquivos DBB (arquivos que o usuário deseja compartilhar na rede).
� Arquivos DAT (arquivos parciais que estão em processo de download,
quando o download termina estes arquivos são renomeados para seus
nomes originais).
Quando um usuário deseja localizar um arquivo para fazer download, o peer
ON envia uma solicitação através da conexão TCP para o peer SN. Para cada
registro encontrado no banco de dados, o SN envia meta-dados sobre o
arquivo solicitado e também o endereço IP do peer que o contém.
Os peers da rede Kazaa geralmente trocam entre si as listas de Super-Nós
disponíveis no sistema. Com este mecanismo de atualização, tenta-se garantir
que os peers sempre tenham SNs ativos e funcionais em suas listas. Os peers
também são capazes de enviar mensagens de textos uns para os outros
(Instant Messaging), e isto é feito com a codificação Base64 [50].
Na Figura 32, demonstra-se o mecanismo de estabelecimento de conexão
entre ON-SN e entre SN-SN.
64
F I G U R A 3 2 - E S T A B E L E C I M E N T O D A C O N E X Ã O
Em relação à conexão ON-SN, inicialmente o ON verifica se consegue
alcançar o SN através de uma mensagem UDP Probe (esperando receber uma
mensagem UDP Response). Em seguida, a conexão TCP é estabelecida através
do triplo-handshake [51]. Quando a conexão é estabelecida, há uma troca de
chaves e a partir de então todas as mensagens são enviadas com criptografia.
Depois do estabelecimento do canal seguro, são enviados os meta-dados dos
arquivos que o ON está compartilhando. Finalmente, o ON recebe uma lista
atualizada de SNs ativos e funcionais da rede P2P.
Já em relação à conexão SN-SN, estabelece-se a conexão TCP, e em
seguida, tem-se a troca de chaves para estabelecer um canal seguro de
comunicação. Os SNs trocam informações sobre a rede.
A maneira como ocorre o processo de seleção de vizinhos dos ONs e SNs
deve levar em consideração alguns pontos:
65
� A carga existente em um Super-Nó: Os ONs e SNs dão prioridade
para selecionar os nós que estão com menor carga (workload).
� Localização: o conceito de localização é usado como parâmetro na
formação da topologia da rede, preferindo nós que estejam mais
perto uns dos outros. Isto geralmente é feito de duas maneiras: através
do tempo de viagem de um pacote PING (RTT – round-trip time) ou por
meio de prefixos IPs, pois hosts que contém prefixos próximos tem
maior chances de estarem fisicamente mais próximos (embora isto nem
sempre seja verdadeiro).
Durante o processo de solicitação de arquivo, um ON pode fazer a
solicitação ao SN que ele está conectado, e depois de receber a resposta,
desconectar deste e imediatamente conectar a outro SN para fazer a mesma
solicitação e receber diversas fontes para sua pesquisa. Portanto, um ON pode
passar por diversos SNs durante uma única pesquisa de maneira transparente
para o usuário. O Kazaa-Lite[52] é um exemplo de aplicação que funciona
com este mecanismo.
5 . 4 . B I T T O R R E N T
Criado por Bram Cohen, o BitTorrent[53] é uma tecnologia que permite o
compartilhamento de qualquer tipo de arquivo pela internet. O funcionamento
do BitTorrent é baseado em um servidor de página web (webserver) e um
arquivo .torrent que é colocado neste servidor. O .torrent contém diversas
informações sobre o arquivo, dentre elas: o tamanho do arquivo, nome do
arquivo e a URL do tracker (direcionador de downloads).
O tracker é o servidor responsável por organizar os arquivos disponíveis e
direcionar os downloads para os peers que possuem o arquivo. Um tracker
pode conter informações sobre diversos arquivos .torrent. Para cada arquivo,
ele contém um conjunto de peers de onde os arquivos podem ser baixados,
distinguindo-os de seeds (arquivos completos) e leechs (arquivos
incompletos).
66
Um peer que contenha o arquivo completo é denominado de seed e esse
pode ser usado como uma fonte para o compartilhamento. Os peers que
estejam baixando um arquivo, mas esse ainda não está completo, são
chamados de leech. O conjunto de todos os peers que fazem parte do
processo de compartilhamento do arquivo é denominado de swarm (seeds +
leechs). Por exemplo, se o arquivo hello_world.pdf estiver sendo
compartilhado por 2 seeds e estiver sendo baixado por 8 peers (leechs), o
swarm do arquivo é composto por 10 peers (2 seeds e 8 leechs). Na Figura 33
estão os componentes do sistema BitTorrent:
F I G U R A 3 3 - C O M P O N E N T E S D O B I T T O R R E N T
A responsabilidade do tracker se resume a ajudar o estabelecimento da
conexão de um peer com outro. Ele é a única fonte por onde um peer pode
descobrir outro peer que tenha o arquivo que ele deseja. O arquivo .torrent
contém a informação do tracker, e o tracker contém uma lista de peer que
podem ser usados para fazer o download do arquivo. Na Figura 34 está
ilustrado a conexão de um peer que deseja iniciar o download do torrent. Após
localizar o arquivo em um servidor de páginas, ele recolhe informações sobre o
tracker responsável por este arquivo, e conecta-se com ele.
67
F I G U R A 3 4 - I N F O R M A Ç Õ E S S O B R E O A R Q U I V O . T O R R E N T
Depois que o peer se conecta com o tracker, ele recebe o conjunto de peers
que serão usados como fontes para fazer o download do arquivo. O peer se
conecta aos peers e tenta receber o maior número de blocos que ele
conseguir. É sempre útil ter várias solicitações pendentes ao mesmo tempo,
para evitar um atraso e tentar maximizar a taxa de transferência.
Nas versões mais novas do BitTorrent, eliminou-se a necessidade do
Tracker, pois o programa cliente (denominados trackerless) já implementa as
funcionalidades do tracker explicadas anteriormente, e isso faz com que cada
cliente seja um mini-tracker . Os clientes utilizam um protocolo baseado em
DHT para prover os serviços de localização de um torrent. Isto torna o
BitTorrent um tipo de rede descentralizada. [53]
F I G U R A 3 5 - T R A N S F E R Ê N C I A D E A R Q U I V O S
Os peers começam a receber alguns blocos, e algumas estratégias surgem
em relação a qual a melhor abordagem para minimizar o tempo de download.
68
O sistema BitTorrent usa os seguintes critérios [54]:
� Prioridade Estrita (Strict Priority): esta política determina que se a
solicitação de download de um bloco foi feita, deve-se solicitar e concluir
o download de todos os pedaços deste bloco, antes de iniciar o download
de um novo bloco do arquivo.
� Primeiro o mais Raro (Rarest First): na maior parte do tempo, tenta-
se fazer logo o download dos blocos mais raros do sistema, aumentando
o número de fontes para este bloco (tornando-o gradativamente mais
popular). É provável que blocos raros não vão estar disponíveis por
muito tempo.
� Primeiro bloco deve ser Randômico (Random First Piece): uma
exceção à política de fazer o download do bloco mais raro é quando se
trata do primeiro bloco, pois quando se inicia o download, o sistema usa
uma escolha randômica de qual bloco deve fazer o download, e depois
que o bloco inteiro tenha sido baixado, troca-se para a política do mais
raro.
� Modo de finalização (Endgame Mode): um peer que está próximo de
completar totalmente o download do arquivo envia solicitações para
todos os peers que ele está conectado (todo o conjunto de fontes que ele
contém) pedindo os pedaços dos blocos que ainda estão faltando, e este
peer terá prioridade de atendimento.
5 . 5 . E M U L E / E D O N K E Y 2 0 0 0 / O V E R N E T
eDonkey[55] é a rede dos aplicativos: eDonkey2000[55],
eDonkey/Overnet[56] e eMule[57].
A rede eDonkey, criada pela empresa alemã MetaMachine em 2000,
ultrapassa o limite dos Terabytes. "Donkey ou Mule" (em português, burro,
69
mula ou jegue) é usado para designar arquivos muito grandes e difíceis de se
obter na Internet. Baseia-se em servidores centrais que servem ao usuário
pesquisas e indexação de arquivos (arquitetura híbrida). Atualmente, qualquer
usuário está apto a criar o seu próprio servidor, pois o software servidor foi
distribuído pela empresa que o desenvolveu. Essa rede se destaca das demais
pela quantidade de arquivos de vídeo que elas contêm. A maior parte dos
arquivos disponíveis é de boa qualidade. Isso se deve ao fato de que cada
arquivo armazenado no sistema possui um código hash que o identifica
unicamente.
Já o Overnet foi considerado a evolução e a 2ª geração do eDonkey. A rede
Overnet é uma espécie de eDonkey "paga": é preciso comprar o software. A
diferença é que o Overnet é altamente descentralizada (não possui nenhum
servidor) e muito mais rápida. Overnet resolve os problemas de servidores
centralizados do eDonkey da seguinte maneira: ele publica as informações e
efetua as buscas de uma maneira completamente descentralizada, usando um
modelo DHT. Ambos (eDonkey2000 e Overnet) usam o mesmo protocolo para
transferência rápida de arquivos, o Multisource FTP (MFTP) [59]. A tendência é
que os usuários do eDonkey2000 migrem para a rede Overnet. Atualmente a
MetaMachine fundiu o Overnet com a rede tradicional eDonkey num só
programa com a finalidade de aumentar as fontes.
Em 2002, um usuário que estava descontente com o cliente eDonkey2000
resolveu que iria tentar fazer um cliente melhor, e assim o fez. Juntou consigo
outros programadores e assim nasceu o projeto eMule. Adicionaram novas
capacidades e um aspecto gráfico mais agradável ao cliente da rede eDonkey.
Até hoje, o eMule é um dos maiores e mais confiáveis clientes peer-to-peer em
todo o mundo. Graças à sua orientação open-source muitos programadores
contribuem para o projeto, tornando a rede mais eficiente com cada novo
lançamento. Os criadores do eMule criaram uma nova rede de características
idênticas à Overnet a que deram o nome de Kadmila, suportada nas versões
mais recentes do software eMule.
70
O eMule é um programa de código aberto lançado sob a GNU (General
Public License) [13] e foi feito para a plataforma Microsoft Windows. Os
diferenciais do eMule são: rápida recuperação de downloads corrompidos e o
uso de um sistema de créditos para premiar os usuários que fazem mais
uploads. Além disso, o eMule transmite os dados de forma compactada (com
Zlib[60]) para gastar menos banda passante.
Outra característica do eMule é a habilidade de aceitar links "ed2k" de um
navegador e começar a baixar o(s) arquivo(s) a que o link se refere.
Versões recentes do eMule tem suas próprias implementações da rede
Kademlia, que não utiliza servidores centrais como faz a rede eDonkey, em
que cada usuário é um "nó" na rede. Foram também adicionadas às novas
versões a "Busca Unicode" (que permite achar arquivos em várias línguas).
As versões para Linux são o eMule, xMule e aMule e todas são na versão
para Windows. [60]
Apresentamos neste capítulo as redes não estruturadas baseadas em
buscas descentralizadas. Estas não possuem um servidor centralizado e alguns
de seus exemplos são as redes FreeNet[39], Gnutella2[42], FastTrack/
Kazaa[46], BitTorrent Trackerless[53], eDonkey2000[55]/Overnet[56]/
eMule[57].
Abaixo, a Tabela 3 ilustra as características entre as arquiteturas:
71
Redes P2P Não Estruturadas e Descentralizadas X Freenet Gnutella 2 Kazaa Bit Torrent Emule
Arquitetura
Rede P2P formada por um conjunto de
peers que armazenam e
recuperam dados de forma anônima
através da atribuição de chaves.
Formado pela Rede Gnutella²
e o Padrão Gnutella². A
rede Gnutella² suporta uma variedade de aplicações
distribuídas Já o padrão
Gnutella² é um conjunto de
requisitos que devem ser atendidos. Arquitetura
Híbrida
Arquitetura do Kazaa é do tipo
híbrida, pois incorpora
características da rede
centralizadas (Napster) e
descentralizadas (Gnutella).
Nas primeiras versões, o
BitTorrent tinha a característica de ser centralizado pois dependia do
Tracker. Nas versões mais
novas do BitTorrent,
eliminou-se a necessidade do Tracker, pois o
programa cliente já implementa as
funcionalidades do tracker.
Versões recentes do
eMule tem suas próprias
implementações da rede
Kademlia, que não utiliza servidores
centrais como faz a rede eDonkey.
Arquitetura híbrida.
Mecanismo de
Localização
A localização é feita a partir de três
chaves em formato de string: KSK
(chave gerada a partir de uma
descrição em formato texto), SSK (cria um contexto para cada
arquivo, para difenrenciar arquivos
com descrições identicas) e CHK
(utilizada para dividir um arquivo em diversas partes)
Mecanismos iterativos de
busca. Quando um peer deseja
realizar uma pesquisa na
rede Gnutella², ele se
comunica com cada peer até que todos os peers tenham
sido contatados ou quando se
obtém o objeto procurado (esquema iterativo).
Para localizar um arquivo na
rede, o peer ON envia uma
solicitação para o peer SN. Para
cada registro encontrado, o
SN envia informações
sobre o arquivo solicitado e também o
endereço IP de quem o contém.
Utiliza o tracker para organizar os
arquivos disponíveis e direcionar os
downloads para os peers que possuem o arquivo. Um tracker pode
conter informações sobre diversos
arquivos .torrent. Para cada arquivo,
ele contém um conjunto de peers
de onde os arquivos podem
ser baixados.
Os super-nós fornecem o
mecanismo de localização de
arquivo para os outros peers.
Após encontrar os arquivos que desejam baixar,
os peers se comunicam uns com os outros e a transferência é
iniciada.
Confiabilidade e Tolerância à
Falhas
Não existe um ponto único de falha, e não há hierarquia entre os peers. Em cada pedido, associa-se
um número de Hops-To-Live, mecanismo
de controle de mensagens. Se um
pedido já foi respondido
anteriormente, ele não o responderá
novamente.
Coloca-se o foco principal nos arquivos
que sejam raros na rede, já que eles serão os
causadores da maioria dos problemas
enfrentados nas consultas.
Dessa forma, tenta-se prover
uma maior tolerância à
falha.
Para encontrar mais fontes, um ON pode fazer a
solicitação ao SN, desconectar
deste e imediatamente
conectar a outro SN para fazer a
mesma solicitação. Da mesma forma,
se um SN falhar, o ON se conecta
a outro SN.
Implementa as seguintes políticas para aumentar a confiabilidade do
sistema: Prioridade Estrita; Primeiro o mais Raro e Modo de
finalização
Conectar-se com outro super-nó
fornece o mecanismo para buscar e outras áreas da rede.
T A B E L A 3 - C O M P A R A Ç Ã O E N T R E A S R E D E S P 2 P E S T R U T U R A D A S E D E S C E N T R A L I Z A D A S
72
6 . N O V A S T E C N O L O G I A S E M R E D E S
P 2 P
Até agora, esse trabalho analisou as diversas arquiteturas existente em
redes P2P. Viu-se que essas arquiteturas são escaláveis, onde todos os
participantes do sistema são denominados peers e se comunicam em um
ambiente não confiável de maneira distribuída.
Denominamos por novas tecnologias, as redes overlay de voz sobre ip
(Tecnologia VoIP) que estão se popularizando na Internet.
A maioria dos programas de Telefonia na Internet (Telefonia IP)
utilizam arquiteturas baseadas nas recomendações do IETF SIP (Session
Initiation Protocol) [61] ou ITU-T H.323 [62]. Estes padrões são
incompatíveis um com o outro, e diversos programas para integrá-los
(gateways SIP/H.323) estão em desenvolvimento. Dentre os softwares que
integram os protocolos SIP/H.323 existe uma plataforma que está obtendo
bastante destaque: Asterisk [64]. Tem como principais características:
• Gateway VoIP Heterogêneo (MGCP, SIP, IAX, H.323)
• PABX
• Servidor de Audioconferência
O principal problema das plataformas de Telefonia IP é que elas dependem
da arquitetura cliente-servidor, pois os servidores são utilizados para registrar
os usuários e fornecer os serviços de localização. Neste modelo, quando um
usuário inicia seu aplicativo, ele registra o seu endereço IP no servidor para
que outros usuários consigam conectar-se a ele. A escalabilidade e a
confiabilidade nestes sistemas são fornecidas utilizando abordagens
tradicionais de links duplicados (redundância) e servidores primários e
73
secundários (tolerância no caso de falhas). Os sistemas necessitam de uma
configuração inicial nos servidores para o serviço de telefonia comece a
funcionar. Há também uma necessidade constante de manutenção em tais
servidores, pois neste modelo existe um ponto único de falha (se os servidores
deixarem de funcionar, o serviço não pode ser utilizado por nenhum usuário).
6 . 1 . T E L E F O N I A N A I N T E R N E T V E R S U S
C O M P A R T I L H A M E N T O D E A R Q U I V O S
Para estudar um modelo de telefonia IP baseado em Redes P2P, inicia-se
uma comparação entre os requisitos de um aplicativo de telefonia na internet,
e dos requisitos dos aplicativos estudados anteriormente, referentes ao
compartilhamento de arquivos.
Uma comparação entre algumas características é feita na Tabela 4, e em
seguida, alguns pontos são discutidos.
x Telefonia na Internet Compartilhamento
de Arquivos
Armazenamento
do conteúdo Não Sim
Caching Não Sim
Sensível a demora Sim Não
Confiabilidade Tolerância à falhas Arquivos redundantes
T A B E L A 4 – T E L E F O N I A N A I N T E R N E T X C O M P A R T I L H A M E N T O
D E A R Q U I V O S
Nos sistemas de telefonia, o armazenamento de conteúdo não é um fator
importante. Um peer nesse sistema pode receber muito mais conexões do que
um peer em um sistema de compartilhamento de arquivos, pois os dados de
voz são menores.
74
A técnica de armazenar endereços utilizados recentemente (caching) não é
de grande utilidade, pois os peers que utilizam o sistema de voz tendem a ser
móveis e permanecerem conectados por menos tempo quando comparados
aos sistemas de compartilhamento de arquivos. Quando o peer entra
novamente na rede, é muito provável que ele esteja com um novo endereço
IP, portanto de nada adianta ter o antigo endereço IP guardado com a técnica
de caching.
Outra característica importante que deve ser observada é o fato do sistema
de voz ser altamente sensível à latência.
Finalmente, em ambos os sistemas deve haver mecanismos de
confiabilidade, mas a abordagem é diferente. Nas aplicações de
compartilhamento de arquivos, existem diversas cópias dos arquivos, portanto,
para receber o arquivo, basta encontrar qualquer cópia deste arquivo. Já no
sistema de telefonia, desejando-se falar com uma pessoa, só existe uma cópia
desta pessoa na rede, portanto a confiabilidade deve ser fornecida para que o
peer em que ela está tenha mecanismos de tolerância à falha.
6 . 2 . M O D E L O S D E T E L E F O N I A C E N T R A L I Z A D O S
6 . 2 . 1 . S I P
O Session Initiation Protocol (SIP) é um protocolo desenvolvido pelo
Internet Engineering Task Force (IETF) para tratar com problemas
referentes ao modo de iniciar, modificar ou terminar sessões ou chamadas
multimídia entre usuários. Dentre suas funcionalidades, tem-se a localização
de usuários, o estabelecimento de chamadas, o suporte a unicast ou multicast,
administração na participação de chamadas (transferências, conferência, entre
outros) e possibilidade de participação de um usuário em terminal H.323, via
gateway SIP/H.323. É um protocolo com abordagem cliente-servidor, onde o
cliente realiza chamadas que são atendidas pelo servidor.
O protocolo SIP é baseado no HTTP, portanto, suporta o transporte de
75
qualquer tipo de carga em seus pacotes, pelo uso de MimeTypes (Multipurpose
Internet Mail Extensions).
As principais características do protocolo SIP são:
• Conversão de nomes e localização de usuários: Mapeamento
entre nomes e endereços, tais como nomes de um domínio e o nome
de um usuário em servidor. Isto é necessário para que um
determinado usuário, que possui um nome qualquer, possa ser
convertido em um endereço IP, de modo que possa ser localizado.
• Negociação de configuração: Permite que se definam algumas
configurações, já que muitos codecs são capazes de receber
diferentes tipos de codificações.
• Alteração de configuração: Torna possível a alteração das
informações configuradas anteriormente de maneira dinâmica.
A infra-estrutura para dar suporte ao protocolo SIP é formada por um
conjunto de componentes operando numa rede IP. Este conjunto é definido
como rede SIP. Estes componentes são apresentados na Figura 36:
76
F I G U R E 3 6 - A R Q U I T E T U R A S I P
• SIP User Agent: Cliente da arquitetura e comunicação multimídia
que interage com o usuário. Um “user agent” tem dois componentes,
um “user agent client” (UAC) e um “user agent server “(UAS). O UAC
é responsável por iniciar as chamadas enviando requisições, e o UAS
é responsável por responder às chamadas, enviando respostas. Uma
aplicação de telefonia Internet contém ambos UAC e UAS.
• SIP Proxy Server: Servidor de redirecionamento de requisições e
respostas. Faz a interconexão entre os dispositivos espalhados na
rede SIP e quando a resposta lhe é enviada, redireciona-se ao cliente
de origem.
• SIP Redirect Server: São responsáveis pela determinação do
conjunto de servidores a serem usados no caminho para completar a
chamada, provendo a interoperabilidade, caso necessário.
A arquitetura pode apresentar ainda os seguintes componentes:
77
• SIP Register Server: Servidor SIP que suporta requisições
REGISTER, usadas para registrar as informações dos usuários em
algum Servidor de Localização.
• Servidor de Localização: Possui a funcionalidade de
armazenamento e consulta de registros de usuários SIP.
6 . 2 . 2 . H . 3 2 3
Para permitir a viabilidade de aplicações como VoIP (Voz sobre IP) e
videoconferência sobre IP, outro padrão amplamente utilizado é o H.323
elaborado pelo International Telecommunication Union (ITU). O H.323 é
uma recomendação do ITU para transmissão de voz e vídeo sobre redes
TCP/IP, mais precisamente sobre aquelas redes que operem sobre Ethernet,
Fast-Ethernet, Gibabit-Ethernet e Token Ring.
Esse padrão foi aprovado em 1996 pelo grupo de estudos do ITU. Devido à
necessidade de um padrão para voz sobre IP, o H.323 foi revisado e surgiu a
versão 2, adotada em janeiro de 1998. Na versão 3, foram adicionados alguns
recursos para fornecerem conexões mais rápidas. A versão 4 teve como foco
importantes áreas como confiabilidade, escalabilidade e flexibilidade. A versão
5 desse padrão possui poucas mudanças em relação a sua versão anterior,
sendo a versão atual.
As principais características do protocolo H.323 são:
• Padrões de voz e vídeo para uma infra-estrutura existente:
Permite que os clientes possam usar aplicações sem mudar a infra-
estrutura de rede atual.
• Padrões de interoperabilidade: Existe a interoperabilidade entre
LANs e outra redes, bem como suas aplicações. Além disso, o padrão
78
é independente do tipo de enlace utilizado.
• Suporte à comunicação multicast: O padrão foi definido para que
fosse totalmente destinado a aplicações multicast, embora também
possa ser usada para tráfego unicast.
• Independente de plataforma: Qualquer aplicação H.323 pode se
comunicar com qualquer outra aplicação implementando este padrão,
não importando a plataforma em que estejam (Windows ou Linux).
Na prática, uma rede H.323 não é um novo tipo de rede, mas sim uma rede
tipicamente IP, que possui serviços especiais voltados para as comunicações
multimídia. Tais serviços especiais são implementados através dos seguintes
componentes: MCUs (Multipoint Control Unit), gatekeepers e gateways. Os
componentes da rede H.323 estão apresentados na Figura 37:
F I G U R E 3 7 - A R Q U I T E T U R A H . 3 2 3
• Terminais: Os terminais H.323 são todos os equipamentos que
podem se comunicar utilizando a pilha de protocolos do padrão.
Podem também incluir protocolos de conferência de dados,
codificadores de vídeo e suporte para MCU. Os terminais são os
pontos iniciais e finais das comunicações multimídia, geralmente
79
apresentando comunicação bidirecional. Os terminais podem ser
microcomputador ou telefones H.323, que implementam todas as
funcionalidades requerentes às aplicações de VoIP (Voz sobre IP).
Outros exemplos muito comus são as câmeras digitais que já
possuem as implementações necessárias às videoconferências.
• MCU: O MCU (Multipoint Control Unit) é um elemento utilizado para
suportar conferências entre três ou mais participantes. As
características do H.323 fazem com que o MCU seja obrigatório em
conferências com mais de dois usuários que sigam esse padrão e
utiliza protocolos orientados a conexão para o controle das
conferências.
• Gatekeeper: O Gatekeeper (GK) é um elemento H.323 que age
como um ponto central para todas as chamadas dentro do domínio
H.323. Este componente é responsável por fornecer diversos serviços
aos clientes da rede, como por exemplo, controla a sinalização da
chamada, realiza funções de negociação de capacidades e de recursos
quando uma chamada é estabelecida, traduz hosts para endereços IP,
realiza o roteamento de chamadas H.323 e faz o controle de admissão
do acesso ao domínio H.323. O domínio H.323 (também denominado
de zona H.323) é o conjunto de dispositivos finais (terminais,
Gateways e MCUs) que são gerenciados por um Gatekeeper. Os
terminais H.323 se registram nos Gatekeepers para enviar e receber
chamadas.
• Gateway: O Gateway H.323 é um elemento opcional utilizado para
compatibilizar padrões de comunicação distintos. Um exemplo de
utilização desse elemento é na interoperabilidade entre ambientes
H.323 e redes de telefonia pública (PSTN), ou quando se utiliza o
protocolo IETF SIP.
80
6 . 3 . M O D E L O D E U M A P L A T A F O R M A D E
T E L E F O N I A I P B A S E A D O E M R E D E S P 2 P
( M O D E L O D E S C E N T R A L I Z A D O )
Baseado nos diversos modelos e arquiteturas P2P (vistos nos Capítulos 3 e
4) estuda-se um modelo descentralizado para a telefonia IP. Baseado no
modelo foi proposto por K. Singh e H. Schulzrinne [64], propomos as
características que o modelo descentralizado baseado em redes P2P para
telefonia IP deve ter:
� Configuração Automática: o sistema deve ser capaz de se auto-
configurar [65]. Por exemplo, descobrir os peers vizinhos e realizar seu
registro na rede P2P.
� Peers Heterogêneos: identifica peers com capacidades diferentes. Isso
permite definir os peers que serão super-nós (SN) e nós-ordinários (ON),
conforme vimos o Kazaa (Capítulo 4).
� Busca Eficiente: o sistema deve fornecer um eficiente mecanismo de
busca baseado em DHT. Escolhemos utilizar o Chord (Capítulo 3) pela
sua eficiência e robustez.
6 . 3 . 1 . C O N F I G U R A Ç Ã O A U T O M Á T I C A
Os usuários registram-se na rede para que outros possam se comunicar
com eles. No modelo centralizado SIP (Seção 6.2.1), existe o Servidor SIP de
Registro e o Servidor SIP de Localização para fornecer o serviço de registro e
localização entre os usuários da rede.
No modelo descentralizado, quando um usuário inicia sua aplicação, o peer
determina sua Chave DHT através da função hash SHA1 e entra na rede P2P.
Por exemplo, seja o login do usuário: [email protected] e sua Chave DHT:
SHA1([email protected]) = 20, então o peer ocuparia a posição 20 no anel de
Chord da rede P2P. Ver a Figura 38.
81
F I G U R E 3 8 - M O D E L O D E S C E N T R A L I Z A D O B A S E A D O N O A N E L D E C H O R D
Quando outro usuário, por exemplo, o [email protected], quiser localizar o
[email protected], ele utiliza a mesma função hash SHA1([email protected]) para
calcular a chave (valor 20) e chama a função find(20) da arquitetura Chord. O
algoritmo do Chord encontra a chave solicitada, e então a comunicação entre
os peers pode ser estabelecida utilizando o protocolo de comunicação ponto a
ponto.
Desta forma, os peers podem entrar na rede sem nenhuma configuração e
podem se comunicar logo que ingressam.
6 . 3 . 2 . P E E R S H E T E R O G Ê N E O S
Como vimos nos modelos estudados anteriormente, os peers podem
desempenhar funções diferentes de acordo com a sua capacidade. Por
exemplo, no modelo Gnutella2 (Capítulo 5) existem peers denominados de
hubs que desempenham funções especiais, enquanto que na versão anterior
Gnutella1 (Capítulo 3) não existe nenhuma hierarquia entre os peers.
Um problema do esquema adotado pelo Gnutella1 é que nem todos os
82
peers têm a mesma capacidade de recursos. Por exemplo, um peer que utiliza
um link com baixa largura de banda e que esteja atrás de um Firewall pode
não funcionar corretamente no ambiente DHT por não ser capaz de receber
conexões, ou ainda, por não possuir recursos de processamento e memória
suficientes para manter as estruturas necessárias do processo DHT. Já um
peer com um link de alta largura de banda, alto poder de processamento e
bastante memória desempenhariam funções especiais e seriam promovidos a
Super-Nós (SN). Os peers com baixa capacidade conectam aos SNs e são
denominados Nós-Ordinários (ON), similar ao Kazaa (Capítulo 5). Ver Figura
39.
F I G U R E 3 9 - P E E R S H E T E R O G Ê N E O S ( S N E O N )
Quando um peer inicia sua conexão na rede, ele será um ON. Quando ele
detectar capacidade suficiente de processamento e memória e possuir um
endereço IP público, poderá ser promovido a SN.
6 . 3 . 3 . B U S C A E F I C I E N T E
No modelo SIP Centralizado, o servidor pode se tornar o gargalo da infra-
estrutura de comunicação, pois todas as solicitações são feitas a ele. Se só
existir um servidor na rede, ele será um ponto único de falha, pois quando ele
deixar de funcionar, todos os serviços da rede deixaram de ser prestados. Uma
melhoria que pode ser proposta é a utilização de múltiplos servidores
(redundância).
83
Estes servidores redundantes poderiam funcionar de maneira que o banco
de dados dos usuários estaria nesses servidores. Desta forma, se um servidor
deixa de funcionar, os outros servidores terão as informações necessárias para
continuar a prover o serviço de comunicação. Para isso, quando um usuário
entrar na rede, é necessário que ele se registre em todos os servidores,
conforme ilustra a Figura 40.
F I G U R E 4 0 - R E G I S T R O S E M M Ú L T I P L O S S E R V I D O R E S
A desvantagem dessa abordagem é o overhead gerado pelas mensagens de
registro de cada usuário. Manter a sincronização entre todos os servidores é
outra tarefa difícil de ser mantido, pois um usuário pode conseguir se registrar
em um servidor e ter problemas em se registrar em outro pela queda de um
link, por exemplo.
Há três maneiras como os peers estão dispostos na topologia do Anel de
Chord. Na primeira, o Anel é composto somente por servidores, como
mostrado na Figura 41. Neste esquema, cada usuário se conecta a um servidor
do Anel. Os servidores implementam o mecanismo DHT para localizar os
usuários corretos dentro do sistema distribuído. Este esquema continua sendo
do tipo Cliente-Servidor, pois o usuário precisa descobrir pelo menos um
servidor e conectar-se a ele.
84
F I G U R E 4 1 - A N E L D E C H O R D C O M P O S T O P O R S E R V I D O R E S
Na segunda, os clientes também agem como servidores e implementam um
overlay de rede P2P puro. Todos os usuários implementam o mecanismo
DHT para localizar uns aos outros na rede. Este sistema tem a desvantagens
de não utilizar a característica dos peers serem heterogêneos, conforme ilustra
a Figura 42.
F I G U R E 4 2 - A N E L D E C H O R D C O M P O S T O P E L O S U S U Á R I O S
Finalmente, na terceira topologia, os peers podem ser hierarquicamente
definidos em SN ou ON de acordo com sua capacidade de processamento e
recursos, conforme discutido no item anterior. Os peers SNs fazem parte do
anel de Chord, e os peers Nos estão ligados a algum peer SN, conforme ilustra
a Figura 43. Este esquema é chamado de Arquitetura Híbrida.
F I G U R E 4 3 - A N E L D E C H O R D C O M P O S T O P O R S N S
85
Neste capítulo, um estudo sobre redes overlay de voz sobre IP (Tecnologia
VoIP) foi desenvolvido. Apresentam-se os protocolos IETF SIP e ITU-T H.323
que são modelos que dependem da arquitetura cliente-servidor, pois os
servidores são utilizados para registrar os usuários e fornecer os serviços de
localização. Portanto, eles trazem consigo as desvantagens do modelo cliente-
servidor. Apresentamos, no fim do capitulo, as características de um modelo
descentralizado de telefonia IP deve ter, baseado em redes P2P.
86
7 . C O N C L U S Ã O
Essa monografia fez um estudo comparativo entre diversas arquiteturas
P2P existentes e outras que ainda estão em desenvolvimento (denominadas
pelo autor de Novas Tecnologias em Redes P2P). Mostramos os modelos
que deram inicio ao estudo de redes P2P. Foram apresentadas as redes
estruturadas baseadas em buscas descentralizadas, utilizando busca baseada
em DHT, e as redes não estruturadas baseadas em buscas descentralizadas.
Finalmente, um estudo sobre redes overlay de voz sobre IP (Tecnologia VoIP)
foi desenvolvido. Acreditomos que as redes VoIP, que hoje são dominadas
pelas arquiteturas Cliente-Servidor serão as próximas a adotarem os
modelos peer-to-peer (P2P). As características que esta plataforma de
telefonia IP baseado em redes P2P (modelo descentralizado) deve conter são:
Configuração Automática, Peers Heterogêneos e Busca Eficiente.
Ilustramos o funcionamento de cada uma dessas características com exemplos
práticos. Portanto, este trabalho teve por objetivo estudar as características
das principais arquiteturas de Redes P2P, fornecendo uma visão geral das
possibilidades para novas aplicações e tecnologias utilizando a abordagem P2P.
87
R E F E R Ê N C I A S
[1] MSN Messenger, disponível em http://messenger.msn.com - acesso
em 5 de janeiro de 2006.
[2] Yahoo! Messenger, disponível em http://messenger.yahoo.com -
acesso em 5 de janeiro de 2006.
[3] Grupo de Trabalho em Computação Colaborativa (GT-P2P) – RNP,
disponível em http://www.gprt.ufpe.br/gtp2p/ - acesso em 6 de janeiro de
2006.
[4] E. K. Lua, J. Crowcroft e M. Pias, University of Cambridge; R.
Sharma, N. Ang, Technological University; S. Lim, Microsoft Asia; “A Survey
And Comparison Of Peer-To-Peer Overlay Network Schemes”, IEEE
COMMUNICATIONS, The Electronic Magazine of Original Peer-Reviewed Survey
Articles, 2005.
[5] C. Ferreira, “Tutorial: Arquitetura Três Camadas”, disponível em
http://www.portaljava.com/ - acesso em 8 de janeiro de 2006.
[6] C. Kamienski, E. Souto, J. Rocha, M. Domingues, A. Callado, D.
Sadok, “Colaboração na Internet e a Tecnologia Peer-to-Peer”, XXV Congresso
da Sociedade Brasileira de Computação.
[7] W. Cirne, E. Santos, “Grids Computacionais: da Computacão de Alto
Desempenho a Serviços sob Demanda”.
[8] ATC, ENGINEERING, LANCASTER UNIVERSITY, UNIVERSITY OF
ATHENS, “Comprehensive Survey of contemporary P2P technology”, 2002.
88
[9] Napster, disponível em http://www.napster.com/ - acesso em 9 de
janeiro de 2006.
[10] Gnutella, disponível em http://www.gnutella.com/ - acesso em 9 de
janeiro de 2006.
[11] M. Xie, University of Ottawa, “P2P Systems Based on Distributed
Hash Table”, 2003
[13] The GNU Project, disponível em http://www.gnu.org/ - acesso em
10 de janeiro de 2006.
[14] V. M. Rocha, “Redes Peer 2 Peer”.
[15] The Gnutella Protocol Specification v0.4
[16] M. Harren, J. M. Hellerstein, R. Huebsch, B. T. Loo, S. Shenker, I.
Stoica, UC Berkeley, “Complex Queries in DHT-based Peer-to-Peer Networks”
[17] D. R. Karger et al., “Consistent Hashing and Random Trees:
Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”
Proc. ACM Symp. Theory of Comp, 1997
[18] S. Ratnasamy et al., “A Scalable Content Addressable Network”,
Proc. ACM SIGCOMM, 2001
[19] G. Silvestre, C. Kamienski, E. Souto, J. Rocha, M. Domingues, A.
Callado, D. Sadok, “Mini-Curso Peer-to-Peer (P2P) Computação Colaborativa
na Internet”, SBRC 2004, Gramado/RS, 2004.
[20] O. D. Sahin, D. Agrawal, A. E. Abbadi,University of California at
Santa Barbara, “Techniques for Efficient Routing and Load Balancing in
Content-Addressable Networks”.
89
[21] I. Stoica, R. Morris et al., “Chord: A Scalable Peer-to-Peer Lookup
Protocol for Internet Applications”, IEEE/ACM Trans. Net., 2003
[22] C. Tryfonopoulos, S. Idreos, M. Koubarakis, Technical University of
Crete, “Pub/Sub Functionality in IR Environments using Structured Overlay
Networks”.
[23] H. Balakrishnan, M. F. Kaashoek, D. Karger, R. Morris, I. Stoica, MIT
Laboratory for Computer Science, “Looking Up Data in P2P Systems”.
[24] R. Cox, A. Muthitacharoen, R. T. Morris, MIT Laboratory for
Computer Science, “Serving DNS using a Peer-to-Peer Lookup Service”.
[25] B. Y. Zhao et al., “Tapestry: A Resilient Global-Scale Overlay for
Service Deployment”, IEEE JSAC, 2004.
[26] C. Plaxton, R. Rajaraman, A. Richa, “Accessing Nearby Copies of
Replicated Objects in a Distributed Environment”, Proc. 9th Annual ACM Symp.
Parallel Algorithms and Architectures, 1997
[27] A. Krishnamurthy, “Tapestry & Skip Graphs”, 2003
[28] UC Berkeley Computer Science Division, The OceanStore Project,
disponível em http://oceanstore.cs.berkeley.edu/ - acesso em 15 de janeiro de
2006.
[29] J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D.
Geels, R. Gummadi, S. Rhea, H. Weatherspoon, W. Weimer, C. Wells, B. Zhao,
University of California, Berkeley, “OceanStore: An Architecture for Global-
Scale Persistent Storage”.
[30] UC Berkeley Computer Science Division, SpamWatch - A Peer-to-
90
peer Spam Filtering System, disponível em
http://www.cs.berkeley.edu/~zf/spamwatch/ - acesso em 18 de janeiro de
2006.
[31] A. Rowstron and P. Druschel, “Pastry: Scalable, Decentralized
Object Location and Routing for Large-scale Peer-to-peer Systems”, Proc.
Middleware, 2001.
[32] Computer technology research at Microsoft Corporation, disponível
em http://research.microsoft.com/ - acesso em 19 de janeiro de 2006.
[33] M. Castro, P. Druschel, A. Kermarrec, A. Rowstron, “Scribe: A large-
scale and decentralized application-level multicast infrastructure”, IEEE
JOURNAL, 2002
[34] P. Druschel, A. Rowstron, “PAST: A large-scale, persistent peer-to-
peer storage utility”
[35] S. Iyer, A. Rowstron, P. Druschel, “Squirrel: A decentralized peer-
to-peer web cache”
[36] M. Castro, P. Druschel, A. Kermarrec, A Nandi, “SplitStream: High-
Bandwidth Multicast in Cooperative Environments”
[37] A. Mislove, A. Post, C. Reis, P. Willmann, P. Druschel, D. Wallach, X.
Bonnaire, P. Sens, J. Busca, L. Bezerra, “POST: A Secure, Resilient,
Cooperative Messaging System”
[38] A. Nandi, T. Ngan, A. Singh, P Druschel, D. Wallach, “Scrivener:
Providing Incentives in Cooperative Content Distribution Systems”
[39] I. Clarke, S. Miller, T. Hong, O. Sandberg, B. Wiley, “Protecting Free
Expression Online with Freenet”
91
[40] D. Nojiri, “A Keyword Search Mechanism for Freenet”, 2003
[41] The Freenet Network Project, disponível em
http://freenet.sourceforge.net/index.php?page=faq - acesso em 28 de janeiro
de 2006.
[42] Gnutella2, disponível em http://www.gnutella2.com/ - acesso em 5
de fevereiro de 2006.
[43] M. Stokes, Shareaza, “Gnutella2 Specification Document”, 2003
[44] D. Tsoumakos, N. Roussopoulos, “Analysis and Comparison of P2P
Search Methods”, 2003
[45] Deflate file compression algorithm, disponível em
http://opensource.franz.com/deflate/ - acesso em 5 de fevereiro de 2006.
[46] Kazaa, completely distributed peer-to-peer file sharing service,
disponível em http://www.kazaa.com/ - acesso em 5 de fevereiro de 2006.
[47] J. Liang, R. Kumar, K. Ross, “The KaZaA Overlay: A Measurement
Study”, 2004
[48] K. Egevang, P.Francis, “The IP Network Address Translator (NAT)'',
RFC 1631, 1994
[49] J. Liang, R. Kumar, K. Ross, “Understanding KaZaA”
[50] H. Tschabitscher, “How Base64 Encoding Works”, disponível em
http://email.about.com/cs/standards/a/base64_encoding.htm - acesso em 8
de fevereiro de 2006.
92
[51] H. Martin, A. McGregor, J. Cleary, “Analysis of internet delay times”,
2000
[52] Kazaa Lite, disponível em http://www.oldversion.com/
program.php?n=kazaalite - acesso em 10 de fevereiro de 2006.
[53] The Official BitTorrent Home Page, disponível em
http://www.bittorrent.com/ - acesso em 15 de fevereiro de 2006.
[54] B. Cohen, “Incentives Build Robustness in BitTorrent”, 2003
[55] eDonkey2000, disponível em http://www.edonkey2000.com/ -
acesso em 15 de fevereiro de 2006.
[56] eDonkey2000 – Overnet, disponível em http://www.overnet.com/ -
acesso em 20 de fevereiro de 2006.
[57] eMule Project, disponível em http://www.emule-project.net/ -
acesso em 5 de janeiro de 2006.
[58] B. Defude, INT (Institut National des
Télécommunications), “Recherche d’informations à grande échelle dans des
architectures Peer-to-Peer”, disponível em http://etna.int-
evry.fr/~defude/P2P/P2PMontpellier.pdf - acesso em 20 de fevereiro de 2006.
[59] J. Gailly, M. Adler, “A Massively Spiffy Yet Delicately Unobtrusive
Compression Library”, disponível em http://www.zlib.net/
[60] eMule – Wikipédia, disponível em http://pt.wikipedia.org/wiki/EMule
- acesso em 22 de fevereiro de 2006.
[61] Session Initiation Protocol (SIP), disponível em
www.ietf.org/html.charters/sip-charter.html - acesso em 22 de fevereiro de
93
2006.
[62] Telecommunication Standardization Sector of ITU, “ITU-T H.323
System Implementors’ Guide”, 2005
[63] Asterisk, The Open Source PBX, disponível em
http://www.asterisk.org/ - acesso em 25 de fevereiro de 2006.
[64] K. Singh, H. Schulzrinne, “Peer-to-Peer Internet Telephony using
SIP”, Department of Computer Science, Columbia University
[65] E. Guttman, “Autoconfiguration for IP Networking: Enabling Local
Communication”, Sun Microsystems, Germany, 2001
Top Related