Mvc model view controller - java para desenvolvimento web
P2P - Sistemas Distribuídos
1. SISTEMAS
DISTRIBUÍDOS
ACADÊMICOS: Anderson dos Santos Ferreira,
Jaqueline Nardes, Valdir Pereira da Silva Junior.
Sistemas para
Internet
PEER TO PEER
P2P
PROFESSOR: THALES
DUARTE
2. INTRODUÇÃO
Quando falamos em peer to peer, a primeira
coisa que nos vem a mente é compartilhamento,
porém muitos de nós não tem ideia de como
isso é feito ou de como isso foi possível.
Em uma breve História, veremos como
chegamos hoje a distribuição de informações e
outros serviços explorados por aplicativos P2P.
3. NAPSTER E SEU LEGADO
INTRODUÇÃO AO NAPSTER
Napster [OpenNap 2001] é um sistema peer-to-peer
que fornecia um meio para os usuários
compartilharem arquivos. Napster se tronou
popular para a troca de musicas, logo após seu
lançamento em 1999, vários milhões de
usuários estavam registrados trocando arquivos
de musicas.
6. NAPSTER DESATIVADO
Nota: O Napster foi desativado por causa de
resultados de ações jurídicas contra os
operadores do serviço Napster, impetradas
pelos proprietários dos direitos autorais de parte
do material.
7. LIÇÕES APRENDIDAS COM O
NAPSTER
Praticidade na construção de um serviço de
larga escala, que depende de dados e
computadores de usuários normais;
Evita o esgotamento dos recursos
computacionais levando em conta o caráter
local da rede;
8. LIMITAÇÕES
O Napster usava um índice unificado de todos
os arquivos disponíveis e não fazia checagem
de versão. Para arquivos como músicas digitais,
isto não era um problema, pois as músicas
nunca são atualizadas, mas para alguns outros
tipos de arquivos (como softwares) isto era um
problema.
9. CRONOLOGIA
Janeiro de 1999: Shawn Fanning abandona a universidade para
desenvolver o software que ganharia o nome de Napster.
Junho de 1999: O Napster entra no ar possibilitando de uma
maneira simples que usuários compartilhassem músicas em
formato mp3.
Agosto de 1999: O tio de Fanning, John Fanning, juntamente com
outros investidores, oferece um acordo para gerenciar o Napster.
Outubro de 1999: As negociações para distribuição de música
online com as gravadoras não obtêm sucesso.
Dezembro de 1999: A RIAA exige US$100 mil por música baixada
por quebra dos direitos autorais.
Fevereiro de 2000: Várias universidade dos EUA proíbem o uso do
Napster em seus computadores.
Abril de 2000: A banda Metallica entra com ações contra o Napster
por distribuir suas canções de forma ilegal.
Maio de 2000: Em resposta aos processo, o Napster mostra que
está disposto a colaborar, banindo mais de 300 mil usuários que
compartilham músicas da banda
10. Junho de 2000: A RIAA entra com um mandado de segurança para
bloquear material compartilhado de grandes selos.
Julho de 2000: A empresa anuncia planos para cooperar com as
gravadoras. Um juiz estabelece um prazo de 48 horas para que o Napster
pare de permitir que músicas com copyright sejam compartilhadas.
Agosto de 2000: Madonna entra com um processo contra o site por
divulgar as faixas de seu álbum "Music", sem autorização e um mês antes
do lançamento oficial.
Outubro de 2000: A Napster anuncia parcerias para pagar os artistas cujas
músicas são compartilhadas no site.
Março de 2001: Um filtro é instalado nas buscas do Napster para bloquear
o download de arquivos listados pelas gravadoras.
Julho de 2001: A Justiça proíbe todos os downloads de arquivos no site, a
menos que o filtro funcione 100%.
Novembro de 2002: O Napster é comprado pela Roxio por US$ 5,2
milhões.
Atualidade: Hoje, o Napster vende arquivos de música digital que
respeitem o direito autoral.
Junho de 2001: Chega a Portugal o Napster
Setembro de 2013: Chegada do Napster no Brasil.
11. MIDDLEWARE
Middleware – é uma espécie de mediador. No
campo da computação distribuída é um
programa que faz a mediação entre softwares
diferentes. É usado para transportar
informações e dados entre programas de
diferentes protocolos de comunicação,
plataformas e dependências do sistema
operacional.
12. MIDDLEWARE PEER-TO-PEER
São projetados especificamente para atender
a necessidades da disposição automática, e
da subsequente localização, dos objetos
distribuídos gerenciados por sistemas e
aplicativos peer-to-peer.
13. REQUISITOS FUNCIONAIS
Permitir aos clientes localizarem e se
comunicarem com qualquer recurso individual
disponibilizado para um serviço, mesmo que
os recursos estejam amplamente distribuídos
entre os hosts;
Capacidade de adicionar novos recursos e
remove-los a vontade;
Adicionar hosts no serviço e remove-los;
Deve oferecer uma interface de programação
simples para programadores de aplicações.
14. REQUISITOS NÃO FUNCIONAIS
Escalabilidade global – deve ser projetado de modo a suportar
aplicativos que acessam milhões de objetos em dezenas ou
centenas de milhares de hosts;
Balanceamento de carga - deve ser projetado para explorar um
grande numero de computadores com distribuições de carga de
trabalho balanceadas entre eles;
Otimização das interações locais entre peers vizinhos – deve ter
como objetivo colocar os recursos próximos dos nós que mais os
acessam;
Acomodar a disponibilidade altamente dinâmica de hosts – o
sistema deve redistribuir cargas e recursos toda a vez que um host
entra ou sai do sistema.
Segurança dos dados em um ambiente com confiança heterogênea
– confiança deve ser estabelecida por mecanismos de autenticação
e criptografia, para garantir a integridade e a privacidade da
informação;
Anonimato, capacidade de negação e resistência a censura – os
hosts que contem dados devem ser capazes de negar a
responsabilidades por conte-los ou fornecê-los de forma plausível.
15. SOBREPOSIÇÃO DE
ROTEAMENTO
Temos dois tipos de sobreposição de
roteamento, estruturado e não estruturado.
Estruturado:
Constituída de procedimentos determinísticos,
onde o processo mais usado é através de um
DHT – tabela de hash distribuída, que distribui
uma chave aleatória, um identificados de 128
ou 160 bits.
O DHT faz um mapeamento único da chave
de um item para o identificador do nó
responsável pelo item desejado.
17. SOBREPOSIÇÃO DE
ROTEAMENTO
Não estruturado:
Funciona com um algoritmo que faz
requisições para localizar nós e objetos
(routing overlay), direcionando qualquer
cliente para um host que contenha suas
solicitações, sendo que estas solicitações
podem estar alocadas em qualquer nó da
rede, dessa forma garante que qualquer nó
pode acessar qualquer objeto por meio de
roteamento de cada requisição.
19. TAREFA PRINCIPAL DE UMA
SOBREPOSIÇÃO DE
ROTEAMENTO
Solicitar via GUID (Globally Unique
Identifier), identificador único universal, uma
operação ao qual direciona a requisição para
um nó que tenha uma réplica do objeto que se
deseja.
O GUID é calculado a partir do estado do
objeto ou parte dele, usando uma função que
produz um valor de probabilidade muito alto
de ser exclusivo.
20. COMUNICAÇÃO DE
PROCESSOS
Processo:
Programa que é executado em um
hospedeiro.
Os processos no mesmo hospedeiro se
comunicam usando a comunicação entre
processos definida pelo sistema operacional
(SO).
Processos em hospedeiros distintos se
comunicam trocando mensagens através da
rede.
Processo cliente: Processo que inicia a
21. ENDEREÇANDO OS
PROCESSOS
Para que um processo receba mensagens, ele
deve possuir um identificador.
Cada host possui um endereço IP único de 32
bits.
Pergunta: O endereço IP do host no qual o
processo está sendo executado é suficiente
para identificar o processo?
Resposta: Não, muitos processos podem estar
executando no mesmo host.
22. IDENTIFICADOR
Porém para que o processo seja identificado é
necessário que:
O identificador inclua tanto o endereço IP
quanto os números das portas associadas
com o processo no host.
Exemplo de números de portas:
Servidor HTTP: 80
Servidor de Correio: 25
23. PROTOCOLOS DA CAMADA
DE APLICAÇÃO
Para que dois processos se comuniquem, eles
devem trocar mensagens.
Tipos de mensagens trocadas: Mensagens de
pedido e resposta.
Sintaxe dos tipos das mensagens: Campos
presentes nas mensagens e como são
identificados.
Semântica dos campos: Significado da
informação nos campos.
Regras para quando os processos enviam e
respondem às mensagens.
24. PROTOCOLOS PÚBLICOS E
PROPRIETÁRIOS
Protocolos de domínio público:
Definidos em RFCs.
Permitem a interoperação.
HTTP e SMTP
Protocolos proprietários:
Napster, Emule
LimeWare, Utorrent
25. ARQUITETURA DO SISTEMA
Com relação a arquitetura temos 3 tipos.
Centralizada.
Descentralizada.
Híbrida.
Sendo que hoje em dia o P2P pode ser
descentralizada ou híbrido, já que como vimos a
ideia de centralizar o mesmo acabou gerando
processos judiciais ao Napster, sua distribuição
é horizontal, onde o cliente e o servidor se
equivalem para equilibrar as cargas(conjunto de
dados).