Compartilhamento de Arquivos através de Redes Peer-to-Peer

Compartilhamento de Arquivos através de Redes Peer-to-Peer André Lucio de Oliveira 1, Gabriel Argolo Matos Rocha 1 1 Instituto de Computação - Universidade Federal Fluminense (UFF) Niterói RJ Brasil {aoliveira, grocha}@ic.uff.br Abstract. Some success application appeared in recent years utilizing the peer-to-peer model. Part of this application success comes from inherent characteristics of them, like anonymity. These applications have been used to exchange music files overcoming copyrights and thus suffering suits from the phonographic industry. On the other hand, their architecture makes use of distributed computing with redundancy and resilience. This tutorial aims to expose the main aspects relative to the state of the art in this technology. Resumo. Algumas aplicações de sucesso surgiram utilizando o modelo de redes peer-to-peer nos últimos anos. Parte do sucesso destas aplicações vem de características intrínsecas das mesmas, como o anonimato. Estas aplicações têm sido utilizadas para a troca de músicas burlando direitos autorais e sofrendo críticas e processos da indústria fonográfica. Por outro lado, sua arquitetura possibilita o uso de computação distribuída com redundância e tolerância à falhas. Este tutorial tem o objetivo de expor os principais aspectos relativos ao estado da arte desta tecnologia.[2] 1. Introdução O objetivo deste trabalho é realizar um estudo sobre as principais aplicações peer-to-peer, bem como entendermos a evolução deste tipo de aplicação e analisarmos os diferentes métodos para implementação do mesmo. A definição do que é uma rede do tipo peer-to-peer (P2P), pode parecer obscura em um primeiro momento. Contudo, é clara a distinção entre o paradigma cliente-servidor e o paradigma P2P. No primeiro existe uma clara distinção entre a entidade que está provendo um serviço e o cliente que o está consumindo. Por outro lado, não existe distinção entre os elementos de uma rede P2P, todos os nós possuem funcionalidades equivalentes. Para tornar este conceito mais claro vamos citar algumas definições encontras na literatura. Sistemas e aplicações Peer-to-peer são sistemas distribuídos sem qualquer forma de controle centralizado ou hierarquia organizacional, onde o

software que está sendo executado em cada nó é equivalente em funcionalidade. Tais sistemas também possuem muitos aspectos técnicos interessantes como, auto-organização, adaptabilidade e escalabilidade. Embora a definição exata de peer-to-peer seja discutível, estes sistemas não possuem infraestrutura centralizada, dedicada, mas ao invés dependem da participação voluntária dos pares para contribuir com recursos com os quais a infraestrutura é construída. Com o a aparecimento do sistema Napster [Napster, 2001] este tipo de rede tornou-se extremamente popular. Este sistema era utilizado para a troca de arquivos, geralmente música, entre os seus usuários tornando-se muito utilizado e conhecido em pouco tempo. No ano de 2001 o Napster foi considerado a aplicação com maior crescimento na Web tendo sido transferido por cerca de 50 milhões de usuários. O mesmo foi desenvolvido por uma companhia privada de mesmo nome que foi processada pela indústria fonográfica devido ao fato de os usuários do sistema o utilizarem para a troca de músicas protegidas por direitos autorais sem a devida permissão. Para utilizar o Napster, os usuários se registravam no sistema identificando os arquivos disponibilizados pelos mesmos. Após isto, um outro usuário poderia consultar o servidor, ou cluster de servidores, para encontrar e transferir um arquivo anteriormente compartilhado. Com o encerramento das operações do Napster, seus usuários e defensores iniciaram a utilizar um outro sistema, o Gnutella [Gnutella, 2000]. Diferentemente do seu predecessor, este sistema não necessita de uma entidade central para a realização das buscas dos arquivos possibilitando a operação direta entre os usuários. Desta forma, a indústria da música viu-se impossibilitada de impedir o funcionamento do Gnutella, pois não se sabe quem são os indivíduos que estão trocando arquivos. Mesmo que se identifiquem alguns usuários que estejam infringindo a lei, a punição dos mesmos não irá impedir o funcionamento da rede e o restante dos usuários continuará a permutar músicas. Com isto fica claro que existem muitas motivações de teor não técnico para a utilização destes sistemas. Por outro lado, com o crescimento do poder de processamento dos nós finais da Internet, os computadores pessoais, uma capacidade extraordinária de processamento não é utilizada nos dias de hoje. Esta capacidade, segundo estudos, soma 10 bilhões de Mhz de poder de processamento e 10 mil terabytes de armazenamento, considerando que de cada 100 milhões de PCs dos 300 milhões de usuários da internet, cada um contribui com 100 Mhz de processamento e 100 Mb de armazenamento. Redes P2P para compartilhamento de arquivos na Internet são resumidamente redes overlay dinâmicas com participação voluntária onde todos os nós participantes trocam arquivos diretamente. As mesmas podem possuir o mecanismo de busca centralizado ou distribuído pela rede.

A próxima seção apresenta duas nomenclaturas para a classificação dos sistemas P2P. Após isto, apresentamos dois sistemas clássicos e que impulsionaram o uso das redes P2P, o Napster e o Gnutella. Em seguida, mostramos um novo modelo de busca numa rede P2P chamado DHT(Ditributed Hash Table). Após isto, exibem-se alguns dados estatísticos sobre testes executados em redes P2P. Este trabalho é finalizado com uma conclusão. 2 Modelos de Aplicações P2P (Classificações) Nesta seção serão apresentadas duas nomenclaturas (Classificações) propostas para as redes P2P. Primeiramente, iremos abordar a primeira a qual chamaremos de Classificação 1. Em seguida, será exposta a segunda definição para a qual iremos nos referir como Classificação 2. 2.1) Classificação 1. 2.1.1) Modelo Centralizado No modelo centralizado, uma unidade central (Servidor ou conjunto de servidores) contém os identificadores de todos os participantes da rede P2P. Desta forma, estabelece-se um modelo cliente servidor entre cada peer (nó) da rede e o servidor P2P. Exemplo: Napster. 2.1.2) Modelo Descentralizado No modelo descentralizado não existe uma coordenação central (servidor). Neste modelo, rede P2P é dita completamente distribuída. Exemplos: Gnutella, Freenet. 2.1.3) Modelo Hierárquico Este modelo envolve, basicamente, a mistura dos modelos centralizado e descentralizado. Para tanto, são introduzidos na rede P2P os chamados super-nós (super-nodes ou super-peers). Exemplos: KaZaA, Morpheus. 2.2) Classificação 2 2.2.1) CIA (Centralized Indexing Architecture) Uma rede peer-to-peer com uma arquitetura CIA é aquela que contêm um servidor central ou um cluster de servidores que é

responsável por responder os pedidos de busca e realizar todas as tarefas de manutenção da infraestrutura. O exemplo mais comum de uma rede deste tipo é o sistema Napster. Hoje, sabemos que os criadores deste serviço foram processados e que a rede está fora do ar, ou seja, os servidores do Napster estão impedidos de funcionar. Isto ilustra um fato de redes do tipo CIA, existe um ponto central que se estiver inoperante, a rede não funciona. Redes deste tipo não são verdadeiramente peer-to-peer, porque além de existir um ponto único de falha, apenas a transferência de arquivos é feita de forma distribuída. O mecanismo de buscas e a manutenção da infraestrutura são realizados de forma centralizada, conforme o paradigma cliente/servidor. 2.2.1) DIFA (Distributed Indexing with Flooding Architecture) Esta arquitetura, assim como também a DIHA, é caracterizada pela completa descentralização de seu funcionamento. Os mecanismos de busca e manutenção da infraestrutura estão distribuídos pela rede. Neste tipo de sistema, cada nó é responsável por manter a listagem dos seus próprios arquivos, e responder quando receber uma busca para um arquivo que seja uma resposta válida para a busca em questão. Para isto, é utilizado o mecanismo de "flooding" ou inundação. A rede deste tipo mais conhecida e estudada é a rede Gnutella. As redes deste tipo possuem uma limitação muito grande que está ligado ao fato de seu mecanismo de busca utilizar o mecanismo de inundação. Para que uma rede não fique saturada com a repetição infinita do flooding de mensagens, estas mensagens possuem um número máximo de nós que a mesma pode atravessar. Isto possui uma séria implicação, mesmo que um arquivo exista no sistema e que o nó que o contenha esteja on-line, uma busca para este arquivo pode falhar. Contudo, embora completamente descentralizadas, estas redes possuem deficiências sérias na performance. 2.2.3) DIHA (Distributed Indexing with Hashing Architecture) Esta arquitetura também possui uma característica totalmente descentralizada. A principal diferença entre as redes DIFA e DIHA está no mecanismo de busca. Nos sistemas com inundação, cada peer é responsável pelo espaço de índices relativo aos arquivos que ele próprio contêm. A arquitetura DIHA muda este conceito, cada nó é responsável por um subconjunto do espaço total de índices. Quando o nó entra na rede, este recebe um espaço do conjunto dos índices dos arquivos, ao sair da rede a mesma deverá designar estes índices para outro nó. As buscas não são difundidas na rede sem direção como no flooding, ao invés disto são direcionadas para o nó correto que é o responsável pelo respectivo índice dentro do espaço de índices.

Os protocolos que implementam este tipo de arquitetura são bem mais complexos, existem poucos estudos sobre a utilização dos mesmos. A seção de roteamento pelo conteúdo irá exemplificar um mecanismo deste tipo. 2. Napster e Gnutella Esta secção apresenta uma descrição dos sistemas Napster e Gnutella. Como estes sistemas sugiram antes de qualquer discussão formal de modelos de arquitetura e antes das propostas de roteamento pelo conteúdo, o entendimento dos mesmos é o ponto de partida para o entendimento dos conceitos P2P. A figura abaixo ilustra a diferença básica entre o funcionamento do Napster e do Gnutella, enquanto o primeiro possui um servidor (mais precisamente um cluster de servidores) para responder os pedidos de busca, o último realiza as buscas de forma distribuída pela rede. Figura 1. Napster e Gnutella. 2.1) Napster Este sistema foi inovador porque possibilitou a troca de arquivos entre vários usuários de forma direta entre a fonte e o destino. Contudo, os participantes não são capazes de descobrir a localização dos arquivos desejados de forma distribuída, os mesmos dependem de um servidor central. Quando um usuário deseja se conectar ao sistema, o mesmo deve conectar-se ao servidor central e então fornecer a lista dos seus arquivos que estará compartilhando. Outro usuário conectado fará uma busca por arquivos

que será respondida pelo servidor central. Eventualmente um arquivo disponibilizado anteriormente poderá ser listado como uma resposta para a busca do segundo usuário que poderá optar por iniciar uma transferência deste. Os arquivos são transferidos utilizando o protocolo HTTP diretamente entre a fonte e a origem sem intervenção do servidor. Pode-se notar facilmente que esta arquitetura não é inteiramente do tipo P2P. Isto porque embora a transferência dos arquivos ocorra de forma distribuída, as buscas são respondidas de uma forma cliente/servidor muito tradicional. Este assunto será novamente abordado na seção sobre Arquiteturas Puras. Desta forma, este tipo de rede não merece muita atenção quando o interesse é entender novas estruturas de sistemas baseadas no conceito P2P. Contudo, como veremos adiante, este tipo de arquitetura apresenta algumas vantagens e não deve ser ignorado quando da escolha de uma arquitetura a ser seguida para uma implementação real. 1 2 3 4 Figura 2. Funcionamento do Napster 2.2) Gnutella

Cada nó ou peer é chamado de servent pela nomenclatura da especificação Gnutella. Conforme característico das redes Peer-to-Peer, cada servent pode atuar como cliente ou servidor. Desta forma, eles possuem uma interface servidora para responder buscas dos pares e também possuem uma interface cliente para realizar suas próprias buscas. Como resultado, uma rede de servents Gnutella é altamente redundante e o serviço não será interrompido se vários nós estiverem desligados ou com problemas. Em [Gnutella, 2000] encontra-se uma descrição completa da versão 0.4 do protocolo Gnutella. A especificação do Gnutella versão 0.4 define uma série de descriptors que são utilizados na comunicação entre os peers. Os descriptors são as mensagens trocadas entre os servents pelo protocolo Gnutella. Adicionalmente, uma série de regras governa a troca das mensagens (descriptors) que em conjunto formam a especificação do protocolo. Abaixo temos uma tabela com os descriptors e suas funções. Tabela 1. Descrição dos Descriptors A descoberta dos nós existentes na rede e a pesquisa de ficheiros partilhados em rede são feitas usando um algoritmo de encaminhamento de mensagens por inundação de pacotes, através da rede de "serventes". Toda mensagem possui um cabeçalho, que de uma forma resumida inclui, uma identificação do tipo de descriptor que a mensagem representa, um identificador único da mensagem e um campo do tipo TTL que irá ser utilizado para conter a inundação. O controle de duplicação de pacotes é realizado através de: - Contador de nº de saltos, decrementado em cada salto; - Registro do identificador dos pacotes para as últimas N origens que passaram pelo "servente". A descoberta de "serventes" na rede é realizada através da difusão de um pacote "Ping" através de todas as ligações ativas do "servente".

Figura 3. Quando um "servente" recebe um pacote "Ping", e caso não conste na lista de pacotes recebidos, reenvia o pacote por todas as ligações exceto a por onde recebeu o Ping, por onde envia um pacote "Pong", indicando o número de ficheiros (Ex: mp3) local e o número de bytes disponibilizados (na versão 0.4 do protocolo). Os "serventes" que recebem o "Ping" de A vão, por sua vez, responder com "Pong" que A reencaminha pela ligação por onde recebeu o "Ping" inicial. Após este processo, o servente cria uma tabela de encaminhamento, que associa as ligações aos "serventes". A pesquisa usa o mesmo algoritmo de inundação, mas difundindo um pacote "Query" com o nome do ficheiro a procurar, que é respondido com "Hit", apenas pelos. "serventes" com ficheiros que obedeçam ao padrão procurado. Figura 4. A transferência do ficheiro é desencadeada com o envio do pacote Push", encaminhado usando as tabelas de encaminhamento, para um dos "serventes" que respondeu com "Hit". Esse servente cria uma ligação HTTP/TCP dedicada para transferir o ficheiro, usando os servidores HTTP que existem em todos os "serventes".

3. DHT (Distributed Hash Table) 3.1) Roteamento Pelo Conteúdo Conforme já dito anteriormente, pode-se identificar duas fases inteiramente distintas em uma rede P2P, a transferência de arquivos e a localização do mesmo. O imenso sucesso do Napster e do Gnutella além de angariar muitos adeptos, também motivou muitos grupos de pesquisa. Um ponto no qual muitos se concentraram foi a escalabilidade destes sistemas. Como a função principal dos mesmos é a transferência de arquivos que ocorre de forma direta entre origem e destino, então, a fase de transferência é intrinsecamente escalável. Isto porque quanto mais usuários, maior a capacidade do sistema para transferir arquivos. Portanto, estas redes podem ser escaláveis. Entretanto os sistemas clássicos, Napster e Gnutella, possuem problemas de escalabilidade devido aos métodos de localização dos arquivos. O Napster possui um elemento central que deve crescer junto com o número de usuários e portanto não é escalável. Por outro lado, o Gnutella utiliza o método de inundação para realizar as buscas que sabidamente também não é escalável. Isto porque se deve limitar o escopo da inundação para não saturar a rede e, portanto restringi-se a alcançabilidade das buscas. As principais propostas para mecanismos de localização dos arquivos escaláveis se baseiam em tabelas hash distribuídas (DHT Distributed Hash Table). Desta forma, cada chave da tabela possui seu respectivo conteúdo armazenado por apenas um nó. Quando um nó deseja saber a localização de um arquivo, que é mapeado univocamente em uma chave, ele inicia uma busca que é roteada para o nó responsável por armazenar a respectiva chave. O nó que possui a responsabilidade pela chave recebe a busca pela chave e responde com o seu valor, que é a localização do arquivo desejado. Tabelas hash (ou tabelas de espalhamento, ou tabelas de dispersão) são tabelas que utilizam uma função hash (ou função de espalhamento, ou função de dispersão) para fazer o mapeamento de diversas chaves em seus valores que são guardados como pares em um vetor. O valor da chave é utilizado como entrada da função hash que provê um inteiro como resultado. Este inteiro é utilizado como índice no vetor para se encontrar o valor correspondente da chave em questão. Ex: h( Aquarela do Brasil ) -> 8045

Figura 5. Faixa de resultados da função de hash é distribuída pela rede A seguir, apresentamos diferentes abordagens que foram desenvolvidas para o modelo DHT. Os sistemas CAN, Chord, Pastry e Tapestry diferem primariamente na escolha do algoritmo de roteamento. 3.2) Pastry Pastry, sistema em desenvolvimento pela Microsoft Research e Universidade Rice, visa construir um substrato para aplicações peer-to-peer descentralizado, auto-organizável e tolerante a falhas. Cada nó do sistema Pastry possui um identificador de 128 bits(nodeid), único e aleatoriamente escolhido. Isso garante que, nós com identificadores próximos estão distribuídos em termos de localidade e jurisdição. Cada um desses nós mantém informações sobre L nós que possuem identificador mais próximo numericamente; estes nós compõem o conjunto de nós folha. Cada nó avisa aplicações que estejam rodando sobre a chegada ou partida de novos nós em seu conjunto de nós folha. O roteamento de mensagens e requisições é bem eficiente, possuindo complexidade O(logN) em número de passos, N sendo o número de nós ativos no sistema em um dado momento. O tamanho da tabela de roteamento que cada nó deve manter também é O(logN). Quando uma mensagem passa por um nó do sistema, aplicações relacionadas à mensagem podem realizar computações relacionadas. Quando uma nova aplicação entra no sistema, ganha um identificador de objeto(objid), e é mapeada para o nó que possui identificador nodeid numericamente mais próximo. Caso haja interesse em replicação, o nó que recebe o objeto envia uma mensagem para mapear a aplicação em, digamos, K - 1 nós. Se K L 2 x L, as réplicas estarão nos nós folha do primeiro nó. Nesse cenário, um objeto só estaria inacessível se os K nós estivessem comprometidos. E, considerando que os nós folha estão em diferentes localizações, é difícil para um mal-intencionado prejudicar o funcionamento da aplicação. Também podem ser usados algoritmos de quorum para impedir que um nó mal-intencionado atualize ou leia as informações. Para manter alta disponibilidade, uma aplicação deve manter o seguinte invariante: em um dado momento, existem K réplicas de seus objetos

funcionando. Como o sistema Pastry mantém comunicação entre nós folha, e muito provavelmente as réplicas estarão em um conjunto de nós folha, é mais fácil checar o funcionamento das réplicas. É possível utilizar-se de caches para obter acesso rápido às informações já solicitadas. Quando uma aplicação manda uma mensagem de procura a um objeto, este pode ser armazenado em nós pertencentes ao caminho percorrido pela mensagem. Subseqüentes requisições tendem a percorrer o mesmo caminho e poderão utilizar as cópias em cache, o que ajuda a aliviar o número de requisições às K réplicas primárias do sistema. Existem três aplicações teste já funcionando sobre o sistema Pastry. Scribe, um sistema de notificação de eventos; PAST, um repositório cooperativo para arquivos e Squirrel, um cache cooperativo para Web. 3.3) Chord O sistema Chord, tem como objetivo oferecer uma base para a construção de aplicações peer-to-peer, oferecendo uma rotina de procura rápida de informações na rede distribuída. De maneira similar aos sistemas Pastry e Tapestry, garante que um objeto no sistema pode ser localizado em tempo O(logN) e a tabela de roteamento de cada nó possui O(logN) entradas. No caso do Chord, também existe a garantia que, caso um nó saia da rede, a atualização do status de roteamento requer apenas O(log2N). O sistema Chord é extremamente simples no que se refere à funcionalidade que provê. A única função que oferece é mapear chaves e seus respectivos objetos em nós do sistema. Funções como replicação e caching são deixadas totalmente a cargo da aplicação. Entretanto, o sistema facilita essas operações. Replicação, por exemplo, consiste em inserir no sistema o mesmo objeto sob diferentes chaves. O sistema não possui conhecimento sobre a localização dos nós e não há nenhum tipo de servidor central. Todas as referências no sistema (nomes de ficheiros e endereços IP dos membros da rede) são convertidas para uma chave, constituída por um número de 160 bits (20 octetos),usando uma função não invertível (definida pelo algoritmo SHA-1). chave(nome) = SHA-1(nome) É criada uma rede em anel virtual ligando os participantes na rede P2P ordenada pelo valor da chave dos endereços IP (Ex:1, 4, 7, 12, 15, 20, 27). Os índices para o ficheiro com o nome "nome" é guardado juntamente com o endereço IP do nó *******com o ficheiros****** no sucessor(nome), o nó com a chave(ip) imediatamente a seguir à chave do nome do ficheiros.

Ex: chave(nome)= 9 Guardado no servidor 12 Se existirem vários ficheiros com o mesmo nome, todos os registros são guardados no mesmo nó. A base de dados fica distribuída por todos os nós. A pesquisa de um ficheiro também é feita através da chave no nome pretendido. No entanto, pode ser lenta se existirem muitos nós. Desta forma, pode-se acelerar a busca em 50%, criando-se uma lista duplamente ligada. Para acelerar a pesquisa é criada uma tabela de apontadores em cada nó, com referências para outros nós. O elemento i da tabela (com m entradas) do nó k start= k+2 i (modulo 2 m ) Endereço IP de sucessor(start[i]) Exemplo de rede com chaves de 5 bits: Figura 6. Se o nó 1 pesquisar: chave(nome) = 3

1 conhece sucessor (4), devolve IP de 4. chave(nome) = 14 Start abaixo é 9 pedido a nó 12, 12 devolve endereço IP de 15 chave(nome) = 16 Start abaixo é 9 pedido a 12, pedido a 15, 15 devolve endereço do nó 20 Manutenção de tabelas - Os nós podem sair ou juntar-se em qualquer altura. - São definidas operações para entrar e sair do anel. - Cada nó conhece um ou mais antecessores e um ou mais sucessores. - Um novo nó tem de conhecer pelo menos um nó da rede. - Quando um nó com chave k pretende entrar: 1. pesquisa sucessor(k), obtendo o IP do futuro nó sucessor. 2. Depois pede ao sucessor o antecessor. 3. Finalmente comunica com estes nós, informando-os da sua existência. Quando um nó sai ordeiramente, todas os nós atualizam a informação sobre o sucessor e antecessor. As falhas de nós são ultrapassadas através do conhecimento de vários sucessores consecutivos, permitindo saltar vários nós. As tabelas de ponteiros são atualizadas por uma tarefa que acorda periodicamente para pesquisar os sucessores das chaves na tabela de apontadores. Algumas deficiências presentes no sistema chord são a impossibilidade de detectar partição do anel de nós e a possibilidade de usuários malintencionados fornecerem uma visão incorreta do sistema. Por exemplo, um usuário poderia inserir um nó no sistema de maneira a interceptar requisições à procura de um objeto, retornando erros. Entretanto, essas limitações se aplicam apenas ao sistema atual, e podem ser resolvidas no futuro. 3.4) Tapestry Tapestry, desenvolvido na universidade de Stanford, apresenta características semelhantes aos sistemas Pastry e Chord, fornecendo uma rede de sobreposição para permitir rápida localização de objetos, como já descrito antes. Entretanto, apresenta diferenças dos demais. Caching de objetos não é feito de forma automática como em Pastry, sendo necessária que a aplicação realize tal tarefa. Tanto Pastry como Tapestry levam em conta métricas da rede substrato para determinarem o roteamento, por exemplo, ping na rede Internet. Isso significa que a recuperação de um objeto através de mensagens possa resultar em menos mensagens nesses dois sistemas. Já Chord não assume nada em relação à rede substrato.

3.5) CAN CAN Content-adressable Network. Não entraremos no mérito do funcionamento deste sistema devido a uma maior complexidade que o mesmo exige em sua explicação. No entanto, podemos, de forma resumida, informar que o CAN usa um sistema baseado em coordenadas geométricas em que cada nó é responsável por um hipercubo. Esta divisão geométrica é vantajosa pois, quando um nó entra na rede somente um número fixo de nós é afetado. Por outro lado, nos outros algoritmos(pastry, Tapestry e Chord), um número proporcional à população da rede é afetado. Para um maior entendimento do sistema em questão citamos como referencia [*******]. 4. Alguns Dados Estatísticos 4.1) Avaliação da performance dos modelos CIA, DIFA e DIHA. Os gráficos seguintes foram obtidos com a simulação do modelo resultante simplificado e com verificação numérica dos resultados. O resultado analítico expresso no gráfico 1, é obtido através de um modelo matemático complexo que não apresentaremos. O aumento da carga na rede é simulado com a variação no número de downloads dos usuários on-line (população fixa em 500.000). Portanto, consegue-se o efeito do aumento da carga no sistema sem aumento da capacidade de serviço, que permanece constante. Todos modelos saturam em determinado momento, o que representa a capacidade do sistema fazer downloads. A arquitetura centralizada satura exatamente na capacidade do servidor atender as buscas. Modelos que dependem de inundação apresentam a pior performance devido a falhas das buscas devido a limitação imposta pelo TTL. O modelo DIHA escala melhor por causa da ausência de servidores e porque não falha nas buscas.

Abaixo, o gráfico mostra o efeito da variação do percentual de freeloaders em uma população fixa (500.000 nós) na vazão total. Notadamente, existe um aumento crescente do throughput com o aumento do percentual de freeloaders em todos os modelo até um certo limite. Os freeloaders acrescentam poder de busca nas arquiteturas distribuídas (DIFA e DIHA), o que justifica o aumento da vazão com o percentual de freeloaders. A maior degradação observada no modelo DIFA é explicada pelo aumento na probabilidade de falha das buscas. A proporção de freeloader ótima para a vazão total é de aproximadamente: CIA ~ 80%; DIHA ~ 90% e DIFA ~ 60%. As arquiteturas CIA e DIHA escalam bem para uma proporção razoável de membros servindo, não freeloaders. Podemos concluir que um número pequeno de nós servindo pode suportar uma grande rede P2P. Os freeloaders podem se beneficiar sem prejudicar significativamente os outros peers porque os freeloaders podem aproveitar recursos que estão sobrando na rede P2P. Podemos concluir que o modelo CIA é o mais performático para pequenas populações, ligeiramente melhor que o modelo DIHA antes da saturação do servidor. A arquitetura DIHA apresenta a melhor escalabilidade. Os sistemas baseados na arquitetura DIFA (flooding), não podem explorar plenamente o potencial de redes P2P porque possuem um impacto negativo sério em performance, sendo um método deficiente. A degradação é pequena quando os arquivos mais procurados não são os mais disponíveis. As redes P2P para compartilhamento de arquivos podem suportar uma proporção relativamente alta de freeloaders sem sofrer degradação considerável na performance dos outros peers. Isto porque estas redes possuem uma capacidade de reserva da qual os mesmos podem se beneficiar.

4.2) Compartilhamento de Arquivos Nesta seção apresentamos os resultados de medidas encontradas em [2] que possibilitam visualizar um grau de caracterização das redes P2P. Para possibilitar as medições foi feita uma modificação em um cliente Java denominado Furi, que é uma implementação completa do protocolo Gnutella e que possui capacidade de fazer registros. Este cliente foi executado durante um período de 24 horas ininterruptamente coletando descriptors Pong e QueryHit dos usuários normais. Foram observados 35.532 nós compartilhando um total de 3.304.046 arquivos. A figura abaixo mostra o número de arquivos compartilhados pelos 33.335 peers da amostra da medição. O gráfico está ordenado em forma de rank, do número de arquivos compartilhados. Iniciando da esquerda com zero para a direita com o maior número de arquivos compartilhados por um único nó. Figura 7. Rank de arquivos por usuário. Aproximadamente 66% dos peers não compartilha nenhum arquivo e 73% dos servents compartilham dez ou menos arquivos. Um pequeno percentual de 1% dos hosts (333 peers), que mais compartilham arquivos, compartilham 37% do total de arquivos compartilhados. Esta tendência cresce rapidamente de forma que apenas 20% dos nós (6.667 servents), que mais compartilham arquivos, compartilham 98% dos arquivos. Isto significa que um quinto dos peers compartilham praticamente a totalidade dos arquivos em uma rede Gnutella. A tabela abaixo ilustra o resultado obtido na medição realizada. Tabela 2. Distribuição dos arquivos compartilhados

Um servent somente irá responder uma busca se o mesmo está compartilhando arquivos, portanto com o resultado anterior, apenas 11.585 peers poderão estar enviando descriptor QueryHit. O objetivo é analisar se as respostas se distribuem uniformemente entre os servents que estão compartilhando arquivos. O gráfico abaixo ilustra o resultado encontrado de forma análoga ao gráfico anterior. Os peers estão colocados em um rank crescente relativo ao número de mensagens QueryHit enviadas. Figura 8. Rank por número de respostas. Uma grande proporção de hosts (63%) não respondeu a nenhuma busca, provavelmente porque os arquivos que estes peers estão compartilhando não são desejáveis. Isto indica que a contribuição de um servent para a rede Gnutella não pode ser medida apenas pela quantidade de arquivos compartilhados, mas deve também levar em conta a quantidade de vezes que este arquivo é requisitado. A tendência do gráfico mostra uma queda acentuada mostrando que poucos nós fazem a grande parte do trabalho. Quase a metade das buscas (47%) é respondida por apenas 1% dos hosts que mais respondem. Esta tendência é muito forte de forma que quase a totalidade (98%) das buscas é respondida por apenas um quarto (25%) dos servents que mais respondem. Foi realizada uma outra análise onde foram coletadas 202.509 mensagens em um outro experimento. Acredita-se que as buscas são muito concentradas em determinados tópicos, o que define uma alta qualidade. Desta forma, o número de peers que estará fornecendo arquivos de qualidade será ainda menor do que aqueles que estão compartilhando arquivos. Foram feitos cálculos sobre as amostras de forma a determinar o grau de concentração das buscas. Ficou constatado que 1% das buscas mais repetidas são responsáveis por 37% do total em uma rede Gnutella. O quarto de buscas mais repetidas (25%) é responsável por 75% do total das buscas na rede. Os valores obtidos são um pouco diferentes dos reais porque não foi feita a análise da combinação de palavras que podem ser de uma busca para um mesmo arquivo (ex: "britney spears" X "spears britney"). O host que mais respondeu buscas, respondeu 3.436 buscas e continha apenas 695 arquivos. Pelo gráfico podemos inferir que o host que mais compartilha arquivos disponibiliza 100.000

arquivos. O segundo host que mais respondeu buscas respondeu 1.474 buscas e contêm apenas 956 arquivos. Este resultado mostra que não existe um relacionamento entre o número de arquivos compartilhados e o número de buscas respondidas. Isto de deve ao fato de que as buscas não são uniformemente distribuídas entre os arquivos, mas concentradas para determinados arquivos mais requisitados. Uma grande proporção de usuários de uma rede Gnutella não compartilha nenhum arquivo, os chamamos de freeloaders. A análise em questão, concluiu que 70% dos usuários se comportavam desta maneira. Como em uma rede P2P todos os nós se comportam simultaneamente como servidores e clientes, espera-se que neste aspecto as este tipo de rede se diferencie muito das tradicionais redes cliente/servidor. Então, espera-se que uma rede P2P se comporte de forma que todos os nós sirvam e demandem serviço de uma forma relativamente proporcional. As medições acima demonstram claramente que o comportamento característico de um cliente pode ser claramente identificado nos hosts freeloaders, que não compartilham arquivos e demandam muitos serviços da rede. Por outro lado, o comportamento servidor fica muito bem caracterizado quando se nota que apenas 1% dos peers que compartilham arquivos são responsáveis por 50% das respostas para as buscas. 5. Conclusão Existe grande motivação para o desenvolvimento e a utilização de aplicações P2P. Pelo lado técnico, as mesmas representam a possibilidade do uso de sistemas de compartilhamento sem uma unidade central que podem se organizar e funcionar de forma descentralizada e auto-organizável. Além disto, as mesmas possuem características de computação distribuída, redundância e tolerância à falhas. Por outro lado, existem razões não técnicas que impulsionam o desenvolvimento das mesmas, sendo o anonimato a principal destas. As razões pelas quais as pessoas buscam o anonimato são basicamente duas atualmente, para o compartilhamento de material protegido por direitos autorais e para a expressão livre de idéias. Existe um espaço muito grande para o desenvolvimento destas aplicações porque as mesmas podem utilizar a capacidade de processamento e armazenamento ociosa nos computadores pessoais, os nós finais da Internet. Portanto, existe a capacidade de suportar altos números de usuários em um mesmo sistema sem a necessidade de grandes centros de processamento. A capacidade excedente é tão grande, que altos índices de nós não-cooperantes são suportados em uma rede deste tipo sem prejuízo de performance. Ainda que nestas redes todos os nós sejam equivalentes em funcionalidade, observa-se que existe um alto grau de especialização. Em outras palavras, o comportamento do tipo servidor é altamente caracterizado

em um número pequeno de nós e em um grande número de nós constata-se o comportamento típico de um cliente. Isto quer dizer que paradoxalmente, o paradigma cliente-servidor pode ser observado de forma contundente em uma rede P2P. 6. Referências [1] Material de suporte às aulas de Tópicos Avançados de Sistemas Distribuídos Copyright DI - FCT/ UNL 2003-2004 lookup. Endereço web: http://asc.di.fct.unl.pt/tasd/aulas/modulo1/data-lookup.pdf [2] Rafael R. da Rocha. Redes Peer-to-Peer para Compartilhamento de Arquivos na Internet. (Grupo de Teleinformática e Automação - PEE/COPPE - DEL/POLI - Universidade Federal do Rio de Janeiro). www.gta.ufrj.br/~rafael/tutp2p.pdf. [3] Chord - http://www.dsc.ufpb.br/~rakel/seminarios/chord_arquivos/frame.htm [4] Dalila Muniz Paiva - Web Semântica e Redes Peer-to-Peer http://genesis.nce.ufrj.br/dataware/tesi_2002_3/dalila_monografia_xml.pdf [5] M. T. Hajiaghagi e H. Zhou. Tópicos Sobre Problemas de Pesquisa na Internet. http://www.universiabrasil.net/mit/18/18996/pdf/lect3_mit.pdf