Peer-to-Peer Systems From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design...

Peer-to-Peer Systems

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Edition 4, © Addison-Wesley 2005

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4

© Pearson Education 2005

Introdução

Objetivo do P2P: compartilhamento de dados e recursos em uma grande escala, eliminando a necessidade da administração de servidores e sua infra-estrutura. Sistemas P2P têm a vantagem de que nos dias atuais, o desempenho entre servidores e clientes está se estreitando e a conexões de banda larga têm se proliferado.

Tradicionais sistemas cliente/servidor provêem acesso aos recursos localizados em um servidor central ou um agrupamento de servidores fortemente acoplados. Neste projeto centralizado, poucas decisões são feitas onde devem ser postos os recursos e o serviço é limitado pela capacidade do hardware do servidor e sua conectividade na rede. Sistemas P2P provêem acesso a informações espalhadas pela internet, sendo necessários algoritmos de posicionamento e recuperação de objetos na rede.



Características

Cada usuário contribui com recursos ao sistema, todos os nós têm as mesmas capacidades e responsabilidades, sua operação correta não depende de um administrador central, oferecem grau de anonimato e usa algoritmos para balanceamento de carga nos nós a fim de possibilitar disponibilidade.



Gerações do P2P

A primeira lançada pelo Napster, a segunda com aplicações de compartilhamento de arquivos, como Kazaa e BitTorrent e a terceira, com o emergente uso de camadas de middleware para o gerenciamento global de recursos distribuídos.Nestes sistemas P2P com middleware, haverá uma nova camada de roteamento complementar ao roteamento IP. Motivos para usar outra camada de roteamento sobre o roteamento IP: o espaço de nomes do P2P (GUID – identificadores únicos globais) é muito maior do o IPv6; a localização dos objetos independe da topologia de rede; as tabelas de roteamento são atualizadas sincronamente ou assincronamente, diferentemente do padrão IP; maior tolerância a falhas com adição de replicação; como cada endereço GUID mapeia para uma ou mais replicas de um mesmo objeto e inviável usar IPv4 que só mapeia para um endereço físico; e segurança em ambiente com confiança limitada, permitindo inclusive anonimato.



Figure 10.1: Distinctions between IP and overlay routing for peer-to-peer applications

IP Application-level routing overlay

Scale IPv4 is limited to 232 addressable nodes. The IPv6 name space is much more generous (2128), but addresses in both versions are hierarch ically structured and much of the space is pre-allocated according to administrative requirements.

Peer-to-peer systems can address more objects. The GUID name space is very large and flat (>2128), allowing it to be much more fully occupied.

Load balancing Loads on routers are determined by network topology and associated traffic patterns.

Object locations can be randomized and hence traffic patterns are divorced from the network topology.

Network dynamics (addition/deletion of objects/nodes)

IP routing tables are updated asynchronously on a best-efforts basis with time constants on the order of 1 hour.

Routing tables can be updated synchronously or asynchronously with fractions of a second delays.

Fault tolerance Redundancy is designed into the IP network by its managers, ensuring tolerance of a single router or network connectivity failure. n-fold replication is costly.

Routes and object references can be replicated n-fold, ensuring tolerance of n failures of nodes or connections.

Target identification Each IP address maps to exactly one target node.

Messages can be routed to the nearest replica of a target object.

Security and anonymity Addressing is only secure when all nodes are trusted. Anonymity for the owners of addresses is not achievable.

Security can be achieved even in environments with limited trust. A limited degree of anonymity can be provided.



Napster e seu legado

A arquitetura Napster inclui índices centralizados, mas os usuários que supriam os arquivos, e era nos computadores pessoais que eles eram armazenados e acessados. O Napster foi desligado como resultado de um procedimento legal contra seus operadores. Os passos do funcionamento do Napster estão na FIGURA 10.2.



Figure 10.2: Napster: peer-to-peer file sharing with a centralized, replicated index

Napster serverIndex1. File location

2. List of peers

request

offering the file

peers

3. File request

4. File delivered5. Index update

Napster serverIndex



Napster

O argumento do Napster fora que eles não participavam do processo de cópia, apenas os usuários. Contudo, os servidores de índice, parte fundamental do processo de busca, eram localizados em endereços bem conhecidos, o que impediu que os operadores mantivessem anônimos. Um sistema mais distribuído poderia ter alcançado uma melhor separação de responsabilidades e tornando a busca por remédios legais quase impossível.

Napster demonstrou a possibilidade de se construir um serviço em larga escala dependente quase completamente nos dados e computadores de usuários comuns da internet. A alocação de servidores ao cliente da música baseava-se na localidade da rede. Com esse mecanismo de distribuição de carga, o serviço escalou rapidamente para um grande número de usuários(13 milhões de usuário).



Napster-Culpado

Em maio de 1999, Shawn Fanning, um estudante universitário de 18 anos, criou um software que combinava o sistema de mensagens instantâneas do IRC, o sistema de compartilhamento de arquivos do Windows e Unix e as capacidades de busca das máquinas de pesquisa. O seu objetivo era criar um sistema que tornasse mais fácil compartilhar arquivos mp3. Ele batizou o seu programa de Napster (o seu apelido na universidade), fundou uma empresa com o mesmo nome e passou a distribuir o cliente de graça.



Middleware P2P

Um problema principal no projeto de aplicações P2P é o mecanismo que possibilita que clientes acessem recursos de dados rapidamente e com dependência de localização. O middleware P2P é desenvolvido de forma a tender o posicionamento automático e a localização de objetos distribuídos.

Requisitos funcionais: clientes comuniquem-se e localizem qualquer recurso disponível, adição e remoção de recursos e hosts, uma interface de programação simples.

Requisitos não-funcionais: escalabilidade global, balanceamento de carga, otimização de interações locais entre pontos vizinhos (distância de rede entre nós), acomodação para disponibilidade dinâmica do host (hosts podem sair ou entrar no sistema P2P sem qualquer aviso).



Camada de Roteamento (ou ouverlay)

O desenvolvimento de um middleware que atende aos requerimentos apresentados anteriormente é um tópico em constante estudo, mas dois sistemas significativos surgiram. Uma camada de roteamento é responsável por localizar nós e objetos. O middleware assume a forma de uma camada responsável por encaminhar requisições de clientes a um host que contém o objeto procurado, sendo que este pode ser relocado em outro host sem que o envolvimento do cliente. Ele assume que um nó pode acessar um objeto através do encaminhamento da requisição por uma seqüência de nós, baseando-se no conhecimento adquirido em cada nó a fim de localizar o objeto.



Figure 10.3: Distribution of information in a routing overlay

Object:

Node:

D

CÕs routing knowledge

DÕs routing knowledgeAÕs routing knowledge

BÕs routing knowledge

C

A

B



Tarefas

1. Um cliente desejando invocar uma operação em um objeto submete uma requisição com o GUID do objeto para a camada de roteamento, que encaminhará a requisição até alcançar um nó que contenha uma réplica do objeto.2. Um nó desejando tornar um novo objeto disponível calcula um GUID e anuncia na camada de roteamento, que assegura que o objeto seja alcançável pelos outros clientes.3. Quando os clientes requisitarem a remoção de um objeto, a camada de roteamento deve torná-lo indisponível.4. Nós podem entrar e sair do serviço. Quando entrar no serviço, a camada de roteamento busca algumas responsabilidades para ele. Quando sair, suas responsabilidades são redistribuídas.



Modelos

Modelo DHT: a GUID do objeto é gerada com uma função hash, usada para determinar o posicionamento e a localização, por isso, esses sistemas que usam uma camada de roteamento são conhecidos como tabelas hash distribuídas. Com isso, há três operações básicas, put (GUID, dados) para armazenar, remove (GUID) para remover todas as referências do objeto e get (GUID) para recuperar o objeto de um dos nós que o armazena.



Figure 10.4: Basic programming interface for a distributed hash table (DHT) as implemented by the PAST API over Pastry

put(GUID, data) The data is stored in replicas at all nodes responsible for the object identified by GUID.remove(GUID)Deletes all references to GUID and the associated data.value = get(GUID)The data associated with GUID is retrieved from one of the nodes responsible it.



Modelos

Modelo DOLR: outra forma, mais flexível, usa uma camada de roteamento e localização distribuída de objetos, sendo que ela é responsável por manter um mapeamento entre GUID e endereços dos nós onde as réplicas estão localizadas. Suas funções são publish (GUID) torna o objeto disponível, unpublish (GUID) torna o objeto indisponível e sendToObj (msg, GUID, [n]) envia uma mensagem ao objeto de forma a acessá-lo.



Figure 10.5: Basic programming interface for distributed object location and routing (DOLR) as implemented by Tapestry

publish(GUID ) GUID can be computed from the object (or some part of it, e.g. its name). This function makes the node performing a publish operation the host for the object corresponding to GUID.unpublish(GUID)Makes the object corresponding to GUID inaccessible.sendToObj(msg, GUID, [n])Following the object-oriented paradigm, an invocation message is sent to an object in order to access it. This might be a request to open a TCP connection for data transfer or to return a message containing all or part of the object’s state. The final optional parameter [n], if present, requests the delivery of the same message to n replicas of the object.



Estudos de caso de middleware de roteamento

a) Pastry: todos os nós e objetos podem ser acessados através de GUID de 128 bits. Em uma rede com N nós participantes, o Pastry irá encaminhar a mensagem endereçada a qualquer GUID em O (log n) passos. Caso o nó esteja ativo, a mensagem é encaminhada a ele; caso contrário, a mensagem é encaminhada ao nó com GUID mais próxima. Os passos de roteamento usam, normalmente, o UDP e transferem ao destino mais “próximo”, não em ternos físicos, mas em termos de um espaço artificial de GUID. Caso um nó entre no sistema, ele recebe todos os dados para construir uma tabela de roteamento e outras informações de estado dos membros existentes, se o nó falhar ou sair, os demais nós podem detectar sua ausência e se reconfigurar cooperativamente para refletir as mudanças ocorridas.



Pastry

O algoritmo de roteamento envolve o uso de uma tabela de roteamento em cada nó para encaminhar a mensagem de forma eficiente. Para propósitos de explicação, será apresentado o algoritmo de duas formas: 1) cada nó inicia com um vetor com as GUID e IP dos nós com GUID numericamente próximos. O espaço é tratado de forma circular (FIGURA 10.6). O processo é feito comparando a GUID da mensagem com as GUID que contém, e encaminhando para a GUID mais próxima numericamente, até alcançar a mensagem ao seu destinatário, evidentemente, em um processo ineficiente. 2) cada nó mantém uma tabela de roteamento e forma de árvore, GUID são valores hexadecimais classificados por seus prefixos. A tabela tem tantas linhas quantos dígitos houver na GUID, no Pastry são 32 linhas, e em cada linha há 15 entradas, uma para cada valor hexadecimal possível excluindo o valor GUID do nó.



Figure 10.6: Circular routing alone is correct but inefficientBased on Rowstron and Druschel [2001]

The dots depict live nodes. The space is considered as circular: node 0 is adjacent to node (2128-1). The diagram illustrates the routing of a message from node 65A1FC to D46A1C using leaf set information alone, assuming leaf sets of size 8 (l = 4). This is a degenerate type of routing that would scale very poorly; it is not used in practice.

0 FFFFF....F (2128-1)

65A1FC

D13DA3

D471F1

D467C4D46A1C



Figure 10.7: First four rows of a Pastry routing table



Figure 10.8: Pastry routing example Based on Rowstron and Druschel [2001]

0 FFFFF....F (2128-1)

65A1FC

D13DA3

D4213F

D462BA

D471F1

D467C4D46A1C

Routing a message from node 65A1FC to D46A1C.With the aid of a well-populated routing table themessage can be delivered in ~ log 16(N ) hops.



Pastry

O algoritmo usado se aproveita do apresentado anteriormente, ou seja, garante a entrega da mensagem, e usa a tabela de roteamento a fim de melhorar a eficiência de desempenho do algoritmo. O algoritmo está detalhado na FIGURA 10.9. A diferença entre as duas abordagens, 1 e 2, é que na primeira leva-se em conta apenas a proximidade do GUID que pode ou não ser localmente próximo, causando ineficiência, com o acréscimo da tabela de roteamento e a computação do prefixo do comprimento mais longo comum do GUID se reduz a quantidade de nós que a mensagem deva passar até alcançar o destino.



Figure 10.9: Pastry’s routing algorithm

To handle a message M addressed to a node D (where R[p,i] is the element at column i,row p of the routing table):

1. If (L-l < D < Ll) { // the destination is within the leaf set or is the current node.2. Forward M to the element Li of the leaf set with GUID closest to D or the current

node A.3. } else { // use the routing table to despatch M to a node with a closer GUID4. find p, the length of the longest common prefix of D and A. and i, the (p+1)th

hexadecimal digit of D.5. If (R[p,i] ° null) forward M to R[p,i] // route M to a node with a longer common

prefix.6. else { // there is no entry in the routing table7. Forward M to any node in L or R with a common prefix of length i, but a

GUID that is numerically closer.}

}



Pastry

Outros aspectos do Pastry: uso de algoritmo de vizinho mais próximo, através de recursividade sobre o conjunto de nós armazenados; localidade com uma estrutura altamente redundante, com mais de uma rota entre dois pares de nós; tolerância a falhas contra quedas eventuais (usando a abordagem “at-least-once”, causando envio repetidos de mensagens) e contra usuários maliciosos; uso de conhecimento acerca de dependências, como no caso em que uma mensagem é enviada a um host que não responde, assim, o nó que envio a mensagem começa a considerá-lo um host suspeito; etc.



Tapestry

b) Tapestry: implementa uma tabela hash distribuída e encaminha mensagens baseando-se na associação de GUID similarmente como o Pastry o faz. A diferença é que ele usa o modelo DOLR, enquanto o Pastry usa o DHT, apresentado anteriormente. Isso dá ao Tapestry maior flexibilidade porque pode posicionar réplicas em distâncias próximas reduzindo a latência e minimizando a carga na rede ou garantindo tolerância a falhas. O identificador usado é de 160 bits, contudo GUID é usado apenas para recursos, enquanto computadores têm um NODEID. O processo usado para publicação de recursos nos hosts está na FIGURA 10.10.



Figure 10.10: Tapestry routing From [Zhao et al. 2004]

4228

4377

437A

4361

43FE

4664

4B4F

E791

4A6D

AA9357EC

4378PhilÕsBooks

4378PhilÕsBooks

(Root for 4378)

publish path

Tapestry routingsfor 4377

Location mappingfor 4378

Routes actually taken by send(4378)

Replicas of the file PhilÕs Books (G=4378) are hosted at nodes 4228 and AA93. Node 4377 is the root nodefor object 4378. The Tapestry routings shown are some of the entries in routing tables. The publish paths showroutes followed by the publish messages laying down cached location mappings for object 4378. The locationmappings are subsequently used to route messages sent to 4378.



Estudos de caso de aplicações

a) Squirrel Web Cachê: dos mesmos desenvolvedores do Pastry. As formas de caching de navegadores internet podem ser servidas no cachê da máquina cliente, de um proxy ou do próprio servidor HTTP. Quando uma página é requisitada, há três possibilidades, ou a página não pode ser cacheada, ou ela não se encontra na cachê (cachê miss) ou ela se encontra. Neste último caso, a página é testada para saber se é atual, ou usando uma data de última modificação, ou o tempo de vida, ou uma eTag.



Squirrel

O sistema Squirrel usa o mecanismo de cachê semelhante ao de um proxy web com o uso de uma pequena porção de recurso das máquina na rede para realizar o cachê. Inicialmente, o GUID do objeto é computado formando um número de 128 bits, e, na forma mais simples de implementação, o objeto é armazenado no host cujo GUID é o mais próximo do GUID do objeto. Se a cópia no cachê não for atualizada ou o objeto desejado não estiver na cachê, Squirrel encaminha uma mensagem de Get para o nó inicial, se este por sua vez não possuir nenhuma cópia do objeto encaminha uma mensagem de Get para o nó servidor.



Squirrel

Squirrel é avaliado sob três ópticas que levaram os seus projetista a concluir que seu desempenho é igual a de um cachê centralizado:Redução da largura de banda usada – inversamente proporcional a quantidade de acertos na cachê.Latência percebida pelos usuários no acesso aos objetos web – maior quantidade de mensagens encaminhada através da camada de roteamento.Carga computacional e de armazenamento imposta – baixo consumo de recursos.



OceanStore File Store

b) OceanStore File Store: dos mesmos desenvolvedores do Tapestry, é um protótipo de um armazém de arquivos P2P com suporte a arquivos mutáveis. Tem replicação, com mecanismo de consistência de réplicas, privacidade e integridade. Um protótipo chamado Pond foi desenvolvido que usa o mecanismo de roteamento Tapestry a fim de colocar blocos de dados em nós distribuídos pela internet e encaminhar requisições a eles.

Os objetos são semelhantes a arquivos, compostos de blocos. Contudo, cada objeto é uma seqüência ordenada de versões imutáveis que, a princípio, são mantidas para sempre. A cada atualização no objeto, uma nova versão é gerada, armazenando apenas os blocos distintos entre a última versão e a nova. O esquema de organização com acesos mediante um bloco de metadados chamado bloco raiz e blocos adicionais de direção se necessários



Figure 10.11: Storage organization of OceanStore objects

d1 d2 d3 d5d4

root block

version i indirection blocks

d2

version i+1

d1 d3

certificate VGUID of currentversion

VGUID ofversion i

AGUID

VGUID of version i-1

data blocks

BG

UID

(co

py

on

wri

te)

Version i+1 has been updated in blocks d1, d2 and d3. The certificate and the root blocks include some metadata not shown. All unlabelled arrows are BGUIDs.




Existem três formas de GUID usadas (FIGURA 10.12), BGUID o hash de um bloco de dado, VGUID o BGUID do bloco raiz da versão e AGUID que unicamente identifica todas as versões do objeto. Com uso destes três GUID diferentes, é possível acessar as novas versões de um objeto, ou versões anteriores, ou mesmo blocos de dados específicos de um objeto em qualquer uma de suas versões. Usa-se um certificado assinado a fim de assegurar a autentica associação entre as cadeias de referência de um objeto, sendo assim, um certificado conterá a VGUID da nova versão, junto a um timestamp e um número seqüencial de versão.



Figure 10.12: Types of identifier used in OceanStore

Name Meaning Description

BGUID block GUID Secure hash of a data block

VGUID version GUID BGUID of the root block of a version

AGUID active GUID Uniquely identifies all the versions of an object




A construção de um certificado é combinada entre um pequeno conjunto de hosts chamado anel interno, o novo certificado substituí a antiga cópia primária nestes hosts, e é então disseminada para um grande número de cópias secundárias.

A atualização de dados envolve o consenso de todos os hosts do anel interno associado ao objeto. Além disso, esse processo envolve checagem dos direitos de acesso e serialização da atualização com quaisquer escritas pendentes.



Ivy File System

c) Ivy File System: é um sistema de escrita/leitura de arquivos com suporte para múltiplos leitores e escritores implementado sobre uma camada de roteamento. Alguns problemas:Manutenção da consistência dos arquivos com atualizações concorrentes de múltiplos hosts sem uso de bloqueio porque a falha de um nó ou da conectividade da rede causaria bloqueio perpétuo; confiança parcial entre os participantes e vulnerabilidade nos ataques a máquinas participantes; e continua operação durante partição da rede que pode resolver em atualizações conflitantes.



Ivy File System

O nó cliente tem instalado um processo servidor Ivy que usa uma DHash para armazenar e acessar registros de log nos nós baseado em GUID (FIGURA 10.14). Um armazém de dados Ivy consiste em um conjunto de logs atualizados, um por participante, cada participante pode ler de todos os logs, mas escrever apenas no seu próprio. Usam-se vetores de versão a fim de impor uma ordenação total das entradas de log quando lidos múltiplos logs, entretanto, um algoritmo para uma simples leitura teria desempenho ruim. Para melhorar o desempenho, usam-se cachê local e snapshots, representações do sistema de arquivos computadas e armazenadas localmente por cada participante.

Como há um processo servidor por nó participante, atualizações são feitas em separado, sem coordenação com outros servidores. A serialização é feita no momento da leitura dos blocos, de forma a construir o conteúdo do arquivo. Integridade dos dados é assegurada.



Figure 10.14: Ivy system architecture

DHash server

ModifledNFS Client

module

Ivy server DHash server

Application

Kernel

Ivy node

DHash server

DHash server

DHash server

Application



Resumo

Arquiteturas P2P foram primeiramente apresentadas em sistemas de compartilhamento de dados de larga escala, como Napster e seus descendentes. Pesquisas subseqüentes desenvolveram um middleware P2P que encaminha requisições aos objetos aonde quer que estejam na internet. O endereçamento envolve o uso de GUID, o posicionamento dos objetos de acordo com uma função de mapeamento específica do middleware, e a entrega é realizado por uma camada de roteamento no middleware. Esta camada também adiciona integridade baseada no uso de funções hash segura para geração do GUID e disponibilidade baseado em réplicas de objetos e algoritmos de tolerância a falhas.

Benefícios: exploração de recursos inutilizados, escalabilidade com balanceamento de carga e independência do número de clientes e hosts. Fraquezas: uso de armazenamento para dados mutáveis é mais caro que o uso de um servidor centralizado e o anonimato ainda não é totalmente garantido.



eMule



O que é?

eMule (Mula Eletrônica) é um programa de troca de arquivos que é baseado na Rede P2P eDonkey2000, mas oferecendo mais recursos do que o cliente padrão (eDonkey) porque é um programa que código fonte aberto (open source), facilitando assim que programadores do mundo inteiro possam fazer novas implementações e modificações visando à melhoria do programa à cada nova versão.

http://www.edonkey2000.com/



Como funciona o emule

O eMule funciona à partir de conexões à servidores existentes no mundo inteiro, feitos por usuários do eMule com um programa específico para isto. Outra vantagem é que no eMule o arquivo tem um código hash e com isso o eMule consegue distinguir separadamente cada arquivo e criar um link próprio para cada arquivo para ser indexado em fóruns e sites indexadores (como o: http://www.pootz.org/ e http://www.sharereactor.com/), e com isso facilitar a localização de um lançamento e a eliminação de arquivos falsos (fake) na rede.

http://www.pootz.org/

http://www.sharereactor.com/



Capacidades

Tem que saber primeiramente a velocidade da conexão. Os valores para a velocidade são dados geralmente em por kilo bits por o segundo [ kb/s ], mas deverá saber os valores para inserir no eMule em kilo Bytes por o segundo [ kB/s ].Exemplo:Máximo de Download: kB/s de 256kb/s ÷ 8 = 32Máximo de Upload: kB/s de 128kb/s ÷ 8 = 16A velocidade depende muito da conexão.



Porta do Cliente

O eMule usa a porta 4662 como porta padrão. Mude-a somente se você estiver recebendo mensagem de ID BAIXO (LOW ID) ou se esta porta estiver fechada pelo Provedor, isto fará com que os dados não saiam ou entrem no seu router ou modem.



Arquivos

Arquivos completos: Especifique o diretório onde serão movidos os downloads concluídos. Padrão Incoming;Arquivos Temporários: Especifique o diretório onde são armazenados os downloads em andamento. Padrão Temp;Diretórios compartilhados: Aqui você pode especificar



Servidores Estáticos

São servidores que podem ser adicionados aoarquivo staticservers.dat que ficam pra sempreno eMule e você pode adicionar e remover quando quiser.O método mais fácil seria quando você colocar um servidor e ver que ele é um servidor bom.



ID

Um ID ALTO significa que a porta escolhida nas preferências - > conexões (padrão 4662) está aberta e livremente acessível.Um ID BAIXO significa que esta porta esta bloqueada ou não pode ser alcançada. Isto pode ser causado pelo provedor, por routers ou por usuários de proxy.Um ID BAIXO é um valor menor que 16777216.Ter um ID baixo não significa que não haverá upload ou download, mas terá diversas desvantagens como: baixa quantidade de fontes encontradas, limites de usuários em servidores com ID BAIXO, 2 clientes com ID BAIXO não podem se conectar, perda de conexões com usuários, etc.Se você tiver usando um Firewall (programa usado para bloquear invasões), você poderá ter um ID BAIXO (Low ID)



Mods

Como o eMule é um programa de código fonte aberto, algumas pessoas ou um grupo (EX: Plus, Tarod...etc) fazem alterações na versão Oficial do eMule, implementando novas funções. Essas alterações trazem novas funções muito interessantes que ajudam muito no download dos arquivos.Esse é o forum oficial do eMule sobre os novos MODs: eMule Mods

http://www.emule-project.net/board/index.php?s=51194be65db734571a900cdf44d1e331&act=SF&f=15





BitTorrent



BitTorrent

O BitTorrent é uma tecnologia criada por Bram Cohen que permite o compartilhamento de qualquer tipo de arquivo pela internet, sendo muito usado para a distribuição de vídeos, músicas e programas. Sua forma de trabalho é muito eficaz e evita, por exemplo, que determinados usuários só façam download, mas não compartilhem arquivos (pelos menos teoricamente). Isso porque a taxa de download é equivalente à taxa de upload, ou seja, somente compartilhando é que você consegue baixar arquivos. Por esta razão, quando você está iniciando um determinado download, a velocidade utilizada é lenta e vai aumentando de acordo com o que já foi baixado do arquivo. Quanto mais você tiver de um arquivo, mais usuários se conectarão ao seu computador e pela regra, a taxa de velocidade do seu download aumenta.



Como Funciona

Na verdade, o BitTorrent é um protocolo, que, como já dito, permite o compartilhamento de qualquer tipo de arquivo. Devido a isso, o BitTorrent não pode ser considerado um software para fins ilegais (como foi o pioneiro Napster, por permitir a distribuição de músicas no formato MP3), pois qualquer pessoa pode usar o protocolo para distribuir arquivos. Existem até empresas que compartilham seus softwares por este meio. Apenas como exemplo, suponha que Professor Mario criou um e-book. Além de disponibilizá-lo em um site, ele pode distribuí-lo pelo BitTorrent e isso não fere nenhuma lei de proteção à propriedade intelectual. Se conteúdo ilegal é distribuído pelo serviço, a responsabilidade é dos usuários e não do programa.



Como Funciona

Para que você possa fazer download (e upload) pelo BitTorrent, é necessário que cada item compartilhado esteja associado a um arquivo denominado torrent, cuja extensão é.torrent (por exemplo, mestrado.torrent). Trata-se de um arquivo pequeno, mas que contém as informações necessárias para o compartilhamento, como o local onde o arquivo está e a seqüência que verifica a integridade do mesmo. Esse arquivo pode estar disponível em um site e quando acessado, inicia o download do arquivo compartilhado (desde que o BitTorrent esteja instalado). Isso significa que você precisa achar um torrent do arquivo que você deseja baixar. Não há uma caixa de busca como a usada no kaZaA, por exemplo. Para encontrar torrents você pode usar sites voltados a este fim. Um dos mais conhecidos atualmente é o http://www.torrentreactor.net/, que separa os torrents em categorias.

http://www.torrentreactor.net/



Termos do Torrent

Seed (ou seeding): é a denominação dada ao computador que possui um arquivo completo compartilhado, como o computador que primeiramente disponibilizou o arquivo e os outros que o baixaram por inteiro;Peer: nome dado a cada computador que compartilha arquivos. Leech (ou leeching): é a denominação dada ao momento em que um computador faz download;Tracker: denominação dada ao servidor que é responsável por organizar os arquivos disponíveis e direcionar os downloads;Swarm: nome dado ao conjunto de computadores que estão compartilhando o mesmo arquivo. Se, por exemplo, o arquivo infowester.pdf está sendo compartilhado por 2 seeds e por 8 peers, o swarm do arquivo contém 10 computadores (2 seeds + 8 peers).



Exemplo



Resumo

O BitTorrent é muito útil, versátil, e atualmente, o responsável por 35% do tráfego de dados na Internet, número maior que o de todos os demais compartilhadores de arquivos somados! A questão acerca da legalidade do mesmo é algo que ainda será muito discutido, mas uma coisa é certa: se bem utilizado, o BitTorrent promove benefícios para todo mundo: servidores menos carregados, e internautas fazendo downloads a boas velocidades.

Peer-to-Peer Systems From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design...

Documents

Transcript of Peer-to-Peer Systems From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design...