Gnutella

Gnutella é um protocolo de rede peer-to-peer. Fundada em 2000, foi a primeira rede ponto a ponto descentralizada desse tipo, levando outras redes posteriores a adotar o modelo.

Em junho de 2005, a população da Gnutella era de 1,81 milhão de computadores, aumentando para mais de três milhões de nós em janeiro de 2006. No final de 2007, era a rede de compartilhamento de arquivos mais popular da Internet, com uma participação de mercado estimada em mais de 40%.

História

O primeiro cliente (também chamado Gnutella) que deu origem ao nome da rede foi desenvolvido por Justin Frankel e Tom Pepper, da Nullsoft, no início de 2000, logo após a aquisição da empresa pela AOL. No dia 14 de março, o programa foi disponibilizado para download nos servidores da Nullsoft. O evento foi anunciado prematuramente no Slashdot e milhares baixaram o programa naquele dia. O código-fonte seria lançado posteriormente, sob a licença GNU General Public License (GPL); no entanto, os desenvolvedores originais nunca tiveram a chance de atingir esse objetivo.

No dia seguinte, a AOL interrompeu a disponibilidade do programa por questões legais e impediu a Nullsoft de continuar trabalhando no projeto. Isso não impediu Gnutella; depois de alguns dias, o protocolo foi submetido a engenharia reversa e clones compatíveis de código aberto e gratuito começaram a aparecer. Este desenvolvimento paralelo de diferentes clientes por diferentes grupos continua sendo o modus operandi do desenvolvimento do Gnutella hoje.

Entre os primeiros pioneiros independentes do Gnutella estavam Gene Kan e Spencer Kimball, que lançaram o primeiro portal destinado a reunir a comunidade de código aberto para trabalhar no Gnutella e também desenvolveram o "GNUbile", um dos primeiros -source (GNU-GPL) para implementar o protocolo Gnutella.

A rede Gnutella é uma alternativa totalmente distribuída para sistemas semi-centralizados como FastTrack (KaZaA) e o Napster original. A popularidade inicial da rede foi estimulada pela ameaça de extinção legal do Napster no início de 2001. Esse aumento crescente na popularidade revelou os limites da escalabilidade do protocolo inicial. No início de 2001, variações no protocolo (implementado pela primeira vez em clientes proprietários e de código fechado) permitiram uma melhoria na escalabilidade. Em vez de tratar cada usuário como cliente e servidor, alguns usuários agora eram tratados como ultrapeers, roteando solicitações de pesquisa e respostas para usuários conectados a eles.

Isso permitiu que a rede crescesse em popularidade. No final de 2001, o cliente Gnutella LimeWire Basic tornou-se gratuito e de código aberto. Em fevereiro de 2002, Morpheus, um grupo comercial de compartilhamento de arquivos, abandonou seu software peer-to-peer baseado em FastTrack e lançou um novo cliente baseado no cliente Gnutella gratuito e de código aberto Gnucleus.

A palavra Gnutella hoje não se refere a nenhum projeto ou peça de software, mas ao protocolo aberto usado por vários clientes.

O nome é uma junção de GNU e Nutella, a marca de uma pasta italiana com sabor de avelã: supostamente, Frankel e Pepper comeram muito Nutella trabalhando no projeto original e pretendia licenciar seu programa finalizado sob a GNU General Public License. O Gnutella não está associado ao projeto GNU ou à própria rede ponto a ponto do GNU, GNUnet.

Em 26 de outubro de 2010, o popular cliente Gnutella, LimeWire, foi encerrado pela juíza Kimba Wood do Tribunal Distrital dos Estados Unidos do Distrito Sul de Nova York quando ela assinou um Decreto de Consentimento com o qual os queixosos da indústria fonográfica e o LimeWire concordaram. Este evento foi a causa provável de uma queda notável no tamanho da rede, porque, durante a negociação da liminar, a equipe do LimeWire inseriu um código de desativação remota no software. Quando a liminar entrou em vigor, os usuários que instalaram versões afetadas (mais recentes que 5.5.10) foram cortados da rede P2P. Como o LimeWire era um software livre, nada impedia a criação de forks que omitissem o código de desativação, desde que as marcas registradas do LimeWire não fossem usadas. O desligamento não afetou, por exemplo, o FrostWire, um fork do LimeWire criado em 2004 que não carrega nem o código de desativação remota nem o adware.

Em 9 de novembro de 2010, o LimeWire foi ressuscitado por uma equipe secreta de desenvolvedores e nomeado LimeWire Pirate Edition. Foi baseado no LimeWire 5.6 BETA. Esta versão teve suas dependências de servidor removidas e todos os recursos do PRO habilitados gratuitamente.

Design

O protocolo de busca e recuperação de gnutella

Para visualizar como o Gnutella funcionou originalmente, imagine um grande círculo de usuários (chamados nós), cada um dos quais possui software cliente Gnutella. Na inicialização inicial, o software cliente deve inicializar e localizar pelo menos um outro nó. Vários métodos foram usados para isso, incluindo uma lista de endereços pré-existentes de nós possivelmente funcionais fornecidos com o software, usando caches da web atualizados de nós conhecidos (chamados Gnutella Web Caches), caches de host UDP e, raramente, mesmo IRC. Uma vez conectado, o cliente solicita uma lista de endereços de trabalho. O cliente tenta se conectar aos nós com os quais foi enviado, bem como aos nós que recebe de outros clientes até atingir uma determinada cota. Ele se conecta apenas a esse número de nós, armazenando localmente em cache os endereços que ainda não tentou e descartando os endereços que tentou e considerou inválidos.

Quando o usuário deseja fazer uma pesquisa, o cliente envia a solicitação para cada nó conectado ativamente. Na versão 0.4 do protocolo, o número de nós conectados ativamente para um cliente era bastante pequeno (cerca de 5). Nessa versão do protocolo, cada nó encaminha a solicitação para todos os seus nós ativamente conectados, que, por sua vez, encaminham a solicitação. Isso continua até que o pacote atinja um número predeterminado de saltos do remetente (máximo 7).

Desde a versão 0.6 (2002), Gnutella é uma rede composta de nós folha e ultra nós (também chamados de ultrapeers). Os nós folha são conectados a um pequeno número de ultrapeers (tipicamente 3), enquanto cada ultrapeer é conectado a mais de 32 outros ultrapeers. Com esse grau de saída mais alto, o número máximo de saltos que uma consulta pode percorrer foi reduzido para 4.

Leaves e ultrapeers usam o Query Routing Protocol para trocar uma Query Routing Table (QRT), uma tabela de 64 Ki-slots e até 2 Mi-slots consistindo de palavras-chave hash. Um nó folha envia seu QRT para cada um dos ultrapeers aos quais está conectado, e os ultrapeers mesclam o QRT de todas as suas folhas (diminuído para 128 Ki-slots) mais seu próprio QRT (se compartilharem arquivos) e trocam-no com seus próprios vizinhos. O roteamento da consulta é feito por hashing das palavras da consulta e verificando se todas elas correspondem ao QRT. Ultrapeers fazem essa verificação antes de encaminhar uma consulta para um nó folha e também antes de encaminhar a consulta para um ultra nó peer, desde que este seja o último salto que a consulta pode percorrer.

Se uma solicitação de pesquisa apresentar um resultado, o nó que possui o resultado entrará em contato com o pesquisador. No protocolo Gnutella clássico, as mensagens de resposta eram enviadas de volta ao longo da rota percorrida pela consulta, pois a consulta em si não continha informações de identificação do nó. Esse esquema foi revisado posteriormente para entregar os resultados da pesquisa por UDP, diretamente ao nó que iniciou a pesquisa, geralmente um ultrapeer do nó. Assim, no protocolo atual, as consultas carregam o endereço IP e o número da porta de qualquer nó. Isso reduz a quantidade de tráfego roteado pela rede Gnutella, tornando-a significativamente mais escalável.

Se o usuário decidir baixar o arquivo, ele negocia a transferência do arquivo. Se o nó que possui o arquivo solicitado não estiver protegido por firewall, o nó de consulta pode se conectar a ele diretamente. No entanto, se o nó estiver protegido por firewall, impedindo que o nó de origem receba conexões de entrada, o cliente que deseja baixar um arquivo envia uma chamada solicitação push ao servidor para que o cliente remoto inicie a conexão em vez disso (para empurrar o arquivo). A princípio, essas solicitações push foram roteadas ao longo da cadeia original usada para enviar a consulta. Isso não era confiável porque as rotas frequentemente quebravam e os pacotes roteados sempre estavam sujeitos ao controle de fluxo. push proxies foram introduzidos para resolver esse problema. Estes são geralmente os ultrapeers de um nó folha e são anunciados nos resultados da pesquisa. O cliente se conecta a um desses push proxies usando uma solicitação HTTP e o proxy envia uma push request para uma folha em nome do cliente. Normalmente, também é possível enviar uma solicitação push por UDP para o proxy push, o que é mais eficiente do que usar TCP. Os proxies push têm duas vantagens: primeiro, as conexões ultrapeer-leaf são mais estáveis do que as rotas. Isso torna as solicitações push muito mais confiáveis. Em segundo lugar, reduz a quantidade de tráfego roteado pela rede Gnutella.

Finalmente, quando um usuário se desconecta, o software cliente salva uma lista de nós conhecidos. Isso contém os nós aos quais o cliente foi conectado e os nós aprendidos com os pacotes pong. O cliente usa isso como sua lista inicial, na próxima inicialização, tornando-se independente dos serviços de bootstrap.

Na prática, esse método de pesquisa na rede Gnutella geralmente não era confiável. Cada nó é um usuário comum de computador; como tal, eles estão constantemente se conectando e desconectando, então a rede nunca é completamente estável. Além disso, o custo da largura de banda da pesquisa no Gnutella cresceu exponencialmente com o número de usuários conectados, muitas vezes saturando as conexões e tornando os nós mais lentos inúteis. Portanto, as solicitações de pesquisa geralmente eram descartadas e a maioria das consultas atingia apenas uma parte muito pequena da rede. Essa observação identificou a rede Gnutella como um sistema distribuído não escalável e inspirou o desenvolvimento de tabelas hash distribuídas, que são muito mais escaláveis, mas suportam apenas correspondência exata, em vez de pesquisa por palavra-chave.

Para resolver os problemas de gargalos, os desenvolvedores do Gnutella implementaram um sistema em camadas de ultrapeers e folhas. Em vez de todos os nós serem considerados iguais, os nós que entravam na rede eram mantidos na 'borda' da rede, como uma folha. Folhas não fornecem roteamento. Os nós que são capazes de rotear mensagens são promovidos a ultrapeers. Ultrapeers aceitam conexões folha e pesquisas de rota e mensagens de manutenção de rede. Isso permite que as pesquisas se propaguem ainda mais pela rede e permite inúmeras alterações na topologia. Isso melhorou muito a eficiência e a escalabilidade.

Além disso, a gnutella adotou várias outras técnicas para reduzir a sobrecarga de tráfego e tornar as pesquisas mais eficientes. Os mais notáveis são o Query Routing Protocol (QRP) e o Dynamic Query (DQ). Com o QRP, uma pesquisa atinge apenas os clientes que provavelmente possuem os arquivos, portanto, as pesquisas por arquivos raros se tornam muito mais eficientes. Com DQ, a pesquisa para assim que o programa obtiver resultados de pesquisa suficientes. Isso reduz enormemente a quantidade de tráfego causada por pesquisas populares.

Um dos benefícios de ter o Gnutella tão descentralizado é tornar muito difícil desligar a rede e torná-la uma rede na qual os usuários são os únicos que podem decidir qual conteúdo estará disponível. Ao contrário do Napster, onde toda a rede dependia do servidor central, o Gnutella não pode ser desligado desligando qualquer nó. Uma rede descentralizada impede que maus atores assumam o controle do conteúdo da rede e/ou manipulem dados controlando o servidor central.

Recursos e extensões do protocolo

O Gnutella já operou em um protocolo puramente baseado em inundação de consultas. O desatualizado protocolo de rede Gnutella versão 0.4 emprega cinco tipos de pacotes diferentes, a saber:

• ping: descubra hosts na rede
• pong: resposta ao ping
• query: procure um arquivo
• query hit: responda à consulta
• push: pedido de download para servidores firewalled

Esses pacotes facilitam as buscas. Em vez disso, as transferências de arquivos são tratadas por HTTP.

O desenvolvimento do protocolo Gnutella é atualmente liderado pelo Gnutella Developers Forum (The GDF). Muitas extensões de protocolo foram e estão sendo desenvolvidas pelos fornecedores de software e pelos desenvolvedores Gnutella gratuitos do GDF. Essas extensões incluem roteamento de consulta inteligente, somas de verificação SHA-1, transmissão de ocorrências de consulta via UDP, consulta via UDP, consultas dinâmicas via TCP, transferências de arquivos via UDP, metadados XML, troca de fontes (também denominada malha de download) e download paralelo em fatias (swarming).

Há esforços para finalizar essas extensões de protocolo na especificação Gnutella 0.6, no site de desenvolvimento do protocolo Gnutella. O padrão Gnutella 0.4 está desatualizado, mas continua sendo a especificação de protocolo mais recente porque todas as extensões, até agora, existem como propostas. Na verdade, é difícil ou impossível se conectar hoje com 0,4 apertos de mão. De acordo com os desenvolvedores do GDF, a versão 0.6 é o que os novos desenvolvedores devem buscar usando as especificações do trabalho em andamento.

O protocolo Gnutella continua em desenvolvimento. Apesar das tentativas de romper com a complexidade herdada do antigo Gnutella 0.4 e de projetar uma nova arquitetura de mensagem limpa, ele continua sendo um dos protocolos de compartilhamento de arquivos mais bem-sucedidos até hoje.

Software

As tabelas a seguir comparam informações gerais e técnicas para vários aplicativos que suportam a rede Gnutella. As tabelas não tentam fornecer uma lista completa de clientes Gnutella. As tabelas são limitadas a clientes que podem participar da rede Gnutella atual.

Especificações gerais

Projeto descontinuado

Recursos do Gnutella

Notas

• Morpheus difere significativamente e pode ter código completamente independente do motor GnucDNA. Morpheus pode funcionar como um moderno ultrapeer enquanto outros clientes GnucDNA não podem.
• Gnucleus e Kiwi Alpha usam o motor GnucDNA.
• BearFlix, uma versão funcionalmente limitada da série BearShare 5.2, pode procurar apenas imagens ou vídeos e vídeos compartilhados são limitados a um comprimento relativamente curto.
• giFTcurs, Apollon, FilePipe, giFToxic, giFTui, giFTwin32, KCeasy, Poisoned e Xfactor são front-ends GUI para o motor giFT.
• etomi usa código de rede Shareaza desatualizado.
• MP3 Rocket, 360Share, LemonWire, MP3Torpedo e DexterWire são variantes de LimeWire.
• FrostWire (até a versão 4.21.8) é quase idêntico ao LimeWire 4.18, mas as versões superiores a 5.00 já não usam gnutella.
• Aquisição e Cabos são front-ends personalizados sobreposição do motor LimeWire.
• LimeWire Pirate Edition (5.6.2) é uma versão ressuscitada do LimeWire 5.6.1 alfa inédito, assim tem características similares menos atualizações automáticas (com nags) e controles remotos centralizados para desativar funções básicas como pesquisas e downloads foram removidos.

Gnutella2

O protocolo Gnutella2 (muitas vezes referido como G2), apesar de seu nome, não é um protocolo sucessor do Gnutella nem relacionado ao projeto Gnutella original, mas sim um protocolo completamente diferente que se bifurcou do projeto original e pegou carona no Nome Gnutela. Um ponto delicado com muitos desenvolvedores Gnutella é que o nome Gnutella2 transmite uma atualização ou superioridade, o que levou a uma guerra inflamada. Outras críticas incluíram o uso da rede Gnutella para inicializar os pares G2 e a documentação deficiente do protocolo G2. Além disso, as novas tentativas de busca mais frequentes do cliente Shareaza, um dos clientes G2 iniciais, podem sobrecarregar desnecessariamente a rede Gnutella.

Ambos os protocolos sofreram mudanças significativas desde a bifurcação em 2002. O G2 tem vantagens e desvantagens em relação ao Gnutella. Uma vantagem frequentemente citada é que a pesquisa híbrida do Gnutella2 é mais eficiente do que a inundação de consultas do Gnutella original. No entanto, o Gnutella substituiu a inundação de consultas por métodos de pesquisa mais eficientes, começando com o Roteamento de consultas em 2002. Isso foi proposto em 2001 pelos desenvolvedores do Limewire. Uma vantagem do Gnutella é sua grande base de usuários, que chega a milhões. A rede G2 é aproximadamente uma ordem de grandeza menor. É difícil comparar os protocolos em sua forma atual. A escolha do cliente, em qualquer rede, provavelmente afeta o usuário final da mesma forma.