Arquiteturas de Sistemas Distribuídos

Prévia do material em texto

Prof. Luiz Fernando Bittencourt IC - UNICAMP 
MC714 
Sistemas Distribuídos 
2° semestre, 2013 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas 
• Componentes de sistema distribuído espalhados 
por diversas máquinas. 
• Controle demanda organização. 
• Organização lógica do software e organização 
física dos componentes. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Software 
• Componentes de software constituem o sistema. 
• Arquitetura de software 
• Como vários componentes estão organizados 
• Como devem interagir 
• Arquiteturas centralizadas, arquiteturas 
descentralizadas, arquiteturas híbridas 
• Separar aplicações das plataformas subjacentes: 
middleware 
• Várias técnicas para alcançar transparência, e 
que afetam o próprio middleware 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Software – sistemas autonômicos 
• Também é possível conseguir adaptabilidade 
fazendo o sistema monitorar seu próprio 
comportamento. 
• Sistemas autonômicos 
• Realimentação de informação 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Estilos arquitetônicos 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Estilos arquitetônicos 
• Organização lógica do sistema em componentes 
de software – arquitetura de software 
• Estilo arquitetônico: componentes, modo como 
estão conectados, dados trocados, como são 
configurados para formar o sistema 
• Componente: unidade modular com interfaces 
requeridas e fornecidas bem definidas; 
substituível. 
• Conector: mecanismo que serve de mediador da 
comunicação entre componentes. 
•  Facilidades para chamadas de procedimento (remotas), passagem 
de mensagem, fluxo de dados. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Estilos arquitetônicos 
• Várias configurações usando componentes e 
conectores. 
• Arquitetura em camadas. 
• Arquiteturas baseadas em objetos. 
• Arquiteturas centradas em dados. 
• Arquiteturas baseadas em eventos. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura em camadas 
• Um componente da camada Li tem permissão de 
chamar componentes na camada subjacente Li-1 , 
mas não o contrário. 
• Adotado em redes. 
• Em geral requisições descem pela hierarquia, 
resultados sobem. 
• Fig. 31. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura baseada em objetos 
• Cada objeto, em essência, corresponde a um 
componente. 
• Conexão através de chamada de procedimento 
remota. 
• Se ajusta à arquitetura cliente-servidor. 
• Fig. 32. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura centrada em dados 
• Processos se comunicam por um repositório 
comum. 
• Em sistemas distribuídos, tão importante quanto 
camadas e objetos. 
• Muitas aplicações se comunicam por escrita/
leitura de arquivos compartilhados. 
• Sistemas web possuem processos que se 
comunicam por meio de serviços de dados web. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura baseada em eventos 
• Processos se comunicam por meio de 
propagação de eventos que podem transportar 
dados. 
• Associado a sistemas publish/subscribe. 
• Processos publicam eventos; middleware 
transmite somente para assinantes. 
• Processos fracamente acoplados; não precisam 
se referir explicitamente uns aos outros. 
• Fig. 33. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura baseada em eventos 
• Pode ser combinada com arquiteturas centradas 
em dados, resultando em espaços 
compartilhados de dados. 
•  Processos desacoplados no tempo: não precisam ambos estarem 
ativos para realizar comunicação. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de software 
• Visam obter nível razoável de transparência de 
distribuição. 
• Compromisso entre desempenho, tolerância a 
falha, facilidade de programação. 
•  Dependente de requisitos/aplicações: não há um sistema para 
cobrir tudo. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de sistema 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura de sistema 
• Onde são colocados os componentes de 
software. 
• Centralizada, descentralizada, híbrida. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura centralizada 
• Processos divididos em dois grupos: clientes e 
servidores. 
• Servidor implementa um serviço específico. 
• Cliente requisita um serviço enviando uma 
requisição e aguarda resposta. 
• Clientes requisitam serviços de servidores. 
• Comportamento de requisição-resposta. 
• Fig. 34. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura centralizada 
• Cliente-servidor pode ser implementado por meio 
de um protocolo simples de comunicação se rede 
é confiável. 
• Empacota mensagem identificando serviço 
desejado junto com dados necessários. 
• Mensagem é enviada; servidor aguarda 
requisição, processa e empacota resultados em 
uma mensagem de resposta. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura centralizada 
• Aplicação: protocolo de comunicação. 
• Confiabilidade versus eficiência; sem conexão, 
com conexão; retransmissão. 
•  Depende da aplicação. 
• Retransmissão de mensagem: transfira R$1.000 da 
minha conta. 
• Retransmissão de mensagem: qual o saldo da minha 
conta? 
•  Operação repetida sem danos: idempotente. 
• Diversas maneiras de tratar falhas, dependendo do tipo 
de mensagem perdida. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquitetura centralizada 
• Muitos sistemas utilizam protocolos confiáveis orientados 
à conexão. 
•  TCP/IP. 
• Primeiro estabelece conexão, depois envia requisição. 
• Servidor pode usar a mesma conexão para enviar 
resposta. 
• Conexão pode ser caro. 
•  Estabelecer e encerrar conexão pode ocupar maior parte do 
tempo, principalmente se mensagens de requisição e resposta são 
pequenas. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Camadas de aplicação 
• Cliente-servidor: quem é quem? 
• Ex: banco de dados recebe consultas, mas 
somente realiza requisições a sistemas de 
arquivos que implementam as tabelas. 
•  Banco de dados apenas faz consultas. 
• Muitas aplicações cliente-servidor visam dar 
suporte aos usuários de bancos de dados: três 
níveis. 
•  1. Interface de usuário – interação. 
•  2. Nível de processamento – aplicação. 
•  3. Nível de dados – gerência dos dados. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Camadas de aplicação 
•  Interface: 
•  Tela baseada em caracteres (terminal). 
• X-windows. 
• Processamento: 
•  Busca web: palavra chave, ordenar resultados, fazer consultas aos 
bancos de dados. 
•  Análise de dados financeiros: estatística + IA. 
• Dados 
•  Dados persistentes. 
•  Geralmente no lado do servidor. 
•  Manter consistência de dados (triggers). 
•  Muito comum ser banco de dados relacional. 
•  Fig 35.a 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas multidivididas 
• 3 níveis lógicos: várias possibilidades para 
distribuição física de uma aplicação no modelo 
cliente-servidor. 
• Mais simples: 
•  2 tipos de máquinas: cliente com interface e servidor com 
processamento e dados. 
•  Cliente é “terminal burro”. 
• Arquitetura de 2 divisões. 
•  Fig. 35.b 
• Outras possibilidades. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas multidivididas 
• Tendência a retirar processamento e 
armazenamento do cliente. 
•  Mais problemáticas para gerenciar/atualizar. 
•  Mais software no cliente = mais propenso a erros. 
• Clientes gordos / clientes magros. 
• Clientes magros: não precisamos mais de sistemas 
distribuídos? 
•  SD muda para o lado do servidor. 
• Arquiteturas de 3 divisões (em termos físicos). 
•  Servidor web repassa requisição para servidor da aplicação 
(processamento), consulta BD. 
•  Fig 36. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas descentralizadas 
• Arquiteturas multidivididas: conseqüência da divisão de 
aplicação em interface/processamento/dados. 
• Em muitos ambientes, organização de aplicações cliente-
servidor é feita em arquiteturasmultidivididas: distribuição 
vertical. 
•  Componentes logicamente diferentes em máquinas diferentes. 
•  Relação com fragmentação vertical: tabelas de BD subdivididas 
em colunas e distribuídas. 
•  Divisão lógica e física: cada máquina executa grupo específico de 
funções 
• Distribuição horizontal 
•  Servidor/cliente divididos em partes logicamente equivalentes. 
•  Cada parte operando sobre seu próprio conjunto de dados. 
•  Distribuição de carga. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas descentralizadas 
• Peer-to-peer (P2P): distribuição horizontal. 
• Não há servidor sempre ligado. 
• Sistemas finais comunicam-se diretamente. 
• Peers intermitentemente conectados e mudam de 
endereço. 
• Ex: distribuição de arquivos (bitTorrent), streaming 
(KanKan), VoIP (Skype). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cliente servidor versus P2P 
• Quanto tempo para distribuir arquivo de tamanho F para 
N clientes: cliente-servidor versus P2P. 
•  Fig. 37. 
• Cliente-servidor: envia sequencialmente N cópias. 
•  Servidor: 
•  tempo para enviar 1 cópia: F/us 
•  tempo para enviar N cópias: NF/us 
•  Cliente: cada cliente faz o download 
•  dmin = taxa de download mínima entre os clientes. 
•  Tempo de download do cliente mais lento: F/dmin 
Tempo para distribuir F 
para N clientes usando 
cliente-servidor Dc-s > max{NF/us,,F/dmin} 
Aumenta linearmente 
em N 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cliente servidor versus P2P 
• P2P: 
•  Servidor: upload de pelo menos uma cópia – tempo F/us 
•  Cliente: cada cliente faz o download de uma cópia 
•  Tempo de download do cliente mais lento: F/dmin 
•  Clientes: download agregado de NF bits 
•  Taxa máxima de upload: us + Σui 
Tempo para distribuir F 
para N clientes usando 
P2P DP2P > max{F/us,,F/dmin,,NF/(us + Σui)} 
Aumentam linearmente em N 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cliente servidor versus P2P 
• Upload cliente = u, F/u = 1 hora, us = 10u, dmin ≥ us 
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
M
in
im
um
 D
is
tri
bu
tio
n 
Ti
m
e P2P
Client-Server
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas descentralizadas 
• Peer-to-peer (P2P): distribuição horizontal. 
• Processos que constituem o sistema são todos iguais. 
•  Funções necessárias são executadas por todos. 
•  Interação simétrica: cliente e servidor ao mesmo tempo. 
• Como organizar os peers? Rede de sobreposição 
(overlay). 
•  Nós são processos; enlaces são canais de comunicação lógicos. 
•  Em geral, processo não pode se comunicar diretamente com outro 
processo arbitrário: deve obedecer overlay. 
•  Redes de sobreposição: estruturadas e não estruturadas. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas descentralizadas 
• Arquiteturas P2P estruturadas: 
•  Rede de sobreposição é construída com a utilização de um 
procedimento determinístico. 
•  Mais utilizado: tabela hash distribuída (distributed hash table – 
DHT). 
•  Ex.: Chord, CAN, Pastry, Tapestry 
• Arquiteturas P2P não estruturadas: 
•  Algoritmos aleatorizados para construir a rede de sobreposição. 
•  Idéia é que cada nó mantenha lista de vizinhos, mas que essa lista 
seja construída de modo que envolva alguma aleatorização. 
•  Localização de item pode depender de inundação da rede. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas P2P estruturadas 
• Rede de sobreposição construída com procedimento 
determinístico. 
• Mais comum: Distributed Hash Table (DHT) 
•  Itens de dados recebem identificador (128, 160 bits...). 
• Nós do sistema também recebem identificador, no mesmo 
espaço de identificadores. 
• Ponto crucial: implementar um esquema eficiente e 
determinístico de mapeamento de chaves para 
identificadores de nós. 
• Consulta a um item deve retornar o endereço do nó 
responsável pelo item. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas P2P estruturadas 
• Como atribuir chaves aos peers? 
•  Idéia básica: 
•  Converter cada chave em um inteiro. 
•  Atribuir inteiro a cada peer. 
•  Colocar par (chave, valor) no peer mais próximo à chave. 
• Atribuir identificador inteiro para cada peer no intervalo 
[0,2n-1] para algum n. 
•  Cada identificador de nó tem n bits. 
• Requer que cada chave esteja no mesmo intervalo. 
• Para obter chave, usar função hash. 
•  Ex.: chave = hash (“Pink Floyd – Dark Side of the Moon”). 
•  Daí vem o nome de tabela hash distribuída. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Chord (Stoica et al., 2003) 
• Nós organizados logicamente em um anel - DHT circular. 
• Regra: atribuir chave ao peer com ID mais próximo. 
•  Item de dado com chave k mapeado em nó com menor 
identificador id >= k. 
•  Denominado nó sucessor da chave k: suc(k). 
• Consulta: Lookup(k) deve retornar endereço de suc(k). 
• Cada peer conhece sucessor e predecessor imediatos 
em uma rede de sobreposição. 
•  Fig. 38. 
• Outras: CAN, Pastry, Tapestry, Kademlia, Ulysses, Koorde 
(grafos de DeBruijn) 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Chord (Stoica et al., 2003) 
• O(N) mensagens na média para resolver consulta. 
0001 
0011 
0100 
0101 
1010 
1100 
1111 
Responsável pela 
chave 1110 ? 
Eu 
1110 
1110 
1110 
1110 
1110 
1110 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
DHT Circular com atalhos 
• Cada peer conhece sucessor, predecessor e atalhos. 
• Redução de 6 para 2 mensagens. 
• É possível desenhar atalhos para que existam O(log(n)) 
vizinhos, O(log(n)) mensagens em consultas. 
1 
3 
4 
5 
8 
10 
12 
15 
Responsável pela 
chave 1110? 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Peer churn 
• Peers entram e saem da rede (churn). 
• Cada peer conhece seus dois sucessores. 
• Cada peer “pinga” seus dois sucessores para verificar se 
continuam online. 
• Se o sucessor imediato sai, realoca segundo sucessor 
como imediato. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Peer churn 
•  Peer 5 sai. 
•  Peer 4 transforma 8 em seu sucessor imediato e pergunta ao 8 qual 
é seu sucessor. 
•  Peer 4 torna sucessor de 8 (10) seu segundo sucessor. 
1 
3 
4 
5 
8 
10 
12 
15 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Peer churn 
•  Peer 13 quer entrar: gera um identificador (aleatório) id. 
•  Consulta algum nó qual ponto da rede deve entrar: quem será seu 
sucessor e predecessor. 
•  Transferência das responsabilidades de dados de 15 para 13. 
1 
3 
4 13 
8 
10 
12 
15 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
CAN – Content Addressable Network 
• Espaço de coordenadas cartesianas de d dimensões 
particionado entre os nós. 
•  Fig 48. 
• Espaço bidimensional [0,1]x[0,1] dividido entre 6 nós. 
• Cada nó tem uma região associada. 
• Cada item de dados em CAN é atribuído um único ponto 
desse espaço, vinculando um nó responsável pelo dado. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
CAN – Content Addressable Network 
• Entrada de um nó P em CAN: 
•  Escolhe ponto arbitrário no espaço de coordenadas; 
•  Pesquisa o nó Q “dono” daquela região (utilizando roteamento 
baseado em posicionamento); 
•  Nó Q subdivide sua região em duas metades e atribui metade a P; 
• Nós monitoram seus vizinhos, responsáveis por regiões 
adjacentes. 
• Na subdivisão, P sabe quem são seus vizinhos 
perguntado a Q. 
•  Itens de dados são transferidos de Q para P. 
•  Fig. 49 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
CAN – Content Addressable Network 
• Saída de nó de CAN: 
•  Saída do nó (0,6; 0,7). 
•  Região é designada a um de seus vizinhos, por exemplo (0,9; 0,9). 
•  Vizinho escolhido toma conta da região do nó que saiu. 
•  Torna repartição menos simétrica: repartição do espaço inteiro por 
um processo de fundo. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Redes P2P não estruturadas 
• Dependem, em grande parte, de algoritmos 
aleatórios para construir overlay. 
•  Idéia: cada nó tem uma lista de vizinhos 
construída de modo (mais ou menos)aleatório. 
•  Itens podem ser colocados aleatoriamente nos 
nós – Balls and bins. 
• Encontrar item = inundar a rede com consulta de 
busca. 
• Rede parecida com grafo aleatório. 
• Ex.: Gnutella, Freenet 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Redes P2P não estruturadas 
• Cada nó mantém uma lista de vizinhos vivos (visão 
parcial). 
• Nós podem trocar regularmente entradas de suas 
visões parciais. 
• Pode-se usar 2 threads, uma de “modo ativo” (push) 
e uma de “modo passivo” (pull). 
•  Modo ativo: empurra entradas para peers vizinhos 
selecionados. 
•  Modo passivo: aguarda nó enviar as entradas. 
• Só ativo ou só passivo pode resultar em redes 
desconexas. 
• É preciso também apagar entradas velhas. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Redes P2P não estruturadas 
• Pull ou push isoladamente podem resultar em 
redes desconectadas. 
•  Melhor que nós troquem entradas de suas visões parciais. 
• Nó quer se juntar ao grupo: contata nó arbitrário, 
possivelmente de lista de nós bem conhecidos e com alta 
disponibilidade. 
• Saída de nó, caso haja troca de visões parciais: nó sai 
sem informar qualquer nó. É removido das visões parciais 
dos seus vizinhos na próxima atualização. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Gerenciamento de topologia 
• Estruturado e não estruturado podem não ser 
estritamente independentes. 
• Troca e seleção cuidadosa de entradas de visões 
parciais pode levar a topologias específicas. 
• Adoção de abordagem de duas camadas. 
• Fig 50. 
Camada inferior: p2p não estruturado com troca de 
visões parciais. 
• Camada superior: seleção adicional de entradas 
para gerar topologia desejada. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Gerenciamento de topologia 
• Por exemplo, camada superior: função de 
ordenação onde nós são ordenados de acordo 
com certo critério. 
•  Ordenar conjunto de nós em ordem crescente de distância em 
relação a um determinado nó P. 
•  Nó P gradativamente montará uma lista de seus vizinhos mais 
próximos, desde que a camada inferior continue enviando nós 
selecionados aleatoriamente. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Gerenciamento de topologia 
•  Jelasity e Babaoglu [2005]. 
• Grade lógica NxN, um nó em cada ponto. 
•  Lista de c vizinhos mais próximos por nó, onde distância 
entre nó (a1,a2) e (b1,b2) é d1+d2, com di = min (N-|ai-
bi|, |ai – bi|). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Redes P2P não estruturadas 
• Podem ser usadas funções de ordenação de 
diversas maneiras. 
• Ex.: funções com captura de proximidade 
semântica de nós. 
• Construção de redes semânticas de 
sobreposição. 
• Algoritmos de busca eficientes em P2P não 
estruturados. 
 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Superpeers 
• Busca em P2P não estruturado pode ser 
ineficiente e não escalável. 
• Alternativa é usar superpares. 
• Nós especiais que mantém um índice de itens de 
dados e/ou agem como intermediários. 
• Outras situações convém abandonar simetria de 
sistemas P2P. 
•  Rede colaborativa de entrega de conteúdo (Content Delivery 
Network – CDN) - armazenamento de páginas por nós para 
permitir acesso rápido a páginas próximas. 
•  Nó que coleta informações sobre nós das proximidades permite 
seleção de quem tem recursos suficientes para armazenar 
conteúdo acessado. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Superpeers 
• Busca em P2P não estruturado pode ser 
ineficiente e não escalável. 
• Alternativa é usar superpares. 
• Nós especiais que mantém um índice de itens de 
dados e/ou agem como intermediários. 
• Outras situações convém abandonar simetria de 
sistemas P2P. 
•  Rede colaborativa de entrega de conteúdo (Content Delivery 
Network – CDN) - armazenamento de páginas por nós para 
permitir acesso rápido a páginas próximas. 
•  Nó que coleta informações sobre nós das proximidades permite 
seleção de quem tem recursos suficientes para armazenar 
conteúdo acessado. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Superpeers 
• Superpares podem ser organizados em uma rede 
P2P à organização hierárquica. 
• Fig. 39. 
• Par comum conectado a superpar. 
• Relação cliente-superpar fixa, em geral: conecta-
se a um superpar e permanece até sair da rede. 
•  Superpares: longa vida com alta disponibilidade. 
• Associação fixa pode não ser melhor abordagem 
•  Melhor cliente se ligar a um superpar com índices que sejam 
próximos ao seu interesse. 
•  Garbacki et al. (2005) à nós associam-se preferencialmente a 
superpares que retornam um resultado de consulta para o nó. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Superpeers 
• Novo problema: como selecionar nós para serem 
superpares. 
• Estreita relação com eleição de líder em sistemas 
distribuídos. 
• Exemplo: Skype/NAT 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas híbridas 
• Combina mais de um tipo de arquitetura, por ex. 
cliente-servidor e P2P 
• Exemplo: sistemas de servidor de borda 
•  “Borda da rede” – fronteira entre as redes corporativas e a Internet, 
como fornecido por um provedor de serviço de Internet (ISP). 
•  Fig. 51. 
•  Servem conteúdo e otimizam distribuição de conteúdo e de 
aplicação. 
•  Também comum em sistemas distribuídos colaborativos. 
• Cliente-servidor utilizado para nós conectarem-se ao 
sistema, depois utilizam esquema descentralizado. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas híbridas 
• Ex.: BitTorrent – sistema de download de 
arquivos. 
• Fig. 40. 
• Transfere pedaços (chunks - 256kb) de arquivos 
até completar o arquivo. 
•  Importante garantir colaboração. 
• Usuário acessa diretório global – sites web – 
referências aos arquivos torrent. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
BitTorrent 
• Torrent contém informações sobre rastreador 
(tracker). 
•  Servidor que mantém lista de nós ativos que tem o arquivo 
requisitado. 
•  Ativo = transferindo algum arquivo para outro nó. 
• Peer entrando em um torrent: 
•  Não possui pedaços, mas obtém com o tempo. 
•  Recebe do rastreador lista de peers daquele torrent e se conecta a 
alguns (vizinhos). 
•  Enquanto baixa, também faz upload. 
•  Pode trocar os peers com quem realiza transferências. 
•  Peer pode sair da rede assim que obtém arquivo inteiro. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
BitTorrent 
• Requisição de pedaços: 
•  Peers diferentes têm subconjuntos diferentes de pedaços. 
•  Periodicamente, usuário requisita lista de pedaços de seus 
vizinhos. 
•  Em seguida, requisita pedaços faltantes de seus vizinhos – mais 
raro primeiro. 
• Enviando pedaços – “tit-for-tat” 
•  Usuário envia pedaços a vizinhos que estão enviando a ele com a 
maior taxa. 
•  Outros peers param de receber dados desse usuário. 
•  Re-avalia os “top 4” a cada 10 segundos. 
•  A cada 30 segundos seleciona aleatoriamente outro peer e 
começa a enviar pedaços. 
•  “Desafoga” de forma otimista esse peer. 
•  Novo peer pode se juntar ao “top 4”.