Stella: Sistema de Backup Peer-to-Peer João Rocha Junior, Daniel Andrade, Lucas Moreira, Osvaldo Matos Júnior, Robério Almeida Filho, Jorge Lima, Paloma Santos Universidade Estadual de Feira de Santana (UEFS) Av. Universitária, s/n, Km 03 da BR 116 – 44.031-460 - Feira de Santana – BA
[email protected], {danbittencourt, cordax}@gmail.com, {tupydabahia, rkielmann, jorgelimadm, palomss}@yahoo.com.br
Abstract. In an effort to propose an application and introduce a new insight in peer-to-peer (p2p) research, this paper describes Stella: a decentralized backup system based on structured and unstructured peer-to-peer networks. Stella proposes a new way to connect nodes based on its relative relevance and shows that is possible to use the best of the two most used p2p models to build a most efficient and cohesive solution. Resumo. Com o objetivo de propor uma aplicação e introduzir uma nova abordagem dentro da pesquisa em redes peer-to-peer (p2p), esse artigo descreve Stella: um sistema de backup descentralizado baseado em redes peer-to-peer estruturadas e não estruturadas. Stella propõe uma nova maneira de conectar Nós, baseado na sua relativa relevância e mostra que é possível utilizar o melhor dos dois modelos p2p mais utilizadas para construir soluções mais eficientes e coesas .
1. Introdução Com o avanço tecnológico, o custo para armazenar dados tem se tornado mais barato, sendo comum encontrar computadores pessoais com 80GB de espaço em disco. Na mesma vertente está o custo com conexão, que vem caindo drasticamente. Segundo pesquisa realizada pelo CNT/Sensus publicada pela revista Veja [Revista Veja 2004], os brasileiros estão aderindo à Internet de banda larga e armazenando mais informações importantes em seus computadores pessoais. Entretanto todo esse avanço tecnológico e disponibilidade de recursos trazem consigo um problema real que já atingiu e que ainda deixa apreensiva a maior parte dos usuários que utilizam computadores - a perda de suas informações! Perder informações está se tornando mais problemático e caro, uma vez que o ser humano nunca esteve tão dependente delas. Hoje são armazenadas fotos, diários, projetos, tarefas, cronogramas, trabalhos artísticos e informações confidenciais de valor inestimável e que podem simplesmente desaparecer a qualquer instante. Apesar do baixo custo e popularização de equipamentos como gravadores de CD, que permitem armazenar cópias das informações, é sempre complicado mantê-las de forma organizada. Além disso, está se tornando mais comum ter acesso a informações pessoais ou profissionais a partir de diversos dispositivos: computador pessoal, computador do trabalho, notepad, notebook ou até mesmo o celular. Nesse caso, o CD se torna uma mídia que não pode ser acessada a partir de qualquer dispositivo e a todo o momento.
O Stella consiste em um sistema para o armazenamento transparente de backup de arquivos utilizando a tecnologia peer-to-peer (p2p) visando aproveitar recursos computacionais ociosos existentes na rede e proporcionar um meio confiável de armazenamento e persistência de dados, que possa ser acessado a partir de qualquer lugar de forma transparente e de fácil utilização para o usuário. O texto está organizado como a seguir: A seção 2 apresenta os trabalhos relacionados. Na seção 3 é exibida a arquitetura do Stella. A seção 4 descreve a implementação em maiores detalhes. Enquanto a seção 5 discorre sobre o funcionamento da ferramenta. Uma avaliação preliminar é descrita na seção 6. E por fim, as considerações finais são apresentadas na Seção 7.
2. Trabalhos Relacionados A maioria dos computadores pessoais possui espaço em disco e processamento que vem sendo descartado por aplicações que utilizam o modelo cliente/servidor amplamente difundido [Rocha Junior, J. B. et all. 2004b]. Assim, máquinas que possuem alto poder de processamento e imensa capacidade de armazenamento se tornam sub-utilizadas. Vários projetos de pesquisa têm proposto a criação de Grids Computacionais e redes peer-to-peer (p2p) para otimizar o uso de processamento extra e espaço em disco abundante para realizar tarefas relevantes. Muitos desses projetos tem alcançado grande notoriedade como é o caso do projeto Beowulf [Becker, D., et al. 1995] da NASA que mostrou que o alto desempenho computacional pode ser obtido usando um conjunto de máquinas distribuídas. Características dos Sistemas Distribuídos como: alta disponibilidade de arquivos, grande área de armazenamento e mecanismos eficientes para a localização e recuperação de conteúdos armazenados. Podem explicar o sucesso que aplicações como o eMule, KaZaA, Gnutella, entre outras, vêm obtendo entre usuários de Internet [Rocha Junior, J. B.; et al. 2004a]. O OceanStore [Kubiatowicz, J. D. et al. 2000] é um projeto de pesquisa que tem como objetivo desenvolver um repositório global de arquivos utilizando a tecnologia p2p. Diferentemente do Stella, o OceanStore tem como objetivo prover uma infra-estrutura global para o armazenamento de arquivos. Essa infra-estrutra pode ser acessada por diversos tipos de dispositivos que não colaboram armazenando arquivos de outros usuários, simplesmente utilizam a rede OceanStore para armazenar seus dados. Nesse sentido o OceanStore se assemelha ao X-Peer [Rocha Junior, J. B. et all. 2005] desenvolvido pela UFPE em parceria com a RNP (Rede Nacional de Pesquisa). Esse tipo de solução descaracteriza em parte a tecnologia p2p que propõe a igualdade entre os pares. Outra diferença importante é que o OceanStore é baseado puramente numa solução p2p não estruturada (inundação) como o Gnutella [Rocha Junior, J. B.; et al. 2004a], o que proporciona um melhor tempo de resposta para algumas consultas, entretanto possui características não-determinísticas no processo de recuperação de informações. O pStore [Batten, K. et al. 2001], diferentemente do OceanStore, possui objetivos similares ao Stella. Uma vez que o objetivo principal do pStore é prover uma solução simples para backup de arquivos distribuídos e se tornar uma alternativa para substituir
soluções atuais como: cds e dvds ou servidores centrais. Enquanto o pStore utiliza o chord [Stoica, I et all. 2001], tecnologia estruturada baseada em DHT (Distributed Hash Table), para identificar os Nós que receberão cópias dos arquivos, o Stella utiliza um modelo híbrido composto por duas modelagens: estruturada, baseada em DHT, e não estruturada, baseada em mecanismo de vantagem de conexão. A tecnologia não estruturada possibilita utilizar a localidade do Nó para armazenar cópias em máquinas próximas e, assim, obter um melhor desempenho no armazenamento e recuperação das réplicas, enquanto o uso do modelo estruturado possibilita a autenticação de usuários, além de garantir a recuperação de uma cópia atribuindo ao Stella características determinísticas.
3. Arquitetura de Comunicação As duas principais modelagens utilizadas para o desenvolvimento de aplicações p2p: estruturada e não estruturadas, possuem vantagens e desvantagens. As soluções não estruturadas possibilitam a conexão entre Nós bem estabelecidos (super Nós) e assim conseguem um maior desempenho na consulta. Entretanto pela sua característica não determinística não é possível garantir a recuperação de uma informação, uma vez que ela tenha sido publicada na rede. Isso traz grandes implicações, por exemplo não é possível fazer a autenticação de usuário nesse tipo de rede, porque não existe garantia nenhuma de que o login e senha poderão ser recuperados a qualquer momento, por isso o Napster utilizou um servidor central para armazenar as informações do usuário e pode ser bloqueado pela RIAA (Recording Industry Association of America).
Rede estrturada Rede não estrturada
Nó Stella Agente Estruturado Agente Não Estruturado
Figura 1: “Rede estruturada” e “Rede não estruturada”
A Figura 1 exibe a rede não estruturada, formada através da conexão entre os Agentes Não Estruturados e a rede estruturada, formada pela conexão entre os Agentes Estruturados. Enquanto que na rede não estruturada pode haver Nós que não conseguem obter informações de outros, a rede estruturada garante a coesão possibilitando recuperar a partir de um Nó, informações que estejam em qualquer outro Nó.
3
4
3
1
1
1
2
1
2
1
3
…
2
4
5
3
5
7
2 6
1
7
2 6
8
8 9
Rede Estruturada Rede Não Estruturada
Nó Stella Agente Estruturado Agente Não Estruturado
9
Figura 2: evolução das redes que constituem o Stella
A importância em utilizar os dos modelos pode ser verificada à medida que o número de conexões aumenta. Inicialmente a rede estruturada e não estruturada se confundem, entretanto com o aumento de Nós, essas duas redes passam a ter papéis bem definidos como ilustrado na Figura 2. Enquanto a não estruturada mantém a proximidade com Nós, a estruturada possibilita a coesão de toda a rede. O Stella utiliza a rede estruturada para garantir a recuperação de uma informação que tenha sido armazenada, esse determinismo facilita o desenvolvimento de aplicações, porque os dados sempre poderão ser recuperados. Entretanto a distribuição dos Nós baseada exclusivamente no seu número hash pode deixar máquinas que estejam fisicamente distantes, virtualmente próximas, o que degrada bastante o desempenho. Para melhorar o tempo para localizar e recuperar um arquivo, o Stella utiliza o modelo não estruturada que utiliza Nós bem conectados. 3.1. Rede Não Estruturada As aplicações que utilizam o modelo não estruturado empregam um parâmetro chamado TTL (time to live) para especificar o número de vezes que a consulta se propaga para outros Nós. Enquanto o Gnutella utiliza para TTL o valor 4, o Stella utiliza TTL o valor 1, ou seja, a busca no Stella só é feita nos Nós que estão diretamente conectados. Portanto, o procedimento de busca é realizado em duas etapas: primeiro verifica se os Nós que estão diretamente conectados possuem o arquivo, caso não encontre, submete à consulta a rede estruturada. Cada conexão na rede não estruturada é gerenciada por um Agente Não Estruturado que funciona como um representante do Nó remoto na instância local, este componente mantém atributos de velocidade de conexão, tempo que o Nó remoto está ativo e uma referência (número hash) para o Nó remoto. Além de possuir procedimentos (métodos) que permitem enviar e receber dados do servidor remoto. Para decidir com quais Nós se conectar e de quais receber uma cópia de seus arquivos, o Stella utiliza uma processo de seleção baseado em um critério de vantagem de conexão
que calcula a nota de cada Nó, e os ordena de forma decrescente de acordo com a sua nota. A nota é calculada através da seguinte fórmula: Nota =
freeConn MAX _ CONN
mem space timeActive speedConn ∗ + 2∗ + 3∗ + 4∗ bestMem bestSpace bestTimeAc tive bestSpeedC onn
Onde, − freeConn: número de conexões livres. Esse número é calculado subtraindo o número máximo de conexões (MAX_CONN) pelo número de conexões ativas; − MAX_CONN: número máximo de conexões. Valor constante, o padrão é 32; − mem: quantidade de memória livre na máquina virtual Java (em bytes) − space: quantidade de espaço disponível para armazenamento (em bytes); − timeActive: tempo que o Nó está ativo (em milisegundos); − speedConn: taxa de transferência de dados (bytes/segundo); As constantes correspondem ao peso do atributo dentro da equação. A velocidade de conexão (speedConn) e tempo que o Nó está ativo (timeActive) foram ajustadas com pesos maiores, visto que o objetivo primordial da equação é identificar os Nós onde é possível armazenar mais rapidamente e ter uma maior probabilidade de encontrar a informação disponível. Enquanto que o número de conexões serve para distribuir melhor o backup entre os Nós e evitar a sobrecarga dos que estiverem mais bem conectados. Portanto o Nó que não possuir conexões livres terá nota zero (freeConn=0) e não receberá novas conexões. Cada uma das frações da equação é obtida dividindo o numerador pelo melhor valor desse atributo dentre todos os Nós conectados, o que significa que cada fração sempre será um número entre zero e um. Portanto a soma de todos os valores multiplicados por seu peso dará no máximo 10. Isso evita que a nota cresça indefinidamente à medida que a tecnologia avance, visto que sua nota sempre será dada em função das variáveis de outros computadores que o Nó esteja conectado. 2
mem 12 MB space 43 MB freeConn 31 timeActive 1 min
speedConn 2 KB/s Nota 3,7 mem 16 MB space. 8 MB freeConn 29 timeActive 5 min
1 speedConn 9 KB/s Nota 6,2
6
3 speedConn 4 KB/s Nota 5,7 mem 14 MB space 10 MB freeConn 30 timeActive 10 min
speedConn 7 KB/s Nota 6,3
4 5
mem 17 MB space. 4 MB freeConn 30 timeActive 8 min
7
Figura 3: seleção de Nós para armazenar cópias de arquivo
Por exemplo, na Figura 3, o melhor espaço (43MB) e o melhor número de conexões livres estão no Nó 2. Entretanto como na equação as variáveis que possuem maior peso
são velocidade de conexão (taxa de transmissão de dados) e tempo que o Nó está ativo, os Nós que receberam melhores notas foram quatro e três, com notas 6,3 e 6,2 respectivamente. 3.2. Rede Estruturada A rede estruturada utilizada no Stella é baseada no DKS (N; k; f) [Alima, L. et. all 2003], que corresponde a uma família de infra-estrutura p2p com grande escala, tolerante a falhas e com baixa comunicação desenvolvida para construir aplicações peerto-peer. Cada instância DKS (N; k; f) corresponde a uma rede completamente descentralizada caracterizada por três parâmetros: N representando o número máximo de Nós que a rede suporta; k delimitando a área de busca e f indicando o grau de tolerância a falhas. O DKS (N; k; f) pode ser compreendido como uma extensão do Chord. Sendo assim, ao atribuir k igual a 2 o DKS (N; k; f) fica com uma tabela de roteamento do mesmo tamanho que a do Chord. A diferença principal entretanto, reside no fato de o Chord utilizar um modelo de correção ativa que realiza um procedimento de tempos em tempos em toda a rede para identificar os Nós que saíram e que entraram e atualizar os seus ponteiros. Esse procedimento possui um alto e desnecessário custo de comunicação. O DKS no entanto, utiliza um modelo baseado em correção sob demanda que trata o problema quando ele ocorre, esse modelo diminui bastante o número de comunicações para gerenciamento da rede, tornando então o DKS mais eficiente. O Stella utiliza uma implementação do DKS baseada em Java bastante simples: o JDHT. O JDHT implementa a interface java.util.Map, o que torna o seu uso bastante simples e intuitivo. O JDHT foi desenvolvido pelo KTH/Royal Institute of Technolgy (http://www.kth.se) em parceria com o Swedish Institute of Computer Science (http://www.sics.se) no contexto do projeto PEPITO (http://www.sics.se/pepito). 3.3. Estruturas de dados O Stella utiliza duas estruturas de dados: uma estrutura que fica armazenada localmente, lista de endereços, e outra que fica armazenada remotamente, dados do usuário. A lista de endereços contém IP e porta de outros Nós Stella e é utilizada no momento que a aplicação tem início. Essa lista é atualizada constantemente durante o funcionamento da aplicação com o objetivo de manter conexões com “bons Nós” (Figura 3). A Figura 4 descreve essa estrutura no formato XML.
Figura 4: lista de endereços
A estrutura que contém os dados dos usuários é armazenada remotamente na rede estruturada. Como essa rede é baseada em DHT, os dados são armazenados na forma de uma tupla composta por chave e valor. Onde a chave é o e-mail do usuário e o valor é um objeto contendo as informações descritas na Figura 5.
Figura 5: dados do usuário armazenados remotamente
Os dados do usuário armazenados remotamente são: e-mail e senha, utilizados para autenticar um usuário e as demais informações se referem aos arquivos copiados pelo usuário como: − space: tamanho em bytes que o usuário disponibilizou para armazenar arquivos de outros usuários. Esse atributo também delimita o tamanho de informações que o usuário pode armazenar remotamente, que deve ser menor ou igual; − files: arquivos do usuário armazenados no Stella; − name: nome do arquivo; − size: tamanho do arquivo em bytes; − hash: identificador do arquivo, produzido pelo algoritmo MD5 [Rivest 1992]; − backuped: data na qual foi realizado o backup do arquivo no Stella; − accessed: data na qual o arquivo foi acessado pela última vez; − mine: indica se o arquivo pertence ao usuário (true) ou não (false);
4. Implementação O diagrama de pacotes permite visualizar o agrupamento das classes principais formando uma unidade concisa do sistema. Ele é importante porque exibe a dependência entre os principais pacotes do Stella mostrando sua organização lógica, Figura 6.
Figura 6: principais pacotes do Stella
Segue uma breve descrição dos principais pacotes: − uesf.p2p.util: pacote com classes que serão usadas por todo o sistema, e não são específicas da aplicação. Como classes para enviar e-mail, tratar arquivos XML, etc.; − uesf.p2p.comm: possui as classes que servem como modelo para o sistema como Server responsável por criar canais de comunicação; − uesf.p2p.stella.util: pacote com classes que serão usadas por todo o sistema, sendo estas específicas da aplicação; − uefs.p2p.stella.comm: pacote que contém as classes responsáveis pela comunicação entre Nós Stella. É nesse pacote, por exemplo, que está a classe StellaAgent responsável por realizar a comunicação com um Nó estruturado; − uefs.p2p.stella.protocol: contêm as classes que definem o protocolo de comunicação do Stella, como: Ping, Pong, Search, Download, Upload, Remove, etc. − uesf.p2p.stella.equation: contêm as classes responsáveis pela seleção dos Nós e cálculo da notas que cada Nó recebe; − uesf.p2p.stella.home: pacote responsável por tratar os arquivos. Nesse pacote encontram-se as chamadas para os pacotes java.util.zip e java.security para compactar e criptografar os arquivos antes de serem enviados; − uefs.p2p.stella: pacote que contém as principais classes de negócio, ele utiliza recursos de vários outros módulos para prover as funcionalidades do Stella funcionando como uma fachada para a Interface gráfica do sistema que poderão ser diversas sem que para isso o Stella sofra qualquer alteração; − uesf.p2p.stella.show: pacote com toda a parte gráfica do sistema.
5. Funcionamento Cada aplicação Stella armazena localmente um conjunto de endereços para outros Nós, que é atualizado a cada nova conexão (Figura 4). Caso a aplicação não consiga estabelecer conexão com nenhum dos Nós dessa lista, ela realiza o download de uma nova lista do servidor da aplicação (http://stella.uefs.br). Ao se conectar, o novo Nó
recebe endereços de outros Nós Stella que estão ativos, assim a lista de endereços aumenta e se atualiza com Nós que ficam mais tempo ativos. É bastante provável que a aplicação nunca necessite realizar o download de uma nova lista do servidor de aplicação, uma vez que ao finalizar ela mantém uma lista com os 32 (MAX_HOST) Nós mais bem conectados.
Figura 7: Tela de confirmação de cadastro
Uma vez que a conexão tenha sido estabelecida com um conjunto de Nós, o Stella seleciona o melhor deles e solicita a referência DHT desse Nó. Com essa referência ela realiza a conexão estruturada. Só depois desse processo, a aplicação estará apta para realizar o login do usuário. O processo de login requer que o usuário tenha sido previamente cadastrado no Stella. Para isso ele deve preencher e-mail e senha e aguardar uma mensagem de e-mail contendo um número de cadastro (Stella Key), de posse desse número o usuário volta à aplicação para finalizar seu cadastro (Figura 7). Uma vez cadastrado o usuário bastará informar apenas e-mail e senha para ter acesso.
Figura 8: parte da tela principal do Stella indicando que o arquivo “curriculum.pdf” foi armazenado e a data que a operação foi realizada
Para validar o login de um usuário, o Stella recupera a estrutura que contém informações do usuário (Figura 5) na rede estruturada e verifica se a senha fornecida confere com a senha armazenada. Caso o mesmo não tenha sido cadastrado, suas informações não estarão na rede estruturada. Uma vez que o usuário tenha seu acesso liberado, será possível fazer o backup de arquivos. Para isso basta selecionar um arquivo clicando no botão + e aparecerão na tela (Figura 8) o endereço completo do arquivo e a data em que foi realizado o backup. O usuário poderá também configurar a aplicação definindo o espaço em disco que ele reservará no seu computador para receber o backup de outros usuários, o usuário só poderá armazenar no Stella uma quantidade menor ou igual ao espaço disponibilizado
para o armazenamento de arquivos de outros usuários, dessa forma pretende-se estimular o compartilhamento de dados. Todas as informação são armazenadas no Stella compactadas e criptografadas utilizando as bibliotecas padrões de Java, java.util.zip e java.security.
6. Avaliação Preliminar Para realizar os testes no Stella foi desenvolvido um simulador simples de uso da aplicação. O simulador consiste em realizar os procedimentos mais comuns que são executados por um usuário como: armazenamento, remoção e recuperação de um arquivo. O simulador recebe como parâmetro uma instância da aplicação Stella, um diretório contendo arquivos e um conjunto de atividades. As atividades podem ser adicionar um arquivo (Add), remover um arquivo (Delete) e recuperar um arquivo (Recover). As atividades são executadas seqüencialmente de acordo com a letra de cada Atividade. A lista “A A A A A A A D A R A“, por exemplo, indica que o simulador deve fazer 7 inserções de arquivos (A) uma remoção (D), depois uma nova inserção (A), depois recuperar um arquivo remoto (R) e depois inserir um novo arquivo (A). O intervalo de tempo entre uma ação e outra pode ser configurado no simulador, o valor padrão utilizado foi 30 segundos. No momento da adição, o simulador seleciona aleatoriamente um arquivo de um diretório específico para simulação e armazena o arquivo no Stella. Durante a remoção (D), o simulador solicita que o Stella remova o arquivo localmente e notifica a todos os demais Nós que o arquivo não precisa ser mais armazenado, enquanto a recuperação consiste em localizar e recuperar o arquivo armazenado anteriormente. 6.1. Exemplo de uso Infelizmente, por restrições de tempo, não foi possível realizar uma avaliação mais detalhada do Stella. A simulação executada serve apenas para demonstrar o funcionamento da aplicação e consistiu em executar quatro instâncias do Stella em dois computadores diferentes numa mesma rede local. Foi criado um diretório contendo 211 arquivos com tamanhos variando entre 711 e 2.310.432 bytes. Foi executada a seguinte seqüência “A A A D A D A A R D A D A R A D A D R A D D R”.
Figura 9: tempo para remover e recuperar um arquivo
A Figura 9 exibe o tempo gasto para remover um arquivo do Stella, esse tempo é pequeno porque compreende apenas o processo de notificar aos vizinhos sobre a remoção do arquivo. A Figura 9 exibe o tempo gasto para recuperar um arquivo. Esse procedimento consistiu em remover um arquivo local e solicitar a recuperação do mesmo, entre a remoção e a solicitação o processo ficou dormindo por 10 segundos, por isso todos os tempos tiveram um acréscimo de 10.000 milisegundos.
Figura 10: tempo para armazenar um arquivo
A Figura 10 compreende os tempo gasto para armazenar três (valor padrão) cópias de cada em Nós vizinhos a partir de um único Nó. Esse tempo ficou entre meio e 3 segundos, que é um tempo bastante razoável levando se em consideração o tamanho dos arquivos utilizados. Com as informações coletadas não foi possível avaliar o desempenho da aplicação em condições normais de uso, isso será realizado futuramente. Entretanto, é possível ter uma noção do desempenho da aplicação que ficou dentro do esperado.
7. Considerações Finais Esse projeto de pesquisa foi desenvolvido ao longo de uma disciplina anual do Curso de Engenharia da Computação (Projeto Desenvolvimento) da UEFS, composta por seis alunos de graduação e um professor orientador. A principal contribuição desse trabalho está no emprego de dois modelos complementares com um intuito de obter uma estrutura mais coesa e eficiente e de um mecanismo para determinação de relevância de nós vizinhos em redes não estruturadas. O Stella ainda está em fase de teste e procedimentos de avaliação mais detalhados serão utilizados para obter resultados mais precisos sobre o seu funcionamento e aplicação.
8. Referências Becker, D.; et al. (1995) “Beowulf: A Parallel Workstation for Scientific Computation”, 24o International Conference on Parallel Processing, 1995. Batten, C. K.; et al. (2001) “pStore: A secure peer-to-peer backup system”. Technical Memo MIT-LCS-TM-632, MIT Laboratory for Computer Science, December 2001.
Kubiatowicz, J. D. et al. (2000) “OceanStore: An architecture for globalscale persistent storage”. ACM SIGPLAN Notices, 35(11):190-- 201, November 2000. Revista Veja (2004) “…Um mundo sem fio”, Revista Veja, pp. 100-111, outubro 2004. Rocha Junior, J. B.; et al. (2005) “XPeer: Um Middleware para Aplicações Peer-toPeer”. In: WP2P SBRC2005, Fortaleza-CE. Rocha Junior, J. B.; et al. (2004a) “Análise de Tráfego Peer-to-Peer no Backbone da RNP”. In: Anais do XXII Simpósio Brasileiro de Redes de Computadores, SBRC2004, Gramado-RS. Rocha Junior, J. B.; et al. (2004b) “Peer-to-Peer: Computação Colaborativa na Internet”. In: Minicursos: XXII Simpósio Brasileiro de Redes de Computadores, SBRC2004, Gramado - RS. Rivest, R. (1992) “The MD5 Message-Digest Algorithm”. IETF, RFC 1321; Stoica, I.; Morris, R., Karger, D. R., Kaashock, M. Frans et Balakrishman, H. (2001) “Chord: A scalable peer-to-peer lookup protocol for internet applications”. In Proceedings of the ACM SIGCOMM, Agosto de 2001. Alima, L.; El-Ansary, S.; Brand, P.; and Haridi, S (2003) “DKS(N,k,f): A Family of Low Communication, Scalable and Fault-Tolerant Infrastructures for P2P Applications”. In 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID), 2003.
