Peer-to-Peer Systems
From Coulouris, Dollimore and Kindberg
Distributed Systems:
Concepts and Design
Edition 4, © Addison-Wesley 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.1: Distinctions between IP and overlay routing for peer-to-peer
applications
Scale
Load balancing
Network dynamics
(addition/deletion of
objects/nodes)
Fault tolerance
Target identification
Security andanonymity
IP
Application-level routing overlay
IPv4 is lim ited to 232 addressable nodes. The
IPv6 name space is much moregenerous
(2128), but addresses in both versions are
hierarch ically structured and much of the space
is pre-allocated according to administrative
requirements.
Loads on routers are determined by network
topologyand associated traffic patterns.
Peer-to-peer systems can addressmore objects.
The GUID name space is very largeand flat
(>2128), allowing it to be much morefully
occupied.
Object locations can be randomized and hence
traffic patterns are divorced from the network
topology.
IP routing tables are updated asynchronously on Routing tables can be pudated synchronously or
a best-efforts basis with time constants onthe asynchronously with fractions of a second
order of 1 hour.
delays.
Redundancy is designed into the IP network by Routes and object references can be replicated
its managers, ensuring tolerance of a single
n-fold, ensuring tolerance of n failures of nodes
router or network connectivity failure. n-fold
or connections.
replication is costly.
Each IP address maps to exactly one target
Messages can be routed to the nearest replica of
node.
a target object.
Addressing is only secu
re when all nodes are
Security can be achieved even in environments
trusted. Anonymity for the owners ofaddresses with limited trust. A limited degree of
is not achievable.
anonymity can be provided.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.2: Napster: peer-to-peer file sharing with a centralized,
replicated index
pee rs
Napste r se rv er
Inde x
1. File locati on
req uest
2. List of peers
offering the file
Napste r se rv er
Inde x
3. File req uest
5. Index update
4. File deli vered
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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).
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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).
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.3: Distribution of information in a routing overlay
AÕs r outing knowledg e DÕs r outing knowledg e
C
A
D
B
Obj ect:
Node:
BÕs r outing knowledg e
CÕs r outing knowledg e
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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ó.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.6: Circular routing alone is correct but inefficient
Based on Rowstron and Druschel [2001]
0 FFFFF....F ( 2128-1)
D471F1
D467C4
D46A1C
D13DA3
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.
65A1FC
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.7: First four rows of a Pastry routing table
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.8: Pastry routing example Based on Rowstron and Druschel [2001]
Routing a mess age from node 65A1FC to D46A1C.
With the ai d of a wel l-popul ated routing table the
mes sage c an be del ivered i n ~ log16 (N ) hops .
0 FFFFF....F ( 2128 -1)
D471F1
D46A1C
D467C4
D462BA
D4213F
D13DA3
65A1FC
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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 levase 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.9: Pastry’s routing algorithm
To hand l e a mess ag eM add res sed to a no dD
e (where R[p ,i] is th e el ement at col umn i,
ro w p o f t h e rou t in g tab l e):
1 . If (L -l < D < L l) { // th e dest in at io n is wit h in th e leaf set o r is th e cu rren t n od e.
2.
ForwardM t o th e elemen tL i o f t h e l eaf s et wit h GUID clo ses tD
t oo r th e cu rren t
n od eA.
3 . } el se { // u se th e ro u tin g tab le to d es p atM
ch t o a n o de wi th a cl os er GUID
4.
fi nd p , t he l en gt h of th e lo n gest commo n p refi x ofD and A. an d i, th e (p +1 )th
h exad ecimal d i gi t oD.
f
5.
If (R[p ,i] ° n ul )l fo rwardM t o R[p ,i] // ro ut eM t o a n o de wi th a lo ng er co mmo n
p refix.
6.
else { // t here is n o en try in t he ro u ti ng t ab le
7.
Forward M t o an y no d e inL o r R wi th a co mmon p refix o f l en g thi, bu t a
GUID t h at is n umerically clo ser.
}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.10: Tapestry routing
From [Zhao et al. 2004]
4377 (Root for 4378)
Tapestr y r outings
for 4377
437A
43FE
publish path
Locati on mappi ng
for 4378
4228
4378
Phil Õs
Books
4361
4664
4A6D
4B4F
Routes actually
taken by se nd(4378)
E791
57EC
AA93
4378
Phil Õs
Books
Replic as of the fil ePhil Õs Book(G=4378)
s
are hosted at nodes 4228 and AA93. Node 4377 i s the root node
for obj ec t 4378. T he T apes try routings shown are some of the entries i n routing tables. The publ is h paths s how
routes followed by the publ ish mess ages layi ng down c ached location mappings for object 4378. T he l oc ation
mappi ngs are s ubsequentl y used to route mess ages s ent to 4378.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.11: Storage organization of OceanStore objects
AGUID
BGUID (copy on write)
VGUID of current
version
certificate
version i+1 VGUID of
version i
d1
d2
d3
d2
d3
root block
version i
Ver sion i+1 has been updated in blocks d1,
d2 and d3. The certificate and the root
blocks incl ude some metadata not shown.
All unlabel led arr ows ar e BGUIDs.
indirection blocks
data blocks d1
VGUID of version i-1
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
d4
d5
OceanStore File Store
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
OceanStore File Store
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 10.14: Ivy system architecture
Ivy node
DHash server
Application
Application
DHash server
Ivy ser ver
DHash server
DHash server
Modifled
NFS Cli ent
modul e
DHash server
Ker nel
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
eMule
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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 = 32
Máximo de Upload: kB/s de 128kb/s ÷ 8 = 16
A velocidade depende muito da conexão.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Servidores Estáticos
São servidores que podem ser adicionados ao
arquivo staticservers.dat que ficam pra sempre
no 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
BitTorrent
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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).
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Exemplo
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005