Espaço de Tuplas

Um espaço de tuplas é um espaço de memória compartilhado globalmente e distribuído por todos os processos e hosts participantes. Os processos que usam este modelo se comunicam gerando tuplas e antituplas que são submetidas ao espaço de tuplas. Tuplas são dados estruturados tipados, como por exemplo, objetos em C++ e Java, onde cada tupla é formada por uma coleção de campos de dados tipados e representa uma parte coesa da informação. Em um sistema baseado em espaço de tuplas, todas as comunicações interprocesso são exclusivamente realizadas utilizando o espaço de tuplas e qualquer processo que usa um espaço de tuplas possui a habilidade para acessar todas as tuplas que o espaço contém, inserir dinamicamente novas tuplas gerando antituplas destrutivas associadas. Sistemas baseados em espaços de tuplas provaram sua habilidade para facilitar a comunicação em configurações sem fio. Esta forma de comunicação é bastante adequada às configurações móveis onde estão envolvidas a mobilidade lógica e a física.

Fonte:
http://www.maxwell.lambda.ele.puc-rio.br/cgi - bin/PRG_0599.EXE/9181_3.PDF?NrOcoSis=28128&CdLinPrg=pt

Maicon N. de Souza 104170132

Técnicas de Escalabilidade

ESCONDER A LATÊNCIA NA COMUNICAÇÃO:

Contruir a aplicação de forma a utilizar somente comunicação assícrona,
em aplicações batch e paralelas normalmente é bem aceita mas o mesmo não ocorre em aplicações interativas; neste caso, uma solução é diminuir a necessidade de comunicação movendo parte da computação do servidor para cliente.

REPLICAÇÃO:

Aumenta a disponibilidade e ajuda a balancear a carga de trabalho entre componentes
levando a um melhor desenpenho.

Caching é uma forma especial de replicação na qual a decisão de trazer o objeto é de
seu cliente e não de seu proprietário.

Pode levar a ploblemas de consistência.

Escalabilidade

A escalabilidade incorpora os limites físicos à questão do desempenho. Como se comporta o desempenho quando atingimos os limites físicos das máquinas, e que estratégias devemos utilizar para aumentar a quantidade de processamento disponível.
Duas são as linhas mestras para atingir maior escalabilidade: o incremento com novos hardwares ou a substituição por novos hardwares de maior desempenho.
O primeiro é denominado escalabilidade horizontal. O exemplo típico é um farm Web, onde podemos incorporar novas máquinas ao farm para dar conta do aumento da demanda pelos usuários finais.
O segundo é a escalabilidade vertical, onde uma nova máquina mais possante substitui a antiga.

http://msdn.microsoft.com/pt-br/library/cc518051.aspx

Espaço de tuplas - Thiago Rodrigues 104170032

Um espaço de tuplas tem como função criar uma abstração de memória compartilhada sobre um sistema distribuído. Por propiciar modelos de programação muito simples e com baixo acoplamento entre os elementos do sistema, espaços de tuplas têm sido empregados na construção de sistemas distribuídos complexos.
O espaço de tuplas cria uma “ilusão” de que existe um espaço compartilhado entre os objetos no sistema distribuídos.
Modelo de Memória com operações de escrita e leitura.
Sistemas distribuídos tem no espaço de tuplas uma memória comum onde todos podem ler e escrever no mesmo.
É baseado no padrão blackboard onde todos podem ler, escrever e apagar o quadro-negro.


LINK: www.teses.usp.br/teses/disponiveis/ 55/55134/tde-08032003-012015/


Thiago Rodrigues
104170032

Técnicas de escalabilidade - Thiago Rodrigues 104170032

Escalabilidade significa adicionar hardware para manter e melhorar a performance de uma solução.
A escalabilidade garante a qualidade de serviço desejada à medida que a demanda de uso aumenta.

Quando um sistema não consegue atender a sua demanda num determinado tempo, significa que ele ultrapassou o seu limite de escalabilidade, sendo necessário adicionar mais hardware no sistema, onde entra as técnicas e escalabilidade:

Escalabilidade Vertical: Adicionar hardware as máquinas já existentes. Menor custo, porém não tão eficiente.

Escalabilidade horizontal: Adicionar computadores ao sistema. Maior custo e eficiente.

Escalabilidade Diagonal: Aplica-se as duas técnicas acima.


http://msdn.microsoft.com/pt-br/library/cc518051.aspx
http://ladoservidor.com/node/12

Thiago Rodrigues
104170032

Escalabilidade

RESUMO: Escalabilidade é uma característica desejável em todo o sistema, em uma rede ou em um processo, que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para o crescimento do mesmo. Por exemplo, isto pode se referir à capacidade de um sistema em suportar um aumento de carga total quando os recursos (normalmente do hardware) são requeridos.

A Escalabilidade, como característica de um sistema, é normalmente difícil de se definir e de forma particular é necessário definir que requerimentos específicos de demanda deverão ser dimensionados para definir a importância da escalabilidade.A escalabilidade é um assunto extremamente importante em sistemas eletrônicos, bancos de dados, roteadore, redes de computadores , etc, e implica desempenho.

Um sistema cujo desempenho aumenta com o acréscimo de hardware, proporcionalmente à capacidade acrescida, é chamado "sistema escalável".

Origem: Wikipédia - http://pt.wikipedia.org/wiki/Escalabilidade

Uso de Virtualização de Recursos Computacionais na Administração de Redes

Resumo: Escalabilidade significa adicionar hardware para manter e melhorar a performance de uma solução. Entretanto, apenas adicionar mais hardware pode não representar ganho de performance por parte da aplicação. Neste artigo, apresentar – se técnicas como o “Xen” e o “VMware” para que Tal habilidade seja vantajosa para um aproveitamento eficiente do hardware disponível.

Introdução

A virtualização de recursos computacionais é um tema recorrente em trabalhos de pesquisa e desenvolvimento envolvendo diversas áreas da computação. A abstração oferecida pelas máquinas virtuais permite mapear recursos reais de uma mesma arquitetura às necessidades de diferentes sistemas e aplicações, contribuindo para a flexibilidade, a portabilidade, a interoperabilidade, a segurança e a gerenciabilidade de sistemas de software,
Em um ambiente virtualizado, as tarefas de gerenciamento, escalonamento e alocação dos recursos disponíveis são executadas por um Monitor de Máquinas Virtuais(MMV). Este monitor virtualiza o hardware existente, oferecendo uma interface individual para cada máquina virtual, permitindo desta forma uma execução transparente e independente de uma arquitetura específica, sendo muito útil para administradores que buscam a consolidação de seus sistemas, aproveitando ao máximo o hardware disponível; alem de proporcionar um sistema mais seguro que nos casos em que os serviços executam todos sobre o mesmo sistema físico.
Dentre as soluções de virtualização mais populares atualmente, destacam-se Xen e VMware, ambas voltados à arquitetura Intel IA32.

Monitores de Máquinas Virtuais

O conceito de virtualização foi amplamente pesquisado e utilizado no início da década de 70, permitindo o compartilhamento dos recursos computacionais dos grandes mainframes entre as máquinas virtuais existentes, hoje obtém um melhor aproveitamento do alto poder computacional dos computadores modernos sendo utilizada como uma forma de interligar tecnologias. Neste contexto, a
virtualização constitui uma solução capaz de garantir a interoperabilidade entre tecnologias, de forma que o hardware virtualizado, independente da forma de implementação, possa ser acessado através de uma camada de abstração oferecida por um monitor de máquinas virtuais.
Um monitor de máquinas virtuais (MMV) é um sistema responsável pelo gerenciamento e alocação dos recursos do sistema hospedeiro entre diversas máquinas virtuais, podendo ser implementados utilizando virtualização clássica ou virtualização hospedada:

v Na implementação virtualização clássica, o monitor de máquinas virtuais é executado diretamente sobre o hardware possuindo o nível mais alto de privilégio de execução de instruções. Neste modelo, todas as chamadas de sistema são interceptadas pelo MMV para posteriormente serem executadas.

v Na implementação hospedada o monitor de máquinas virtuais executa sobre um sistema operacional existente, utilizando o nível mais baixo de privilégios. Neste modelo de implementação, o MMV utiliza tradução binária em tempo de execução para adaptar as instruções que necessitam de um maior nível de privilégios.
Xen

O monitor de máquinas virtuais Xen é baseado na abordagem clássica de
implementação de virtualização, onde o MMV possui o nível mais alto de privilégio;
o monitor Xen utiliza a técnica de paravirtualização para adaptar a execução dos sistemas operacionais virtualizados. Através da paravirtualização, Xen garante que os sistemas virtualizados não tenham acesso direto aos recursos disponíveis, permitindo desta forma uma virtualização eficiente sobre a arquitetura Intel x86.
A implementação do monitor Xen é dividida especificamente entre o monitor de máquinas virtuais (hypervisor) e os domínios Xen, que são a representação das máquinas virtuais existentes. Nesta abordagem, as máquinas virtuais são gerenciadas através de chamadas realizadas para um domínio especial, denominado Domain0, através do qual é possível inicializar e terminar máquinas virtuais. Internamente, o monitor Xen utiliza os recursos do Domain0 para ter acesso ao hardware e gerenciar a alocação de memória entre os demais domínios, a independência de hardware obtida pelo monitor Xen permite que máquinas virtuais sejam encapsuladas e migradas entre computadores com arquitetura virtualizada. Este processo de migração pode ser efetuado sem a interrupção dos serviços em execução sobre o sistema operacional virtualizado, tornando assim uma ferramenta auxiliar para administradores de redes e servidores permitindo a manutenção do hardware do computador hospedeiro quando necessário.

Vmware

O monitor de máquinas virtuais Vmware é utilizando a técnica de virtualização hospedada. O sistema é dividido em VMApp, que é a máquina virtual que executa no espaço de usuário do sistema operacional hospedeiro e VMDriver, que é um software que executa junto ao sistema operacional hospedeiro e processa as requisições feitas pelo VMApp.
A máquina virtual provida por VMware apresenta ao sistema operacional hospedado um conjunto fixo de dispositivos, como interfaces de vídeo, áudio e rede, o que anula a necessidade de desenvolvimento de novos controladores por parte do sistema operacional hospedado. Sempre que o sistema hospedado faz uma um acesso a algum dispositivo virtual, o MMV salva o contexto da máquina virtual e muda para o seu contexto (world switch), onde é feito o acesso ao dispositivo real e retornando ao contexto da máquina virtual assim que a requisição estiver completa. Utilizando essa arquitetura, VMware pode ser utilizado para executar a maioria dos sistemas operacionais disponíveis no mercado, sem necessitar de alteração do código dos mesmos.
A migração de uma máquina virtual para outro sistema hospedeiro é possível, porém com interrupção momentânea do sistema. É feita uma cópia da memória utilizada pela máquina virtual para o novo hospedeiro, bem como o estado atual da máquina virtual e o arquivo com as configurações do BIOS virtual. O sistema de arquivos da máquina virtual precisa estar armazenado em algum sistema de armazenamento compartilhado, como por exemplo um sistema de armazenamento conectado à rede - NAS.

Virtualização de Recursos e o Gerenciamento de Redes

Em ambientes distribuídos para a computação de alto desempenho, a virtualização surge como um mecanismo auxiliar na administração de clusters de computadores e grades computacionais. Em ambientes que necessitam
de gerenciamento eficiente de redes e servidores, uma arquitetura virtualizada
permite que diversas tecnologias sejam interligadas, auxiliando em diversas tarefas de administração dos recursos.
Servidores que utilizam virtualização oferecem vantagens em diversos aspectos como segurança e integridade dos processos em execução através da utilização de monitores de máquinas virtuais. Um exemplo de utilização de virtualização é encontrado nos servidores IBM Power5, onde a virtualização é explorada para garantir independência e integridade dos serviços em execução através da transparência obtida com a utilização de máquinas virtuais.
Um servidor que utilize virtualização de recursos permite que cada máquina virtual
hospede um serviço independente das demais, garantindo através do isolamento de hardware que as falhas ocorridas em um serviço não se propaguem para os demais.

Conclusão

Escalabilidade significa adicionar hardware para manter e melhorar a performance de uma solução.Entretanto, apenas adicionar mais hardware pode não representar ganho de performance por parte da aplicação, por isso o uso de ferramentas de virtualização vem se tornando popular em ambientes distribuídos. A virtualização permite executar múltiplos sistemas operacionais em um mesmo computador hospedeiro, cada qual com sua própria visão da arquitetura física subjacente. Tal habilidade é vantajosa para um aproveitamento eficiente do hardware disponível, além de trazer benefícios do ponto de vista da administração de sistemas. Alem de explorar as tecnologias de virtualização em sistemas em rede, com ênfase nas ferramentas Xen e Vmware.
Maicon Nascimento de Souza 104170132
Fonte:
http://www-usr.inf.ufsm.br/~boufleur/artigos/errc2006-xen.pdf

Escalabilidade e eficiência em descoberta do conhecimento em grandes volumes de dados

Escalabilidade e eficiência em descoberta do conhecimento em grandes volumes de dados

A troca de informação e a informação propriamente dita se mostra bastante importante nos dias de hoje. Ela deve ser bem organizada e manuzeada por poderosas máquinas inteligentes. Vivemos hoje uma grande dificuldade de sobrecarga de informação, ou seja, temos muitas informações que podem ser significantes, e pouco tempo, ou capacidade computacional insuficiente para avaliá-la adequadamente. Descobrir novos e poderosos mecanismos para organizar, encontrar e analisar essa informação é essencial para encarar esse problema.
Porém, observamos também uma tendência de evolução dos mecanismos computacionais para os grandes sistemas distribuídos. Pois temos uma tendência forte para processamento paralelo. Os padrões de programação paralela e os respectivos ambientes de programação se expõem bastante inadequados para assegurar a escalabilidade e a eficiência de implementações paralelas de muitas aplicações atuais. Aplicações essas que chamamos de irregulares, já que a demanda computacional é fortemente dependente dos dados de entrada, podendo variar significamente em funções deles.
Desta forma consideramos que a extração automatizada de informações se mostra como um desafio para uma significativa parcela da comunidade de ciência da computação, abrangendo desde as arquiteturas dos computadores e das redes que os conectam até a sua aplicação a um contexto específico, passando por novos algorítimos e a sua paralelização.

FONTE: http://www.ic.unicamp.br/~cmbm/desafios_SBC/wagnermeira.pdf

Ivonei Silva Nunes/ 106040332

Escalabilidade

A escalabilidade pode ser medida em três dimensões:
1. Relação ao tamanho --> Podem-se acrescentar mais usuários e recursos ao sistema;
2. Relação à distância geográfica --> Acesso a distâncias maiores.
3. Relação à facilidade de administração --> Mesmo com inclusão muitas organizações independentes ainda continua fácil a administração.

Problemas de escalabilidade

1. Relação ao tamanho
--> Servidores centralizados
--> Dados centralizados
--> Algoritmos centralizados

Uma máquina tem informação completa sobre o estado do sistema, ou as máquinas tomam decisões baseadas em informações de outros nós, ou uma falha de um nó pode arruinar o algoritmo, ou assume-se que existe um relógio global.

Mas por vezes é inevitável ter centralização (dados confidenciais de bancos, etc.).

2. Relação à distância geográfica
Em LANs é comum usar comunicação síncrona --> o cliente envia o pedido e fica bloqueado à espera de uma resposta.
Numa WAN a comunicação pode durar três ordens de grandeza mais (centenas de milisegundos);
Se uma aplicação tem componentes centralizados fica também limitada em termos geográficos.

3. Relação à facilidade de administração
São necessários dois tipos de medidas de segurança quando o sistema distribuído se expande para um novo domínio:
--> O sistema tem de se proteger de ataques vindos do novo domínio;
--> O domínio tem de se proteger de ataques vindos do sistema distribuído.

Técnicas de escalabilidade
Três técnicas principais:
1. Esconder latência na comunicação
2. Distribuição
3. Replicação.

1. Esconder latência na comunicação
Usar comunicação assíncrona para evitar bloquear processos à espera de receber respostas.
--> Tratamento de respostas como eventos;
--> Usar várias tarefas em paralelo para continuar processamento. Na figura acima: Passar parte do processamento do servidor para o cliente melhora a escalabilidade geográfica.

2. Distribuição
Distribuir entre vários computadores os serviços e dados. Decompondo os componentes em partes menores, que são distribuídas por todo o sistema distribuído. Exemplos: DNS e Web
Nenhum servidor prestará todos os serviços nem possuirá todos os dados.
Se um servidor falhar, nem tudo está perdido.

3. Replicação
Aumenta a disponibilidade dos serviços e melhora o balanceamento de carga no sistema.
Aumenta a disponibilidade do serviço nas zonas da rede onde há réplicas.
Caching é uma forma de replicação controlada pelo cliente. A existência de várias cópias pode levar a problemas de consistência.
Se for necessário ter garantias fortes de consistência tem de se atualizar as cópias imediatamente (ex: Internet banking).

Francino Neto \ 103041061
Sistemas Distribuídos

Fonte: http://tele1.dee.fct.unl.pt/rit2_2007_2008/teo/4_sist_dist.pdf

questões para fixação

Exercícios para Fixação
1 - O que são sistemas distribuídos?
2 - O que é um middleware? Como podemos apresentá-lo graficamente?
3 - Acesso a recursos remotos é uma das metas de sistemas dsitribuídos. Qual o benefício de tal se compartilhar recursos?
4 - o que é um sistemas trasnparente?
5 - Diga e explique quais os tipos de transparencias de distribuição.
6 - Porque a transparencia de falha é uma das questões mais difíceis de Sistemas Distribuídos?

Stella: Sistema de Backup Peer-to-Peer

Resumo

O artigo escolhido tem como objetivo introduzir uma nova abordagem dentro da pesquisa em redes p2p.

Stella é o sistema proposto por esse artigo. Trata-se de um sistema de backup descentralizado baseado em redes p2p estruturadas e não estruturadas. Tal sistema propõe uma nova maneira de conectar Nós e mostra que é possível utilizar o melhor dos dois modelos p2p mais utilizados para a construção de soluções mais eficientes e coesas.

Introdução

O Stella consiste em um sistema para o armazenamento transparente de backup de arquivos utilizando redes peer-to-peer (p2p), visando aproveitar recursos computacionais ociosos existentes na rede e proporcionar um meio confiável de armazenamento e persistência de dados, que possa ser acessado a partir de qualquer lugar de forma transparente e de fácil utilização para o usuário.

Implementação

A rede estruturada utilizada no Stella é baseada no DKS (N; k; f) [Alima, L. et. all2003], que corresponde a uma família de infra-estrutura p2p com grande escala, tolerante a falhas e com baixa comunicação desenvolvida para construir aplicações peer-to-peer.

A diferença principal entre o DKS e o Chord, reside no fato de o Chord utilizar um modelo de correção ativa que realiza um procedimento de tempos em tempos em toda a rede para identificar os Nós que saíram e que entraram e atualizar os seus ponteiros. Esse procedimento possui um alto e desnecessário custo de comunicação. O DKS, no entanto, utiliza um modelo baseado em correção sob demanda que trata o problema quando ele ocorre, esse modelo diminui bastante o número de comunicações para gerenciamento da rede, tornando então o DKS mais eficiente.

O Stella utiliza uma implementação do DKS baseada em Java bastante simples: o JDHT. O JDHT implementa a interface java.util.Map, o que torna o seu uso bastante simples e intuitivo.

Fonte: http://www.lbd.dcc.ufmg.br:8080/colecoes/wp2p/2006/st2_1.pdf

Chrystiano Barbosa S. Araújo

Código Fonte da Aula Sobre Socket

Pessoal, estou disponibilizando os códigos do cliente e do servidor feitos em java utilizando Socket.
Criem essas classes porque continuaremos a utilizá-las na próxima aula.
Um abraço,
Izalmo
cliente.java

import java.io.IOException;
import java.io.PrintStream;
import java.net.Socket;
import java.net.UnknownHostException;
public class Cliente {
Socket cliente;
public Cliente()
{
try {
cliente = new Socket("127.0.0.1",4321);
PrintStream saida = new PrintStream(cliente.getOutputStream());
saida.print("Aula de Sistemas Distribuídos Fializada!");
} catch (UnknownHostException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
try {
cliente.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
public static void
main(String[] args)
{
new Cliente();
}
}
servidor.java
import java.io.DataInputStream;
import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;
public class Servidor
{
ServerSocket servidor;
public Servidor()
{
try {
servidor = new ServerSocket(4321);
} catch (IOException e) {
e.printStackTrace();
}
System.out.println("Bem Vindo!");
while (true)
{
try {
Socket cliente = servidor.accept();
System.out.println("Ip:"+cliente.getInetAddress());
DataInputStream dis = new DataInputStream(cliente.getInputStream());
System.out.println(dis.readLine());
} catch (IOException e) {
e.printStackTrace();
}
System.out.println("Requisição Recebida!");
}
}
public static void
main(String[] args)
{
new Servidor();
}
}

Redes P2P: Middleware X-Peer e Aplicações P2P

Redes P2P vem sendo uma área de constante pesquisa e evolução, mostrando o interesse da comunidade num modelo de paradigma diferente do mais utilizado normalmente – cliente-servidor. O middleware XPeer torna-se bastante interessante com o objetivo de divulgar a tecnologia, estimulando assim o desenvolvimento de aplicações P2P. Aqui são apresentados, entre outras coisas, estudos relacionados à viabilidade de se utilizar o Chord.

A computação peer-to-peer (P2P) tem promovido uma grande modificação nos padrões de uso da Internet nos últimos anos. Sua grande vantagem, em relação à computação cliente/servidor, é possibilitar a colaboração e acesso direto entre os usuários e seus recursos, mesmo que as máquinas estejam escondidas atrás de firewalls e NATs, sem a dependência de uma organização central ou hierárquica, dispondo aos seus integrantes as mesmas capacidades e responsabilidades.

Um sistema P2P puro é totalmente descentralizado e se subdivide em sistemas puros estruturados e não estruturados, que se diferenciam, respectivamente, pela capacidade de recuperar todas as informações disponíveis na rede ou apenas parte delas. Exemplos de sistemas estruturados são os sistemas baseados em tabelas hash distribuídas (DHT – Distributed Hash Tables), como Chord, Pastry, Tapestry e CAN.

Foi proposto o middleware X-Peer, que define um novo modelo de arquitetura que utiliza o melhor dos modelos P2P citados. O X-Peer utiliza o conceito de super-nós que se comunicam através de uma rede estruturada baseada em DHT [10]. Isto garante ao X-Peer os benefícios da escalabilidade e robustez.

Dentre os algoritmos analisados para ser utilizado neste sistema estão o Chord, o Pastry e a plataforma JXTA. O Pastry apresentou a melhor opção de implementação, fica encapsulada sob uma interface genérica DHT, e, portanto, pode ser substituída por outra solução DHT que forneça a mesma API, como o Chord.

O X-Peer foi desenvolvido com o objetivo de construir um mecanismo para facilitar o desenvolvimento de aplicações P2P. Entretanto, o X-Peer é um middleware que pode ser utilizado em corporações de pequeno, médio e grande porte como substrato básico para a construção de aplicações P2P de larga escala. O X-Peer é escalável e flexível, pois organiza super-nós sobre um modelo estruturado DHT. Além disso, pela estruturação das meta-informações proposta, amplia os tipos de consulta possíveis, permitindo vários tipos de consultas por palavras-chave.
Como trabalho futuro, espera-se que várias características como gerenciamento e suporte a aplicações moveis e dispositivos sem fio sejam adicionados ao X-Peer. Assim também se espera desenvolver aplicações móveis que se utilizam do X-Peer.

link: http://www.cin.ufpe.br/~tds/ic1/tarciana-silva-04-02.doc

A performance vs. cost framework for evaluating DHT design tradeoffs under churn

Este artigo apresenta performance versus custo Framework (PVC), que permite designers comparar os efeitos de diferentes características de protocolos e valores dos parâmetros. PVC vistas como um protocolo consumindo uma certa quantidade de largura de banda, a fim de alcançar um certa latência, e ajuda a revelar a eficiência dos protocolos adicionais com os quais utilizam recursos de rede para melhorar a latência. Para demonstrar o valor de PVC, o presente documento simula Corda, Kademlia, Kelips, OneHop, Tapestry e sob diferentes trabalhos e utiliza PVC para entender quais recursos são mais importante. PVC análisa e mostra que a chave para usar banda adicional de um protocolo é ajustando o tamanho da tabela de roteamento. Demonstra também que a estabilização da tabela de roteamento é inútil e pode ser substituído por aprendizagem oportunistas através tráfego normal. Estas percepções combinadas demonstram que o PVC é um instrumento precioso para DHT designers.

Fonte:
http://pdos.csail.mit.edu/papers/dhtcomparison:infocom05/paper.pdf

Lucas Carvalho Teixeira

Kenosis: A P2P RPC system using the Kademlia DHT

O artigo: Kenosis: A P2P RPC system using the Kademlia DHT, de Baris Boyvat, disponivel em http://www.tml.tkk.fi/Publications/C/18/boyvat.pdf, acessado em 13 de março de 2008, apresenta um sistema remoto peer-to-peer, baseado no Kademlia distribuído em uma tabela hash para descobertas de nós e rotas na rede.
O Kademlia é um método DHT desenvolvido pela Universidade de Nova York A maior inovação desse algoritmo é que as distancias entre os pontos na rede são gerenciados por uma métrica XOR. Esse método é completamente descentralizado como o Chord (outro conhecido método DHT).
Este artigo aborda o desenvolvimento do sistema Kenosis. Esse sistema utiliza a tabela Hash de distribuição Kademila para a descoberta de nós e de rotas. Para as chamadas remotas o Kenosis utiliza o framework XML-RPC.

COMENTÁRIO:
O referente artigo aborda resumidamente os aspectos referentes a construção do Kenosis. A abordagem introdutória foi razoável (tendo duas seções dedicadas a este fim), porém descrição sobre o sistema em si foi extremamente superficial. Algo também não muito apropriado no artigo são as referencias bibliográficas. Este baseou-se principalmente em fóruns e wikis. Apesar de o tema ser interessante, o projeto aparentemente resumiu-se a um protótipo estudantil sem maiores pretensões.
20 de março de 2008


Leandro Moraes V. Cruz

Um modelo de arquitetura em anel baseado na implementação Pastry

Introdução ao artigo

Com o surgimento da abstração Distributed Hash Table (DHT) foram resolvidos alguns problemas das redes p2p como localização de nós e de arquivos. Esse mecanismo sugere que um nó ativo fornece primitivas para enviar uma mensagem a uma chave. Cada nó mantém uma tabela de roteamento, formada pelor Id’s dos nós mapeados a seus endereços IP. A rede é organizada de forma que cada nó mantenha uma pequena tabela de roteamento de tamanho constante. Alguns sistemas de implementação do DHT são CAN, Chord, Kademlia, Pastry e Tapestry.

O objetivo deste artigo é propor uma infra-estrutura que forneça uma solução para alguns problemas que não são atingidos pelos sistemas acima, como por exemplo, publicação, recuperação e Binding de serviços. Publicação e recuperação fornecem mecanismos que permitem que o usuário busque e instale apenas serviços de seu interesse e Binding provê todo o código necessário para instalação de um serviço em outro nó.

Os sistemas atuais citados acima são ineficazes para estes problemas, uma vez que, exigem que cada nó da rede suporte o mesmo conjunto de aplicações e que elas estejam pré-instaladas em todos os nós.

O artigo usa a implementação Pastry como exemplo de protocolo p2p estruturado.

Pastry

Pastry direciona mensagens para o nó o qual o id é numericamente mais perto da chave de destino numa estrutura circular que podemos chamar de anel. Cada nó mantém um conjunto de folhas e uma tabela de roteamento. Cada folha no conjunto possui o endereço para o próximo nó no sentido horário. A tabela de roteamento é organizada em 32 linhas e 16 colunas de maneira que o número de nós populados na tabela seja apenas logaritmo de 16 na base n.

Em um procedimento normal de roteamento, um nó pastry direciona a mensagem para o nó onde o id compartilha com a chave de destino um prefixo que é pelo menos um dígito mais longo que o compartilhado pela chave e o id do nó que está enviando. Se não houver nenhum nó que possua um id com essa característica, a mensagem é direcionada para o nó que compartilha o prefixo com a chave tão longo quanto o do nó que está enviando.

Para cada serviço é fornecido um service id, e quando um nó descobre que está numericamente perto da chave de destino, segundo o mecanismo citado acima, ele entrega a mensagem para o serviço local que corresponde ao service id da mensagem. Isso permite a realização de cache nos nós intermediários por onde passa a mensagem destinada a um serviço.

O anel Universal

Primeiramente cada nó deve obter um id fornecido por uma entidade de controle, após isso, para cada id é atribuído um certificado, uma chave pública e uma privada para garantir a segurança. Em seguida cada nó precisa obter o endereço do seu nó de contato no anel. Através de um multicast de endereço IP ou outras formas de flooding controlado.

Serviços

O primeiro serviço oferecido é o de armazenamento persistente de pares chave-arquivo para um acesso eficiente aos arquivos através de suas chaves. Esse serviço apoiará o armazenamento de informações sobre outros serviços, como o código necessário para rodar e a lista de nós que fornecem um determinado serviço.

O segundo é um multicast de serviço em nível de aplicação.

O terceiro é a busca distribuída por serviços, que permite que usuários façam uma busca textual pelo serviço desejado através de palavras-chave.

O quarto serviço é a publicação e descoberta de serviços, onde cada serviço criado possuirá um certificado de serviço que conterá um nome e uma descrição textual de cada serviço, além disso, esse certificado também terá um conjunto de code keys onde cada code key identificará uma implementação diferente do serviço criado.

Opinião

A arquitetura proposta permite a publicação, a descoberta e a vinculação de serviços através de máquinas interligadas em um “anel universal” de forma que não seja mais necessário que todas as máquinas tenham disponibilidade para rodar todo o conjunto de aplicações e nem que estas aplicações estejam pré-instaladas em todas as máquinas. Isso facilita o uso de serviços de forma que uma pessoa dotada de um celular possa executar processos extremamente necessários em um dado momento, porém, custosos para dispositivos móveis.

O artigo deixou um pouco a desejar no que diz respeito às entidades gerenciadoras responsáveis pelos certificados citados acima, como elas reconheceriam uma falha em um dos nós ou o impacto da entrada e da saída de um nó no anel, e ainda, a arquitetura tem como alvo a implementação Pastry, e não ficou explicitado como seria o seu comportamento com outras implementações do DHT como o Chord ou o CAN.

Fonte : M. Castro, P. Druschel, A-M. Kermarrec and A. Rowstron, "One ring to rule them all: Service discovery and binding in structured peer-to-peer overlay networks", SIGOPS European Workshop, France, September, 2002. [ pdf.zip ].

Link: http://research.microsoft.com/~antr/pastry/pubs.htm (O terceiro artigo desta página).

Thiago R. Nunes / 105040501
Sistemas Distribuidos
UCAM

Tapestry

Tapestry

Usando apenas ligações ponto-a-ponto e recursos descentralizados, o Tapestry é uma infra- estrutura de roteamento e de cobertura de posição que fornece um roteamento independente da localização de mensagens diretamente a uma cópia mais próxima de um objeto ou serviço. O tapestry pode ostentar características como o balanceamento de carga, fault-resilience, robustez, escalabilidade e auto-organização.
Arquitetura de roteamento
Usando a localização Plaxton as metas do mecanismo de roteamento do Tapestry são adaptativas, auto-gerenciáveis e fault-resiliance. A arquitetura de roteamento do Tapestry eficientemente “roteia” requisições mesmo na presença de falhas nos nós ou uma carga alta na rede. Através do uso de aleatoriedade ele realiza o roteamento localmente e carrega a distribuição. O Tapestry vai lidar com os problemas da rede desviando se das rotas com falhas, removendo nós sobrecarregado por um serviço, transparentemente mascarando componentes com falhas e rapidamente adaptando a topologia de comunicação às circunstâncias que dependem dos tipos de problemas encontrados.
Por ter suas rotas fortemente ligadas ao mecanismo Plaxton, é apropriado discutir o que é basicamente o método Plaxton para que se possa entender o mecanismo de roteamento do Tapestry.
Arquitetura de roteamento do Plaxton
O mecanismo de roteamento do Plaxton possui em cada nó mapas de roteamento locais chamados mapas de vizinhança (neighborhood maps) que incrementalmente “roteiam” as mensagens cobertas ao local de destino (destination ID). Cada nó possui um mapa de vizinhaça com múltiplas camadas. Cada camada possui um número de entradas igual à base do ID, onde uma de i entradas de uma das j camadas é a ID e o local mais próximo do nó. Na intenção de achar o próximo nó, procura-se nos n+1 níveis do mapa, e verifica-se a entrada correspondente ao valor do próximo dígito no local de destino. Usando este método de roteamento num “namespace” de tamanho n e usando ID de base b pode-se garantir que em no máximo hops lógicos um nó pode ser achado no sistema, assumindo que cada nó tenha um mapa de vizinhança consistente.
Como todos os mapas de vizinhança em cada nó assumem que a predição de dígitos de cada nó sempre “casa” com o sufixo do nó atual, ele só precisa manter um tamanho constante b de entradas em cada nível da rota:
NeighborMapSize = (entries/map) * (# of maps) = b *


Esse trecho sobre Tapestry foi tirado do link abaixo. Um link muito bom que descreve um visão geral dos algoritmos de implementação DHT, além de diversas seções a respeito de várias áreas da tecnologia e arquitetura Peer-to-Peer (P2P).

http://www.gta.ufrj.br/grad/04_1/p2p/

KADEMLIA

Proposto por Petar Maymounkov e David Mazèries, Sistema de armazenamento e busca P2P. Totalmente descentralizado

A Rede

Para ingressar na rede, é necessário conhecer o IP de um nó participante.
Cada nó recebe um ID calculado através da aplicação de uma função de hash no seu IP.
Cada arquivo recebe uma Chave, obtida através da função de hash.
Os IDs e chaves possuem 160 bits.
Os pares identificam a localização do arquivo. Os pares são distribuídos aos nós, de acordo com a proximidade com os seus Ids. A distância entre dois identificadores (chaves ou IDs) é calculada com o XOR interpretado como um inteiro.

K-Listas

Cada nó mantém listas de contatos de outros nós. O nó mais recente fica na cauda da lista. A cada mensagem trocada as listas são atualizadas

Protocolo

É formado por 4 RPC’s (Remote Procedure Calls); find_node, find_value, store, ping. A busca é recursiva

Busca

Ex: Um nó deseja encontrar uma chave y.
● Ele busca em suas k-listas os IDs mais próximos desta chave.
● Ele envia então o pedido aos nós. Se algum deles possui o arquivo a busca acaba.
● Se não, os nós enviam o pedido aos nós de ID mais próximo de suas k-listas.

http://www.cic.unb.br/~bordim/TD/Arquivos/G02_Slides.pdf

Marcele Barreto Soares

mat: 104040495

Protocolo Chord

Um problema chave que toda a aplicação peer-to-peer enfrenta é a localização eficiente de qualquer nó. O artigo abaixo relata sobre o Chord que é um protocolo distribuído para a resolução daquele problema.A função do protocolo Chord é saber como localizar as keys (chaves), como novos nós juntam-se ao sistema e como se recuperar de falhas (ou evitá-las).Chord aumenta a capacidade de escalabilidade evitando que cada nó saiba sobre todos os outros. Um nó Chord precisa saber apenas algumas informações de roteamento sobre outros nós. Pelo fato da informação ser distribuída, um nó é capaz de resolver a função hash comunicando-se com outros nós.

Link: http://pdos.csail.mit.edu/chord/papers/paper-ton.pdf

Postado por: Maycon Lopes

Plataforma JXTA

Para transformar o uso P2P em uma solução madura, os desenvolvedores precisam tirar seus esforços da programação das redes e protocolos P2P para a criação de aplicações em uma base sólida e bem definida. Para isso, os desenvolvedores precisam de uma linguagem comum que permita que os peers se comuniquem e exerçam as funcionalidades básicas de uma rede P2P.

Mensagens: Mensagens são objetos enviados entre peers JXTA, ou seja é a unidade básica de troca dedados entre peers. Mensagens são enviadas e recebidas por serviços de dutos e por pontos de fim (endpoint). Tipicamente aplicações utilizam serviço de dutos para criar, enviar e receber mensagens. Em geral as aplicações não necessitam do uso direto de serviços de pontos de fim (endpoint).Mensagem é essencialmente um conjunto chave/valor, seu conteúdo pode ser de tipos arbitrários e cada plataforma de software descreve como uma mensagem é convertida de uma estrutura de dados nativa (como exemplo objetos da linguagem Java ou C) para uma representação conhecida por toda arquitetura JXTA.

Segurança: Redes P2P dinâmicas como JXTA necessitam um suporte para diferentes níveis de segurança de acesso aos recursos. Peers JXTA operam em modelos baseados em papéis, no qual diferentes peer se integram na rede e cada um possui níveis de privilégio diferentes, o qual podem executar diferentes tarefas. Cinco são os princípios básicos de segurança necessários: sigilo; autenticação; autorização; integridade dos dados; refutabilidade.

Identificadores (IDs): Peers, grupos de peers, dutos e outros recursos JXTA precisam ser univocamente identificados. O JXTA ID é um identificador único de uma entidade. Algumas entidades que precisam ser unicamente identificadas são: peers, grupos de peers, dutos e conteúdos. URNs (Uniform Resource Names) são utilizados para expressar JXTA IDs, sendo que estes servem como identificadores independentes. Estes identificadores são representados em arquivo texto no formato XML reconhecido por toda plataforma JXTA.

Opinião:
JXTA pode não ser a solução melhor ou mais eficiente para implementar uma aplicação P2P qualquer.Entretanto, JXTA provê a mais bem modelada plataforma para produzir aplicações P2P que tenham a flexibilidade necesária para crescer no futuro.A capacidade de alavancar outros serviços P2P e permitir o vasto crescimento de comunidades P2P são os valores centrais da plataforma JXTA.

Link: http://minerva.ufpel.edu.br/~agostini/pesquisa/TI_Image.pdf
http://200.18.98.97/intranet/documentos/papers/sbrc2005/2005/WP2P/P2P%2003.pdf

Jefferson Moura
105040029