Desenvolvimento de Uma Ferramenta de Backup Descentralizada Utilizando JXTA

Jan Tarik Martins Nazorek
DESENVOLVIMENTO DE UM SOFTWARE DE BACKUP

DESCENTRALIZADO, UTILIZANDO A PLATAFORMA JXTA
Palmas
2013
Jan Tarik Martins Nazorek

Trabalho de Concluso de Curso (TCC)

elaborado e apresentado como requisito
parcial
para
obteno
do
ttulo
de
bacharel em Sistemas de Informao pelo

Centro Universitrio Luterano de Palmas
(CEULP/ULBRA).
Orientador: Prof. Mestre Madianita Bogo

Marioti.
Palmas
2013
JAN TARIK MARTINS NAZOREK

Trabalho de Concluso de Curso (TCC)

elaborado e apresentado como requisito
parcial
para
obteno
do
ttulo
de
bacharel em Sistemas de Informao pelo

(CEULP/ULBRA).
Orientador: Prof. Mestre Madianita Bogo

Marioti.
Aprovada em xxxxxxx de 20XX.
BANCA EXAMINADORA
___________________________________________________
Prof. M.Sc. Madianita Bogo Marioti
___________________________________________________
Prof. M.Sc. Jackson Gomes de Souza
___________________________________________________
Prof. M.Sc. Edeilson Milhomem Silva
Palmas
2013
SUMRIO
1
INTRODUO ................................................................................................... 10
REFERENCIAL TERICO ................................................................................. 13

2.1
2.1.1
Aspectos de Projeto ............................................................................... 14
2.1.2
Motivaes e dificuldades ...................................................................... 18
2.1.3
Modelos de Sistemas Distribudos......................................................... 19
2.2
Aplicaes P2P...................................................................................... 22
2.2.2
Distribuio de contedo utilizando redes P2P...................................... 23
2.2.3
Arquiteturas P2P de Distribuio de Contedo...................................... 24
2.2.4
Arquiteturas Desestruturadas ................................................................ 25
2.2.5
Arquitetura Descentralizada................................................................... 28
2.2.6
Segurana P2P...................................................................................... 31
Tecnologia JXTA .......................................................................................... 33
2.3.1
Arquitetura JXTA ................................................................................... 36
2.3.2
Protocolos JXTA .................................................................................... 37
2.4
Arquitetura Peer-to-Peer (P2P) .................................................................... 21
2.2.1
2.3
Sistemas Distribudos ................................................................................... 13
Backup Cooperativo ..................................................................................... 39
2.4.1
Tipos de backup .................................................................................... 39
2.4.2
Backup em rede ..................................................................................... 41
MATERIAIS E MTODOS ................................................................................. 44

3.1
MATERIAIS .................................................................................................. 44
3.2
Metodologia .................................................................................................. 45
RESULTADOS E DISCUSSES ....................................................................... 50

4.1
Arquitetura da aplicao Peer Backup ......................................................... 51
4.2
Diagrama de classes .................................................................................... 53
4.3
Modelo de dados .......................................................................................... 58
4.4
Cenrios de Uso........................................................................................... 61
4.5
Implementao da aplicao Peer Backup .................................................. 65
4.6
Testes realizados sobre a aplicao ............................................................ 83
CONSIDERAES FINAIS ............................................................................... 91
REFERNCIAS BIBLIOGRFICAS ................................................................... 93
RESUMO
As redes de computadores tm se tornado comum entre usurios e organizaes e,
consequentemente, a utilizao de dados digitais tem crescido. Com isso,
importante criar novas formas de armazenar esses dados com intuito de manter
cpias de segurana de arquivos para evitar possveis perdas. Assim, o objetivo
deste trabalho foi desenvolver uma soluo de backup P2P, utilizando JXTA, que
possibilita o compartilhamento de arquivos disponveis nas mquinas dos usurios.
A aplicao oferece funcionalidades para o usurio enviar, buscar e recuperar seus
arquivos, que so criptografados e armazenados em diversas mquinas de rede afim
de criar cpias de segurana. Os arquivos enviados podem ser recuperados
somente por quem possui a chave de criptografia, utilizada para garantir a
privacidade dos arquivos.
LISTA DE ILUSTRAES
Figura 1Troca de mensagens entre servidor e clientes ........................................... 14

Figura 2 - Servidor FTP ............................................................................................. 20
Figura 3 - Sistema distribudo P2P ............................................................................ 21
Figura 4 - Rede P2P .................................................................................................. 22
Figura 5 - Compartilhamento de contedo em uma rede P2P .................................. 24
Figura 6 - Rede P2P Hibrida ..................................................................................... 26
Figura 7 - Rede P2P parcialmente centralizada ........................................................ 27
Figura 8 - Rede P2P descentralizada ........................................................................ 28
Figura 9 - Incluso de novo membro na rede ............................................................ 29
Figura 10 - Buscar um arquivo na rede descentralizada. .......................................... 30
Figura 11 - Recuperando informao com chave pblica ......................................... 33
Figura 12 - Camadas JXTA (MAINBAUM, MUNDT. 2002, p. 3) ................................ 36
Figura 13 - Protocolos JXTA (MAIBAUM, MUNDT. 2002. p. 4) ................................. 38
Figura 14 - Backup incremental adaptado (IBM, 2004, online) .................................. 40
Figura 15 Backup diferencial (IBM, 2004, online) ................................................... 41
Figura 16 - Backup centralizado ................................................................................ 42
Figura 17 - Backup descentralizado .......................................................................... 43
Figura 18 - Etapas de execuo do projeto ............................................................... 46
Figura 19 - Arquitetura Peer Backup ......................................................................... 51
Figura 20 - Funcionamento do Peer Backup ............................................................. 52
Figura 21 - Diagrama de classes da aplicao.......................................................... 54
Figura 22 - Pasta .jxta ............................................................................................... 58
Figura 23 - Pastas Peer Backup................................................................................ 60
Figura 24 - Pasta Config ......................................................................................... 60
Figura 25 - Arquivo "Base.xml" ................................................................................. 61
Figura 26 - Primeiro acesso ...................................................................................... 62
Figura 27 - Recuperando lista de arquivos ................................................................ 63
Figura 28 - Recuperar um arquivo ............................................................................. 64
Figura 29 - Sequncia de eventos na inicializao do Peer Backup ......................... 66
Figura 30 - Fluxo verificar base e pastas................................................................... 67
Figura 31 - Criao da rede P2P ............................................................................... 68
Figura 32 - Etapas de acesso aplicao................................................................. 72
Figura 33 - JXTA Configurator................................................................................... 73

Figura 34 - Verificao de chave ............................................................................... 75
Figura 35 - Interface grfica Peer Backup ................................................................. 76
Figura 36 - Mtodo notifyMoreResults() .................................................................... 79
Figura 37 - Aba Buscar Arquivos ............................................................................... 80
Figura 38 - Aba "Download" ...................................................................................... 81
Figura 39 - Aba Peers Conectados ........................................................................... 82
Figura 40 - Aba Logs ................................................................................................. 83
Figura 41 - Arquivos enviados por Lord..................................................................... 87
Figura 42 - Arquivos da pasta Share dos pares ........................................................ 87
Figura 43 - Peers conectados ................................................................................... 88
Figura 44 - Lista de arquivos disponveis .................................................................. 88
Figura 45 - Tentativa de recuperao de usurio falso ............................................. 90
LISTA DE ABREVIATURAS E SIGLAS

P2P Peer-to-Peer
IP Internet Protocol
FTP File Transfer Protocol
URI Uniform Resource Identifier
10
INTRODUO
Com a expanso da internet e a facilidade de acesso aos recursos computacionais e

de telecomunicao, a quantidade de dados gerados por usurios tambm
aumentou. Deste modo, continuamente tem sido propostos novos meios de atender
a demanda de usurios e criar sistemas com poder computacional e capacidade de
armazenamento elevado tem se tornado cada vez mais comum. Nesse contexto,
utilizar sistemas distribudos pode ser uma boa alternativa.
Coulouris (2007, p. 16) define sistema distribudo como um sistema no qual
os componentes de hardware ou software, localizados em computadores interligados
em rede, se comunicam e coordenam suas aes apenas enviando mensagens
entre si. Estes componentes trabalham em conjunto para realizar aes solicitadas
pelos usurios do sistema.
Um sistema distribudo pode trazer muitas vantagens, sendo que o
compartilhamento de recursos uma delas, pois oferece a capacidade de dividir o
processamento entre os recursos, evitando que apenas um destes fique
sobrecarregado de processos. Outro ponto positivo a possibilidade de aumentar a
capacidade do sistema, como o espao de armazenamento, sem precisar descartar
o que j est funcionando. Exemplos de sistemas distribudos so: Cliente/Servidor;
que utiliza um servidor centralizado para coordenar as aes e responder
requisies enviadas pelos clientes; e P2P, que constitudo de pares que se
comunicam diretamente entre si, podendo trabalhar tanto como servidor quanto
como cliente.
Em uma rede P2P (Peer-to-Peer) os ns interligados podem compartilhar
recursos como ciclos de CPU, armazenamento, arquivos etc. Muitas aplicaes
existentes utilizam P2P para que seus usurios possam compartilhar arquivos
pessoais como msicas, vdeos, fotos etc. Alm do compartilhamento de arquivos, o
compartilhamento de hardware tambm importante como, por exemplo, espao em
disco, pois outros usurios podem usar o espao disponvel de ns da rede para
guardar seus dados. Baseado nisso, desenvolveu-se em criar um sistema de backup
11
descentralizado utilizando P2P, no qual as cpias podem ficar armazenadas em ns

de rede. Esses ns representam as mquinas conectadas a rede local.
Um sistema descentralizado de backup guarda em vrios locais uma mesma
informao, tornando difcil que esta seja perdida caso ocorra falha em algum dos
locais. Uma maneira de implementar um sistema desses utilizando a ferramenta
JXTA, que oferece recursos para a implementao de redes P2P e para o acesso
aos recursos disponveis dos pares da rede.
Segundo Sun Microsystems (2005, p. 7) JXTA um conjunto aberto de
protocolos Peer-to-Peer (P2P) que permitem qualquer dispositivo de rede [...] se
comunicar e colaborar mutuamente como pares. Esta ferramenta vem sendo
bastante utilizada em aplicaes P2P, isto porque tem caractersticas que permitem
a comunicao entre os pares independentemente de endereamento de rede,
protocolos fsicos e plataforma de programao.
A criao de uma rede P2P descentralizada foi o objetivo do trabalho, e isto
foi possvel por meio do JXTA, que fornecer as funcionalidades da rede Peer-toPeer. Com os mtodos de rede P2P fornecidos pelo JXTA, foi implementada uma
aplicao
denominada
Peer
Backup.
A aplicao,
em conjunto
com as
funcionalidades da rede, fornece ao usurio mtodos para realizao de backups em

rede.
Na primeira etapa do trabalho foram pesquisados assuntos referentes a
sistemas distribudos, peer-to-peer, JXTA e Backup colaborativo. Estes materiais
foram utilizados para o desenvolvimento do referencial terico, e foram utilizados
como base para a execuo do projeto. Durante a execuo do projeto foram
gerados artefatos de modelagem, e, a partir deles, foram criados cenrios que
mostram situaes com os quais os usurios da aplicao pode se deparar. Os
cenrios, que englobam desde a criao da rede P2P descentralizada at a
recuperao de um arquivo do usurio, serviram de base para a implementao dos
mtodos e das sequncias de execuo das aes.
A aplicao Peer Backup possui as caractersticas de um programa comum
de cpias de arquivos, mas possibilita duplicar os arquivos em mquinas de uma
rede local, com intuito de garantir a disponibilidade e garantir a privacidade utilizando
chave de criptografia.
O trabalho est estruturado da seguinte forma: captulo 1 que referente
Introduo do projeto, captulo 2 que apresenta o referencial terico sobre os
12
assuntos 2.1 Sistemas Distribudos, 2.2 Arquitetura Peer-to-Peer, 2.3 Tecnologia

JXTA e 2.4 Backup cooperativo. No captulo 3 apresentada a metodologia de
desenvolvimento do projeto e os materiais utilizados no desenvolvimento do projeto.
O captulo 4 referente ao desenvolvimento da aplicao, no qual apresenta a
arquitetura, modelo de dados, codificao e testes da aplicao desenvolvida. As
consideraes finais que mostrada no captulo 5, seguido pelas referncias
bibliogrficas presentes no capitulo 6.
13
REFERENCIAL TERICO
Nesta seo so abordados os principais conceitos referentes ao projeto, que so:

2.1 Sistemas Distribudos, 2.2 Arquitetura Peer-to-Peer, 2.3 Tecnologia JXTA e 2.4
Backup cooperativo. A partir deles ser possvel fundamentar o desenvolvimento da
aplicao.
2.1
Sistemas Distribudos
As redes de computadores possibilitam que computadores se conectem e troquem

informaes, independentemente da localidade. As tecnologias de redes e sua
abrangncia cresceram bastante, e consequentemente, a quantidade de usurios e
tipos de servios oferecidos tambm. Para atender essa demanda, tem se
destacado o uso de sistemas distribudos, que tm a capacidade de atender grande
quantidade de usurios e oferecer servios usando recursos das redes de
computadores.
Coulouris (2007, p.16) define sistema distribudo como um sistema no qual
os componentes de hardware ou software, localizados em computadores interligados
em rede, se comunicam e coordenam suas aes apenas enviando mensagens
entre si. Isto , processos que podem estar executando em computadores distintos
trabalham em conjunto para executar determinada tarefa em comum e, tambm,
compartilham recursos e informaes.
Os sistemas distribudos podem ser empregados em diversos tipos de
aplicaes como, por exemplo, uma partida online de domin, no qual os usurios
trocam mensagens com o servidor para realizar uma jogada e o servidor envia
mensagem aos usurios sobre aes do jogo, como mostra a Figura 1.
14
Figura 1Troca de mensagens entre servidor e clientes
Na Figura 1, os usurios acessam a aplicao cliente que envia para o

servidor mensagens de requisio. O servidor o responsvel por controlar as
aes baseando-se nas mensagens que recebeu das aplicaes cliente. Dessa
forma, quando um usurio realiza uma jogada, o aplicativo cliente envia uma
mensagem ao servidor, que replica a mensagem para os aplicativos cliente dos
demais usurios para que todos os usurios tenham a mesma viso do jogo nos
seus computadores.
No desenvolvimento de um sistema distribudo necessrio considerar
aspectos de projeto importantes para que este funcione de forma consistente, que
so: Transparncia, Flexibilidade, Escalabilidade, Confiabilidade, Tolerncia a falhas
e Desempenho. Cada um desses aspectos apresentado na seo seguinte.
2.1.1 Aspectos de Projeto
No projeto dos Sistemas Distribudos um conjunto de aspectos devem ser

considerados visando garantir o funcionamento adequado, para que as tarefas
possam ser realizadas de forma eficiente, que seu funcionamento no seja
interrompido em caso de falhas, que tenha a capacidade de acompanhar o
15
crescimento da demanda, entre outras caractersticas desejadas em um sistema de

computao. Esses aspectos so:
Transparncia;
Flexibilidade;
Escalabilidade;
Confiabilidade;
Tolerncia a falhas;
Desempenho.
Transparncia
Um sistema distribudo deve ocultar de seus usurios que os processos executados
e os componentes utilizados esto separados fisicamente, mesmo quando esto
separados por localidade, com sistemas operacionais diferentes etc.. Existem vrios
tipos de transparncia, sendo que cada aplicao pode exigir conceitos diferentes
(TANEMBAUM, 2007, p. 3). So elas:
Acesso: ocultar como os dados so representados e como os recursos so
acessados. Caso o usurio faa uma requisio de download, por exemplo, o
usurio no deve perceber como este dado est armazenado no sistema;
Localizao: ocultar do usurio a localizao dos recursos, sendo que
recursos locais e remotos, para o usurio, so vistos da mesma forma. Por
exemplo, ao acessar uma pgina o usurio no quer saber se ela est no
Brasil ou na China, apenas necessita que pgina seja exibida.
Migrao: ocultar que um recurso possa ter sido movido de um local para
outro. Por exemplo, se um arquivo foi movido de um servidor para outro, o
sistema deve retornar as informaes para o usurio sem que este perceba
ou se preocupe com a nova localizao;
Performance: melhorar a capacidade (desempenho) do sistema caso seja
necessrio sem que o usurio perceba. Mesmo com o aumento da carga,
devido ao aumento da quantidade de usurios, o sistema deve garantir que o
tempo de acesso a um recurso no sofra alterao;
Replicao: ocultar que existem cpias de um recurso. Um exemplo de
replicao um sistema que, para evitar perda de dados, faz cpias de dados
que usurios enviam em outro local, mas, no informa isto ao usurio. Caso
16
ocorra um problema na mquina que est o documento original, a cpia pode

ser utilizada, evitando que os dados do usurio sejam perdidos;
Concorrncia: ocultar do usurio que existem outros usurios compartilhando
do mesmo recurso. Um exemplo de concorrncia dois usurios utilizarema
mesma opo (exemplo sacar) de um caixa eletrnico, que busca no banco
de dados informaes na mesma tabela. O sistema deve ser percebido pelo
usurio como exclusivo, como se ningum estivesseusando os mesmos
recursos que ele;
Falha: ocultar falhas de algum recurso e ainda ocultar a recuperao dessa
falha. Se um usurio tenta acessar uma imagem e o servidor tem um
problema de conexo com a internet, este deve solucionar o problema
automaticamente sem que o usurio perceba.
Flexibilidade
Segundo Dettenborn (2008, p. 19) um projeto de sistemas distribudos deve ser
flexvel com a capacidade de suportar alteraes que no foram previstas. Deste
modo, a flexibilidade de um sistema est ligada a capacidade de realizar
modificaes futuras com mais facilidade. Nessas modificaes podem ser includas
funcionalidades como segurana, desempenho etc.. Assim, situaes imprevistas
devem ser contornadas de forma simples. Por exemplo, se o firewall utilizado de
baixa confiabilidade ele pode ser trocado por outro sem precisar alterar o sistema
que protegido por ele.
Escalabilidade
Um sistema descrito como escalvel se permanece eficiente quando h um
aumento significativo no nmero de recursos e no nmero de usurios
(COULOURIS, 2007, p.31). Ou seja, preciso que um sistema continue funcionando
adequadamente caso a demanda aumente. Por exemplo, se um site da internet
ganha novos usurios de forma progressiva e de diversos locais do mundo, deve
permanecer funcionando normalmente e fornecer respostas s solicitaes dos
usurios em tempo adequado. Esta escalabilidade pode ser dividida em trs nveis:
Tamanho: capacidade de atender uma demanda maior de usurios.
Distncia geogrfica:capacidade de atender usurios mesmo ele estando
longe dos recursos.
17
Facilidade de administrao: mesmo com incluso muitas organizaes

independentes ainda continuam fceis administrao.
Confiabilidade
Confiabilidade [...] refere-se propriedade de um sistema poder funcionar
continuamente sem falha (TANEMBAUM, 2007, p.194). Um sistema confivel deve
garantir a disponibilidade, a segurana dos dados transmitidos e, tambm, a
possibilidade de se recuperar caso ocorra uma falha. Por exemplo, se um servidor
que compartilha arquivos na maior parte do tempo est fora do ar, os usurios
podem entender que o site no confivel, pois existe uma dificuldade em obter
qualquer informao dele dependendo do momento que em que acessado.
Tolerncia a Falhas
Sistemas so sujeitos a falhas, tanto por software como por hardware. Quando
ocorrem falhas no hardware ou no software, os programas podem produzir
resultados incorretos ou podem parar antes de terem concludo a computao
pretendida (COULOURIS, 2007, p.32). Porm, mesmo quando ocorre algum
problema com um de seus componentes, o sistema deve ter a capacidade de
continuar funcionando, ou seja, deve ser tolerante a falhas. Algumas alternativas
para preveno de falhas so: redundncia de hardware, que ter cpias idnticas
de hardwares utilizados; e recuperao por software, pois, caso algo falhe, o sistema
pode, por exemplo, reiniciar um servio ou direcionar os usurios para um recurso
que est funcionando, evitando que o servio pare.
Desempenho
preciso que um sistema distribudo oferea um desempenho equivalente ou
melhor que de um sistema centralizado, fornecendo respostas rpidas, como se o
sistema estivesse executando localmente. Podem ser adotadas mtricas distintas
para verificar o desempenho, como: tempo de resposta, utilizao do sistema,
quantidade consumida da capacidade da rede, entre outras.
A utilizao de sistemas distribudos interessante em diversas situaes,

mas, a distribuio dos sistemas traz dificuldades. A prxima seo discorre sobre
18
as motivaes que levam a criao dos sistemas distribudos e a dificuldades

encontradas no uso destes.
2.1.2 Motivaes e dificuldades
Os sistemas distribudos permitem que sejam criadas aplicaes com a capacidade
de executar tarefas que exigem alto poder de processamento, atender demanda de
grande quantidade de usurios, entre outras possibilidades que se tornam motivao
para o seu uso:
Compartilhamento de recursos: capacidade de utilizar recursos disponveis

em maquinas da rede como software, hardware e dados.
Capacidade de concorrncia: caso a escala de usurios aumentar de forma

desordenada, a carga pode ser distribuda entre os recursos, no
sobrecarregando apenas um recurso.
Capacidade de expanso: possibilidade de aumentar o poder de

processamento ou/e armazenamento sem precisar se desfazer do que j est
pronto.
Tolerncia a falhas: o sistema pode continuar funcionando mesmo quando

ocorre um problema.
Por outro lado, se comparado a outros tipos de sistemas, o seu desenvolvimento

mais complexo e nem sempre as solues fceis so encontradas para resolver os
problemas. Entre os principais problemas encontrados na sua utilizao e
desenvolvimento esto:
Complexidade
de
software:
implementar
softwares
para
sistemas
distribudos so complexos, levando em considerao a sua dimenso e que

seu funcionamento no-determinstico.
Segurana: como os dados so compartilhados, preciso garantir que os

dados sejam acessados somente por pessoas autorizadas.
Rede de comunicao: a rede pode saturar por causa da quantidade de

dados transferidos, e falhar. Alm da distncia fsica da rede entre os
recursos do sistema podem afetar a velocidade, deixando o sistema lento.
19
Apesar das dificuldades o uso de sistemas distribudos costuma ser uma boa
soluo para resolver determinados problemas, como o acesso informao em
localidades distintas. No seu desenvolvimento deve ser levada em considerao a
necessidade, a dificuldade e o benefcio que trar quando concludo. De toda forma
existem vrias solues parao problema da segurana e das redes de comunicao.
Ao se decidir pelo desenvolvimento de um sistema distribudo, deve-se definir

qual modelo ser utilizado, j que existem alguns modelos, entre eles ClienteServidor e P2P, abordados na prxima seo. As motivaes e dificuldades
comentadas nessa seo esto presentes nos Sistemas Distribudos em geral,
independente do modelo.
2.1.3 Modelos de Sistemas Distribudos
As diversas caractersticas contidas em sistemas distribudos so empregadas de
acordo com o modelo escolhido no seu desenvolvimento. Estes modelos permite
que o desenvolvedor tenha conhecimento sobre o funcionamento do seu sistema.
Entre os modelos existentes possvel citar: Arquitetura Cliente-Servidor e P2P.
Na arquitetura Cliente-Servidor existe uma aplicao central, denominada
servidor, que responsvel por disponibilizar servios e as aplicaes acessadas
pelos usurios, que so os clientes. Um servidor fica esperando por requisies de
clientes, que recebem a solicitao do usurio, empacotam em uma mensagem de
requisio e enviam ao servidor pela rede (TANEMBAUM, 2007, p22). Esse tipo
considerado centralizado, no qual um servidor essencial e responsvel pelo
atendimento das requisies dos usurios e que uma falha neste pode gerar muitos
problemas.
Vrios sistemas podem ser citados como exemplo de cliente servidor, um
deles o sistema de FTP (File Transfer Protocol), mostrado na Figura 2.
20
Figura 2 - Servidor FTP
Na Figura 2 apresentado um exemplo de aplicao Cliente-Servidor, que

representa o funcionamento do FTP. Quando um cliente deseja um arquivo, envia a
solicitao do arquivo ao servidor. O servidor recebe a solicitao, buscar o arquivo,
verifica se o usurio possui permisso para acessar, monta as mensagens com o
contedo do arquivo solicitado e envia como resposta ao cliente.
Outro modelo de sistema distribudo o Peer-to-Peer, tambm conhecido
como P2P. Nesse modelo os ns so interconectados e tm a capacidade de atuar
tanto como cliente quanto como servidor. Ainda, so capazes de se auto organizar
em topologias de redes, com o objetivo de compartilhar recursos (arquivos, ciclos de
CPU etc.) (LOEST, 2007, p3).
Como mostra a Figura 3 os sistemas P2P so projetados de forma que os
componentes, chamados de ns, se comuniquem entre si e compartilhem recursos
por troca direta, via rede, sem a necessidade de um servidor central.
21
Figura 3 - Sistema distribudo P2P
Como a arquitetura P2P o foco desse trabalho, a seo seguinte apresenta

de forma mais detalhada os conceitos, exemplos e caractersticas relacionadas a
essa arquitetura.
2.2
Arquitetura Peer-to-Peer (P2P)
Os sistemas Peer-to-Peer tem ganhado afinidade entre desenvolvedores de

sistemas distribudos, e isto ocorre porque as redes P2P oferecem facilidade de
expanso caso esta seja necessria, alm de ter um custo mais baixo, se
comparada a outras arquiteturas.
Segundo Androutsellis-Theotokis e Spinellis (2004, p. 337) Peer-to-Peer so
sistemas distribudos constitudos de ns interligados capazes de se organizar em
topologias de rede com a finalidade de compartilhar recursos [...].
Estes ns podem trabalhar como cliente (ex. recebendo um arquivo) ou como
servidor (ex. transferindo um contedo). Os recursos compartilhados podem ser
apenas arquivos ou at mesmo ciclos de CPU, espao em disco etc.. Na Figura 4
mostrada a representao de uma rede P2P composta por quatro ns.
22
Figura 4 - Rede P2P
Na Figura 4 mostrada a ligao entre ns em uma rede P2P, sendo que

eles so equivalentes e funcionam como cliente ou como servidor. Em alguns casos,
podem existir super-ns, que so pares que utilizados para centralizar informaes
como localizao de pares, recursos etc., isto definido na aplicao.
A arquitetura P2P pode ser empregada em diversos tipos de aplicaes,
como para transferncia de contedo como fotos, vdeos, programas etc.. De acordo
com a finalidade da aplicao foram definidas diversas classificaes, as principais
so: comunicao e colaborao, computao distribuda, suporte de servios de
internet, sistemas de banco de dados, distribuio de contedo. Na prxima seo
abordada as caractersticas dessas classificaes.
2.2.1 Aplicaes P2P
Segundo Androutsellis-Theotokis e Spinellis (2004) a arquitetura P2P est cada vez
mais sendo utilizada no desenvolvimento de aplicaes. Estas aplicaes tm sido
utilizadas para diversos fins, alguns exemplos so:
Comunicao
colaborao:
esto
presentes
nesta
classificao
aplicaes que permitem que os usurios da rede se comuniquem, para

trocar mensagens de texto, voz, imagem etc. Este tipo de aplicao tem se
tornado comum entre os usurios de internet, pois existem muitos softwares
que utilizam a tecnologia, como exemplo: MSN Messenger, Skype, ICQ;
23
Computao
distribuda:
so
sistemas
que
utilizam
poder
de
processamento dos pares da rede para executar tarefas. Este tipo de

aplicao divide grandes processos em pequenas tarefas, que so
distribudas e balanceadas entre os pares e ainda utiliza o poder de
processamento deles para concluir estas tarefas, deste modo o sistema
ganha capacidade de processamento dependendo da quantidade de pares na
rede;
Streaming media: segundo Rodrigues e Druschel (2010, p.73) aplicaes

P2P mais populares so streaming media distribution e IPTV. Estas
aplicaes streaming P2P tem o objetivo de utilizar a largura da banda dos
pares da rede para replicar os dados de udio e vdeo, deste modo
economizando largura de banda de um servidor central;
Computao voluntria: so sistema no qual os pares fornecem ciclos de

CPU para terceiros. Neste caso geralmente os usurios da rede instalam uma
aplicao, que recebem e processam os dados de um servidor central e
retorna os resultados. Esse tipo de paradigma bastante utilizado para
clculos cientficos. Um exemplo de aplicao o SETI@Home que faz a
anlise de sinais de rdio do espao para detectar possveis emisses
extraterrestres (RODRIGUES, DRUSCHEL, 2010, p. 73);
Distribuio de contedo: aplicaes para distribuio de contedo so

bastante populares entre os usurios de sistemas P2P. Esto includas nesta
classificao aplicaes que permitem o compartilhamento de arquivos
(imagens, vdeos, documentos etc.) entre os usurios da rede. Exemplos de
aplicaes que esto nessa classificao so Kazaa, Gnutella, Napster.
O foco deste trabalho a distribuio de contedo entre os ns de uma rede

P2P, deste modo, na prxima seo abordado o funcionamento de uma aplicao
de distribuio de contedo.
2.2.2 Distribuio de contedo utilizando redes P2P

A utilizao de aplicaes P2P para distribuio de contedo tem se tornado comum
entre usurios da internet. Estes servios fornecem ao usurio meios de publicar,
buscar e recuperar arquivos de outros pares ou de locais de armazenamento da
rede. Os contedos compartilhados nessas aplicaes, normalmente, incluem
24
arquivos de msicas, vdeos, fotos e programas. A Figura 5 apresenta uma rede

P2P formada por quatro ns, que trocam contedos atravs de uma aplicao P2P.
Figura 5 - Compartilhamento de contedo em uma rede P2P
Na Figura 5 as setas representam a troca de informaes entre os pares, no

qual eles podem tanto transmitir quanto receber informaes. A arquitetura da rede
que vai definir a ligao entre os pares, deste modo a prxima seo aborda as
caractersticas das arquiteturas P2P.
2.2.3 Arquiteturas P2P de Distribuio de Contedo.
As redes P2P so formadas dentro de uma rede j existente (normalmente IP), e so
chamadas de redes overlay (sobreposta). As redes overlay fornecem recursos como
arquitetura de roteamento robusta para atingir reas amplas, busca eficiente de
dados, localizao de pares prximos etc., alm de caractersticas como
autenticao, anonimato, escalabilidade e tolerncia a falhas (LUA etal, 2004, p1).
As redes overlay podem ser diferenciadas por sua organizao, na qual
possuem regras para garantir o funcionamento coerente. As redes sobrepostas
podem ser: estruturadas e desestruturadas.
Estruturadas
So redes com alto controle no qual o contedo colocado em locais especficos,
para que consultas sejam feitas de forma mais eficiente (LUA et al, 2004, p. 2). A
25
rede define chaves nicas para os dados, organiza os pares e atribui a chave para
um ponto, isto permite que sejam realizadas consultas mais eficientes. Geralmente
redes estruturadas so baseadas em DHT (Distributed Hash Tables), no qual so
utilizadas para organizar os processos (ex. localizao). Segundo Vestola (2010, p.
2) DHT so sistemas descentralizados e distribudos de prestao de servios de
pesquisa semelhante a uma tabela hash.
Em redes baseadas em DHT os pares e objetos possuem identificadores
nicos, conhecidos como chave. As DHTs armazenam a chave e valor de um item
nos pares da rede, no qual a chave utilizada para identificar o objeto, e o valor o
identificador do n que responsvel pelo item. Exemplos de arquiteturas
estruturadas so: Freenet, Chord, CAN.
Desestruturadas
Nas redes P2P no estruturadas a ligao entre os pares estabelecida de forma
facultativa e no existe correlao entre um par e o contedo administrado por ele
(LUA et al, 2004, p. 2). Deste modo um par pode se conectar a outro utilizando
somente seu endereo fsico. Os itens podem ser disponibilizados em qualquer
ponto da rede e para encontr-los necessrio utilizar a busca por inundao, que
consiste em difundir a requisio entre os pares. Exemplos de arquiteturas no
estruturadas so: Napster, Gnutella.
Para o desenvolvimento deste trabalho, proposta a utilizao de uma rede

P2P descentralizada, deste modo, a prxima seo aborda as caractersticas desse
tipo de arquitetura.
2.2.4 Arquiteturas Desestruturadas
As
arquiteturas
desestruturadas
podem
ser
classificadas
em:
hibrida
descentralizada, parcialmente centralizada e puramente descentralizada.

Hibrida descentralizada
Neste tipo de rede, existe o papel de um servidor que executa aes como registro
de pares, servios de ndice (recursos disponveis), registro de grupos etc.
(VITHOFT, 2009, p. 10). Os pares da rede armazenam o contedo e compartilham
26
com a rede. Na Figura 6 apresentado o funcionamento de uma rede hibrida

descentralizada.
Figura 6 - Rede P2P Hibrida
Os clientes trocam informaes diretamente, porm existe intermdio do

servidor em casos de buscas, inicializao, publicao de recurso, conexo com a
rede etc.. Como mostrado na Figura 6, um par realiza uma consulta no servidor,
que retorna a informao de localizao de determinado dado. Quando obtida a
informao sobre a localizao, o par se conecta ao outro e realiza a transferncia
das informaes solicitadas. Exemplos de arquiteturas hbridas so: Napster e
Publios.
Parcialmente centralizada
Esta arquitetura caracterizada pela existncia de super-ns, que so definidos de
acordo com as caractersticas definidas pela rede (ANDROUTSELLIS-THEOTOKIS,
SPINELLIS, 2004, p. 346). Os super-ns possuem funes semelhantes de um
servidor, como exemplo indexao, cache e proxy para as requisies. Caso um
27
super-n falhe, a rede possui caractersticas para se auto organizar e definir um

novo. A Figura 7 mostra um exemplo de rede parcialmente centralizada.
Figura 7 - Rede P2P parcialmente centralizada
Os pares comuns ingressam e publicam recursos na rede com auxilio dos

super-ns. Como mostrado na Figura 7, os super-ns so interconectados, e em
conjunto com os pares comuns criam redes locais para realizar o processamento de
requisies de busca. Caso os pedidos no sejam encontrados na rede local, so
repassados para o super-n referente, que realiza o roteamento da requisio entre
os outros. Exemplo de arquitetura parcialmente centralizada o Kazaa.
Puramente descentralizada
Esta arquitetura caracterizada por no existir o papel de um servidor para
centralizar as aes da rede, todos os pares trabalham como servidor e cliente
(ANDROUTSELLIS-THEOTOKIS, SPINELLIS, 2004, p. 345). Os pares se conectam
diretamente, e no necessariamente precisam conhecer todos os outros. A Figura 8
mostra um exemplo de estrutura de uma rede puramente descentralizada.
28
Figura 8 - Rede P2P descentralizada
Na rede P2P mostrada na Figura 8 no existe um centralizador de aes para

comandar as requisies dos usurios, desta forma os pares da rede precisam se
comunicam diretamente para trocar informaes.
Como o objetivo do trabalho a implementao de uma aplicao P2P

descentralizada, esse tipo de arquitetura abordada na prxima seo.
2.2.5 Arquitetura Descentralizada
Em uma rede P2P descentralizada no se utiliza um servidor para comandar as
requisies enviadas na rede (BACKXet al, 2002, p. 2). Desta forma, no existe
pontos nicos de falha, tornando mais difcil a indisponibilidade da rede. De forma
arbitrria ou diretamente os pares descobrem a rede, no necessitando do servidor
para registr-los.
Qualquer par pode iniciar a rede e distribuir a tabela de vizinhos conectados
para novos membros. Caso algum dos pares se desconectar, a rede continua
funcionando, pois qualquer membro da rede pode fornecer os servios essenciais da
rede.
Um
exemplo
de
arquitetura
descentraliza
rede
Gnutella
(ANDROUTSELLIS-THEOTOKIS E SPINELLIS, 2004, p. 344), que formada por

pares conectados por meio do protocolo IP, que operam como servidor e cliente e
possuem uma tabela de roteamento dinmico. A Figura 9 mostra como um par se
conecta a rede.
29
Figura 9 - Incluso de novo membro na rede
Na rede descentralizada mostrada na Figura 9, um novo par envia uma

requisio para outro j conectado a fim de se conectar na rede, e recebe uma
resposta informando se a entrada foi permitida ou no. Quando conectado, um par
envia mensagens de tempos em tempos para seus vizinhos com intuito de descobrir
novos pares.
As mensagens servem para que os membros possam se comunicar e trocar
informaes. No Gnutella as mensagens possuem em seu corpo atributos
importantes (KLINGBERG, T., MANFREDI, R., 2002, online), como:
Message ID: identificado nico da mensagem na rede;
PayloadType: determina o tipo de mensagem. Exemplo: Ping, PongBye

etc.;
TTL (Time To Live): controla a propagao da mensagem. No qual

definido um valor, que decrementado a cada par percorrido. Quando o
valor chega zero significa que no tempo especificado a consulta no
retornou nenhum objeto;
Hops: quantidade de vezes que a mensagem foi encaminhada;
PayloadLength: tamanho de bytes do corpo da mensagem.
As mensagens tm papel importante por ser o meio de comunicao entre os

pares da rede (ANDROUTSELLIS-THEOTOKIS E SPINELLIS, 2004, p. 344).
30
Existem mensagens de controle como, por exemplo, para ingressar na rede, verificar
status etc.; e para troca de dados, que so os arquivos. So definidos quatro tipos
de mensagens, que so:
Ping: pedido de um determinado host para se anunciar;
Pong: resposta a uma mensagem de ping.
Query: mecanismo para realizar busca de recursos disponveis na

rede;
QueryHit: resposta a uma consulta. Este tipo de mensagem retorna ao

usurio
localizao
de
dados
encontrados
da
pesquisa
correspondente.
Por no existir um centralizador de aes, as mensagens so propagadas

pela rede por inundao, que consiste em distribuir a requisio entre os pares
vizinhos, que difunde a requisio entre outros membros. Na Figura 10 mostrada a
troca de mensagens a fim de encontrar um arquivo.
Figura 10 - Buscar um arquivo na rede descentralizada.
Para obter um determinado dado na rede, um par deve seguir alguns passos,
como mostrado na Figura 10, na qual a linha tracejada representa a ligao dos
pares e as setas indicam o caminho percorrido das mensagens. O peer A envia
uma mensagem de Query para seu vizinho peer B, que consequentemente distribui
31
a requisio com seu vizinho peer C, que repassa a mensagem aos vizinhos peer
D e peer E. Ao encontrar o arquivo no peer C, uma mensagem de QueryHit
retornada ao peer A, que originou a mensagem, contendo as informaes de
localizao do arquivo.
Em qualquer arquitetura P2P, as mensagens trocadas devem ser vistas e
modificadas somente por usurios autorizados, aumentando a segurana da rede, o
que discorrido na prxima seo.
2.2.6 Segurana P2P
Para garantir a segurana de uma rede algumas caractersticas devem ser levadas
em considerao (ANDROUTSELLIS-THEOTOKIS E SPINELLIS, 2004), entre elas
esto:
Integridade e autenticidade: garantir que as informaes no possam

ser modificadas por usurios no autorizados. E que membros no se
passem por outros.
Privacidade e confidencialidade: garantir que somente membros

autorizados possam ter acesso determinada informao.
Disponibilidade e persistncia: garantir que as informaes e a rede

sempre estejam disponveis quando o usurio desejar ou precisar.
As caractersticas citadas tendem a criar uma sensao de segurana no

usurio sobre os dados trocados na rede. Desta forma, necessrio que sejam
adotados mecanismos que no permitam acesso no autorizado e a integridade das
informaes. Entre os mecanismos existentes esto:
Auto certificao dos dados;
Esquema de Shamir Secret Sharing;
Retransmisso criptogrfica annima;
Public Key.
Auto certificao dos dados

Este mecanismo permite que um par ao recuperar um arquivo verifique sua
integridade. Isto feito por meio de um hash criptogrfico, que calculado no
32
momento que o arquivo postado e quando ele recuperado (ANDROUTSELLISTHEOTOKIS E SPINELLIS, 2004).
Esquema de Shamir Secret Sharing
Consistem em uma forma de criptografia, que gera uma chave para o arquivo
(ANDROUTSELLIS-THEOTOKIS E SPINELLIS, 2004). Esta chave dividida em
vrias partes e distribuda entre os pares da rede. Para recuperar o arquivo
necessrio unir todas as partes, afim de obter a original.
Retransmisso criptogrfica annima

A pessoa que ir publicar o contedo escolhe um conjunto de retransmissores e
envia para eles, utilizando conexes annimas, partes criptografadas do arquivo. Os
retransmissores, por sua vez, escolhem alguns pares para armazenar as partes que
foram recebidas. No instante que todas as partes so armazenadas, a pessoa
responsvel pela publicao destri as partes originais e anuncia o arquivo, com a
respectiva lista de retransmissores.
Quando o cliente quer recuperar um arquivo, ele entra em contato com os
retransmissores, que entram em contato com servidores aleatrios, para repassar
a requisio para os pares que possuem o contedo. Por fim, esses pares
decodificam o contedo e o enviam para o cliente.
Public Key
Mecanismo de criptografia que gerar duas chaves, chave pblica e chave privada,
no qual so relacionadas (MIZANI, 2005, p. 21-22). As informaes criptografadas
pelo mecanismo so recuperadas utilizando as duas chaves correspondentes. Em
uma rede P2P a chave pblica armazena junto ao arquivo, e somente um par que
possuir a chave privada pode decodificar e recuperar a informao, na Figura 11
mostra essa comunicao.
33
Figura 11 - Recuperando informao com chave pblica
Na Figura 11 mostrado como um par consegue recuperar uma informao,

em que o Peer A possui uma chave privada de determinado objeto presente no
Peer C. O Peer A envia uma query requisitando o arquivo, como ele possui a
chave privada correspondente a chave pblica do objeto, o Peer C retorna o que
foi solicitado. J o Peer B por no possu a chave privada necessria no recebe
nenhuma informao.
Esses mecanismos de segurana fornecem confiabilidade se forem includos

no desenvolvimento das aplicaes. Existem diversas tecnologias disponveis para
se aplicaes P2P, e que ainda fornece tais mecanismos, entre elas a JXTA. Que
de cdigo aberto e vem sendo bastante utilizada em diversos projetos. Suas
caractersticas so abordadas na prxima seo.
2.3
Tecnologia JXTA
O JXTA uma tecnologia de cdigo aberto, projetada para redes P2P, desenvolvida
pela Sun Microsystems, com a participao de empresas, universidades, entre
outros colaboradores. Segundo Gong (2001, p. 88) a tecnologia JXTA uma
plataforma de desenvolvimento computacional e de redes que foi projetada para
34
resolver problemas na computao distribuda, mais especialmente para sistemas

P2P.
Entre as tecnologias existentes para se desenvolver aplicaes P2P, o JXTA
tem
ganhado
afinidade
entre
os
desenvolvedores,
isto
porque
oferece
funcionalidades que facilitam a implementao de redes P2P, que possibilitam a

conexo dos pares independe da sua localizao, por ser uma ferramenta
independente de linguagem de programao e por funcionar em qualquer dispositivo
com tecnologia digital (SUN, 2001, p. 1).
Uma rede JXTA constituda por pares, que enviam anncios na rede e
ingressam em grupos de pares, utilizando mensagens e passando por canais virtuais
denominados Pipes, para a formao das redes P2P(SUN, 2001, p. 4). Esses pares,
anncios, grupo de pares etc., so denominados conceitos em uma rede JXTA. Os
conceitos existentes so utilizados pela tecnologia como forma de identificar uma
ao ou componente da rede, que so:
Peers: qualquer dispositivo (computador, telefones, sensores etc.) que

utilize qualquer protocolo JXTA, de forma que possam se comunicar
entre si considerado um Peer (Par). Cada par da rede funciona de
forma independente e assncrona e so identificados com um ID nico.
Os pares utilizam uma ou mais interfaces de rede para uso dos
protocolos JXTA, anunciadas na rede como um ponto de extremidade,
utilizadas para estabelecer conexes diretas entre os pares.
PeerGroups: um grupo de pares composto por um conjunto de

pares, geralmente, com interesses em comum. O JXTA no cita
normas de quando, onde e por que um grupo de pares deve ser criado.
Normalmente, o objetivo agrupar pares com interesses em comum,
criar um ambiente seguro etc.
Identifiers
(ID):
JXTA
utiliza
identificadores
de
128
bits,
denominados UUID, para referir-se a entidades (par, anuncio, servio

etc). Cada entidade possui um identificador exclusivo, e para expressar
esses identificadores o JXTA utiliza URI (Uniform Resource Identifier).
As ID so apresentadas em formato texto.
Advertisements: todos os recursos da rede so representados em

forma de anncios, como exemplo os pares, grupos de pares, servios
etc.. Os anncios, tipo de mensagem mais trocada no JXTA, so
35
metadados utilizados para representar recursos. Ele pode descrever a

disponibilidade (vida til) de um recurso na rede, e pode ser
republicado para aumentar a vida til de um recurso (SUN, 2007, p. x).
Messages: so informaes transmitidas por canais virtuais entre os

pares, que podem armazenar qualquer tipo de dado e so transmitidas
em formato XML ou em representaes binrias. As mensagens ainda
contm informaes de roteamento, direcionamento e a sequncia de
pares a ser percorrida at chegar ao destinatrio.
Pipes:
so
canais
virtuais
de
comunicao
unidirecionais
assncronos que conectam dois ou mais pares da rede, que

possibilitam a troca de mensagens independente da sua localizao,
topologia e protocolo de rede. Os pipes podem ser do tipo Receiver
(recebe dados) ou Transmitter (transmissor de dados) (SUN, 2007, p.
xi) e oferecem dois tipos de comunicao:
o Ponto a ponto: conecta dois pontos da rede, um receptor e um
transmissor de dados.
o Propagao: faz a conexo de um ponto transmissor a vrios
outros pontos receptores. Todas as mensagens enviadas de um
ponto transmissor so enviadas aos pontos receptores.
Network Services: servios de rede podem ser vistos como um

conjunto de operaes disponibilizadas a serem utilizadas via rede. Os
pares trabalham em conjunto para publicar, descobrir e invocar
servios de redes. Estes servios so executados por um par da rede
por um grupo de pares.
O JXTA se diferencia das outras tecnologias existentes por oferecer recursos

que permitem que os pares conectados possam, facilmente: se localizar, se
comunicar e fornecer servios aos outros pares. Isso se deve a sua arquitetura e aos
seus protocolos, que so descritos nas prximas sees.
36
2.3.1 Arquitetura JXTA

A arquitetura da JXTA dividida em trs camadas, que so (2002, p. 3):
JXTA Core: comparada ao kernel de um sistema operacional, abriga as

funcionalidades primrias de uma rede P2P, entre elas comunicao (criao
de pares, descoberta, gesto de comunicao, roteamento etc.) e segurana.
JXTA Services: esta camada do JXTA composta por itens que no so

obrigatrios em uma rede P2P, mas, que so desejveis. Entre as
funcionalidades disponveis nesta camada esto busca, indexao, sistema
de armazenamento, compartilhamento de recursos, traduo de protocolo,
autenticao etc.. Esta camada oferece recursos necessrios para a
colaborao entre os pares, independente da plataforma.
JXTA Applications: abriga as aplicaes que utilizam a tecnologia como os

mensageiros instantneos,
compartilhadores de arquivos etc.. Essas
aplicaes utilizam as funcionalidades das outras camadas.
A Figura 12 apresenta as trs camadas do JXTA, que abrigam os protocolos e

as funcionalidades necessrias para o funcionamento da rede P2P.
Figura 12 - Camadas JXTA (MAINBAUM, MUNDT. 2002, p. 3)
Na Figura 12 so apresentadas as camadas da arquitetura do JXTA, na qual

as funcionalidades bsicas para o funcionamento de uma rede P2P esto presentes
na camada JXTA Core e nas outras duas camadas, JXTA Services e JXTA
Applications, esto presentes os protocolos especficos de cada aplicao, que so
apresentados na prxima seo.
37
2.3.2 Protocolos JXTA

O JXTA oferece ao desenvolvedor um conjunto de protocolos que possibilitam aos
pares da rede se auto organizar e se autoconfigurar independente de sua posio na
rede e sem a necessidade de um servidor para guiar as aes (SUN, 2007, p. 2).
O JXTA oferece seis protocolos, sendo que, ao se implementar uma aplicao
P2P usando essa tecnologia, pelo menos um deles deve ser implementado, que so
eles:
Peer Endpoint Protocol: responsvel pelo roteamento de mensagens e

descobrir caminhos entre os pares para que as mensagens cheguem ao
destino. Este protocolo ignora a existncia de firewalls ou redes lgicas
(NAT), quando um par um roteador e possu a rota para o destino, a
mensagem enviada diretamente para o destino final, sem necessidade de
buscar novamente em outro roteador (GONG, 2001, p. 91);
Peer Resolver Protocol: permite a um par da rede emitir consultas genricas

como busca de parese grupos de pares e, posteriormente, identificar as
respostas
correspondentes.
Cada
consulta
ou
resposta
possui
um
identificador nico (MAIBAUM, MUNDT, 2002, p. 4);
Peer Discovery Protocol: este protocolo permite que um par encontre recursos
anunciados na rede.
Permite que o par encontre outros pares, grupo de
pares e anncios emitidos por estes. Pares que implementam esse protocolo
podem, ainda, ajudar outros na busca de recursos na rede (SUN, 2007, p.
32);
Pipe Binding Protocol: esta funcionalidade permite que sejam criados canais
virtuais de comunicao entre pares. Estes canais virtuais permitem criar,
abrir/resolver, fechar, excluir, enviar e receber operaes (SUN, 2007, p. 44);
Peer Information Protocol: permite que um par da rede saiba a situao de

outro par. Alm de obter informaes como trfego de carga, tempo de ativo
etc.. Um par da rede no precisa, obrigatoriamente, implementar este
protocolo, caso este no possua as mensagens de informaes sobre o par
so ignoradas (GONG, 2001, p. 91);
Peer Membership Protocol: por meio deste protocolo, os pares podem se

organizar e formar grupos com intuito de criar uma rede de segurana. Estes
38
pares utilizam este protocolo para ingressar ou sair de um grupo j existente

na rede, e ainda para descobrir grupos existentes (GONG, 2001, p. 91).
A Figura 13 mostra a ligao existente entre os protocolos e as camadas que

cada um compe.
Figura 13 - Protocolos JXTA (MAIBAUM, MUNDT. 2002. p. 4)
A Figura 13 mostra os protocolos do JXTA, as setas ligam os protocolos

comuns dos pares da rede. Os protocolos trabalham acima da camada de
transporte, e so agrupados em quatro camadas diferentes, como mostrado na
Figura 13. Na camada Endpoit existe o protocolo que realiza o roteamento de
mensagens e descobre caminhos entre os pares. A camada Resolver composta
pelo protocolo que permite ao par realizar consultas na rede e identificar resposta
para as buscas. A camada Peer caracterizada pelos protocolos que trabalham com
a descoberta de recursos na rede, a criao de canais entre os pares e ainda
funcionalidades para descobrir a situao de outros pares na rede. Por fim a camada
PeerGroup, que fornece servios relacionados a grupo. Essas camadas servem para
reunir protocolos com caractersticas em comum.
O objetivo deste trabalho utilizar a tecnologia JXTA na criao de

redes P2P para a realizao de backups cooperativos, por isso, a prxima seo
discorre sobre backup.
39
2.4
Backup Cooperativo
Com o crescimento do uso de computadores por usurios comuns e por empresas,

tem-se tornado comum a utilizao de dados digitais. Deste modo, a quantidade de
dados armazenados em computador cada vez maior, que podem ser documentos
importantes, softwares, mensagens de e-mail etc.. Dessa maneira, importante que
esses dados no sejam perdidos, afim de no causar prejuzos a quem precisa das
informaes, e uma forma de garantir isso a cpia de segurana, ou backup.
Segundo Faria (2010, p. 1) backup (ou cpia de segurana) consiste na
cpia de especficos (redundncia) para serem restaurados no caso da perda dos
originais. Existem diversas formas de realizar a cpia de segurana de arquivos,
que vo desde a cpia em discos at cpias em nuvem. Independente de como os
dados tenham sido armazenados, os backups so realizados para minimizar a
probabilidade de perda de dados.
Nos servios de backup cooperativos os recursos pertencentes a mltiplos
usurios so colocados juntos como em um sistema de armazenamento distribudo
para que cada um faa o backup dos dados do outro (LOEST, 2007, p. 32). Neste
caso, os usurios da rede disponibilizam espao de armazenamento em suas
mquinas para que outros usurios possam guardar seus arquivos. Assim, o usurio
garante que mais cpias estejam disponveis caso precise restaurar um arquivo
perdido.
No que diz respeito s necessidades dos usurios existem alguns tipos de
backup e no que diz respeito aos backups em rede podem existir duas topologias, os
backups centralizados e os backups descentralizados. Essas formas de backup so
abordadas na prxima seo.
2.4.1 Tipos de backup

Para garantir que integridade de seus arquivos, assim como as modificaes feitas,
os usurios tendem a realizar cpias de segurana de tempos em tempos.
As
cpias evitam problema com a perda de dados no futuro. Deste modo necessrio
que o usurio determine estratgias para realizar estas cpias, pois de forma
aleatria, os dados ou modificaes, poderiam ser ignorados (JUNIOR, 2010, p. 13).
Para auxiliar os usurios a criarem suas estratgias foram definidos alguns tipos de
backup, que os mais comuns so: Completo Full, Incremental e Diferencial.
40
Completo - Full
Os dados so copiados de todos os arquivos ignorando se foram modificados ou
no. Esse tipo geralmente executado em intervalos de tempo maiores do que os
outros, pois o tempo de cpia pode ser muito grande dependendo do volume de
dados a ser gravado. Caso seja necessria uma restaurao dos dados, basta
executar a ltima cpia gravada.
Incremental
Nesse modelo de backup so realizadas cpias dos arquivos modificados desde a
ltima cpia completa ou cpia incremental. Na Figura 14 apresentado como os
dados de um backup incremental crescem durante um perodo de tempo.
Figura 14 - Backup incremental adaptado (IBM, 2004, online)
Na Figura 14 mostrado que uma cpia completa foi executada no domingo e

os arquivos modificados ao longo da semana so adicionados ao backup completo,
atualizando a cpia inteira. Nesse modelo, caso seja necessria uma restaurao,
basta executar a cpia completa.
Diferencial
Este tipo de backup bem parecido com o modelo incremental, mas, os dados
modificados ou criados so gravados em arquivos parte. Na Figura 15 mostrado
o crescimento de cpias utilizando o modelo diferencial.
41
Figura 15 Backup diferencial (IBM, 2004, online)
O modelo apresentado na Figura 15 mostra que foi criado um backup

completo e ao longo do perodo percorrido cpias menores so criadas, essas
cpias so de arquivos novos ou modificados. Nesse tipo de backup, caso seja
necessrio recuperar os itens, preciso restaurar a cpia completa e todos os outros
diferenciais criados depois dele.
Os tipos de backup citados so empregados de acordo com a necessidade do

usurio, quantidade de dados etc.. As polticas empregadas para a criao de cpias
de segurana pode usar todos os tipos de backup, de formas e ocasies distintas.
Por exemplo, uma empresa realiza diariamente backups diferenciais, e nos fins de
semana executa um backup completo.
As cpias podem ser armazenada em diversos lugares, como fitas, discos
externos etc. Com a disponibilidade de uma rede, os dados podem ser gravados em
outros computadores. Desta forma so definidas algumas formas de backup para
armazenamento em rede, e so abordados na prxima seo
2.4.2 Backup em rede

Utilizar computadores de uma rede para guardar arquivos pode ser uma alternativa,
considerando que as informaes ficam armazenadas em outros locais fsicos e,
caso a fonte original falhe, as cpias estaro protegidas e podero ser recuperadas.
Em redes locais, podem ser utilizados servidores para armazenar os dados,
porm, devem possuir grande capacidade de armazenamento, o que requer um alto
investimento. Uma alternativa para evitar gastos utilizar o espao de
armazenamento disponvel nas mquinas da rede para guardar cpias de
segurana. Deste modo existem duas topologias que podem ser empregadas aos
backups em rede que so: Backup centralizado e Backup descentralizado.
42
Backup centralizado
Em um ambiente no qual empregado o backup centralizado, os usurios utilizam
uma mquina central para armazenar as cpias de segurana de seus arquivos
(JUNIOR, 2010, p. 18). O computador que armazena esses backups, geralmente,
so servidores com grandes capacidades de armazenamento e, normalmente, so
utilizados em corporaes. Na Figura 16 mostrado um exemplo de funcionamento
do backup centralizado.
Figura 16 - Backup centralizado
Na Figura 16 mostrada a utilizao de um servidor para guardar cpias de

arquivos dos usurios da rede. No qual as estaes da rede efetuam cpias para o
disco do servidor e, tambm, realizam restaurao de cpias realizadas
anteriormente.
Backup descentralizado
Um ambiente descentralizado quando as mquinas da rede guardam cpias de
seus arquivos em mais de um local como forma de minimizar perdas em caso de
falhas (JUNIOR, 2010, p. 17). Deste modo, se ocorrer problemas em um dos locais
no qual o backup foi armazenado, a restaurao pode ser feita em outro local no
43
qual os dados foram armazenados. Um exemplo de ambiente descentralizado pode

ser observado na Figura 17.
Figura 17 - Backup descentralizado
Em um ambiente que utilizado backup descentralizado, as cpias de um

mesmo arquivo so replicadas em locais diferentes, como mostrado na Figura 17.
Uma estao da rede realiza a cpia de um arquivo e este armazenado em dois
servidores diferentes. Deste modo, caso um deles venha a falhar, o outro possui
uma cpia idntica dos dados.
Os conceitos citados durante o decorrer do referencial terico serviram como
base para a execuo do projeto. Os materiais utilizados durante a execuo, a
metodologia aplicada e os resultados dos projetos so mostrados nas sees
seguintes.
MATERIAIS E MTODOS
Nesta seo so apresentados os detalhes sobre a realizao do projeto, tais como

materiais utilizados no decorrer do trabalho, o conjunto de hardware utilizados e a
metodologia adotada no desenvolvimento da aplicao.
3.1
MATERIAIS
A primeira etapa do trabalho consistiu no estudo referente aos conceitos envolvidos

no projeto. Desta forma, diversas fontes bibliogrficas foram utilizadas, como livros,
dissertaes, artigos, teses, monografias etc.
Todas as etapas de implementao e testes foram realizados sobre o sistema
operacional Windows 7, tendo como hardware um computador Intel Core2Duo
E7500 2.93Mhz, 4GB de memria RAM.
No trabalho foram utilizados diversos materiais, que so divididos em duas
categorias: Hardware e Software.
Hardware
Como um dos objetivos do trabalho foi a implementao de uma rede Peer-to-Peer,
foi necessrio criar um ambiente de rede com algumas mquinas para validar o
funcionamento da aplicao.
Devido dificuldade da criao de um ambiente com mquinas reais, foi
decidido criar um ambiente virtual para simular uma rede de computadores. Neste
ambiente foram criadas trs mquinas virtuais sobre o hardware informado
anteriormente.
Cada mquina virtual foi configurada com 512 Mb de memria e disco rgido
de 10 Gigabytes. O sistema operacional escolhido foi o Windows XP, por no
necessitar de muitos recursos de hardware para seu funcionamento.
Software
Na fase de projeto da aplicao foi utilizado o software Microsoft Visio 2010 para a
criao dos diagramas de caso de uso, que descrevem funcionalidades que
45
necessitam da interao do usurio, e do diagrama de classes, que representa as

entidades presentes na aplicao.
Na fase de desenvolvimento foram utilizados os seguintes softwares:
Java, verso 7: linguagem utilizada para criar a aplicao de backup. Foi

escolhida por possuir quantidade superior de referncias sobre o JXTA na
verso JAVA, comparado outras linguagens de programao;
JXTA
2.5
verso
Java:
utilizada
para
desenvolvimento
das
funcionalidades de uma rede P2P. Sendo o objetivo do trabalho utilizar

esta tecnologia, e seu uso foi definido sem comparar com outras.
JDom 2.0: fornece uma soluo completa para a manipulao de dados

XML, utilizado para acesso ao banco de dados da aplicao que em
arquivo XML. Ferramenta escolhida por ser open source e por fornecer as
funcionalidades necessrias para manipulao de arquivos XML;
VMWare Player: ferramenta gratuita utilizada para a criao das mquinas

virtuais, afim de simular uma rede de computadores. Por ser uma
ferramenta gratuita foi agregada ao trabalho;
IDE NetBeans verso 7.2.1: ferramenta gratuita utilizada para auxiliar no

desenvolvimento da interface grfica e dos cdigos;
Adobe Fireworks CS5: utilizado para manipulao das imagens e cones

presentes na aplicao;
Microsoft Visio 2010: ferramenta que permite a criao de diagramas

UML. Utilizado na criao de diagrama de classes e casos de uso.
As ferramentas foram utilizadas durante o processo de implementao da

aplicao e a maioria foram escolhidas por serem de cdigo aberto ou gratuitas,
alm da facilidade de se usar. As ferramentas auxiliaram durante o processo de
execuo do trabalho. A seguir apresentada a metodologia do trabalho, que o
detalhamento das tarefas executadas com intuito de desenvolver o projeto.
3.2
Metodologia
A primeira etapa do projeto consistiu na coleta de referencial terico sobre o domnio

do projeto, que envolve Sistemas Distribudos, P2P, JXTA e Backup cooperativo.
46
Paralelamente coleta, foi realizado o estudo dos materiais coletados e a

elaborao do referencial terico.
A segunda etapa do trabalho foram executadas as fases de projeto e
desenvolvimento de uma aplicao de backup P2P. A sequncia executada para a
realizao do projeto mostrada na Figura 18.
Figura 18 - Etapas de execuo do projeto
Na Figura 18 so mostradas as etapas executadas durante a realizao do

trabalho. No incio, na etapa de Coleta de requisitos, foi realizada uma pesquisa em
sistemas de backup e compartilhamento de informaes, com o intuito de verificar
requisitos bsicos que devem ser fornecidas ao usurio. A partir disso foram
definidos os requisitos da aplicao Peer Backup, que a implementao de uma
aplicao de backup P2P.
Aps a coleta de requisitos foram definidos requisitos no funcionais para a
implementao da aplicao, que so:
47
criao de rede P2P, de arquitetura descentralizada. Esta arquitetura foi

designada por ter a caracterstica de no precisar de um servidor para
comandar as aes, sendo possvel utilizar a capacidade j existente na
rede local;
envio dos arquivos completos para as mquinas da rede P2P, isto porque
as cpias ficaro em computadores pessoais dos usurios que decidirem
entrar na rede e no momento da restaurao pode ser que nem todos os
usurios estejam conectados, e caso os dados fossem separados em
partes ocasionaria problema na recuperao do arquivo;
uso
de
criptografia
simtrica
para
garantir
privacidade
confidencialidade. Definiu-se chave simtrica por no ser preciso o

compartilhamento da chave de criptografia, pois somente o dono dos
arquivos devem recuper-los e visualiz-los;
Por meio dos requisitos definidos, foi possvel ter uma base das necessidades
do software, e a partir da foi iniciado o processo de desenvolvimento da aplicao,
que consistiu em:
criao do diagrama de classes, que representa as classes desenvolvidas

na aplicao e seus respectivos relacionamentos. Por meio do diagrama
foi possvel definir as entidades a serem implementadas e as respostas
que o sistema deve fornecer ao usurio a cada ao.
elaborao dos cenrios de uso, que so possveis situaes em que um

usurio pode se deparar ao realizar uma ao via interface grfica como o
envio e recuperao de arquivos. Os cenrios descritos so baseados nos
casos de uso gerados, em que o usurio precisa interagir com a aplicao.
Foram utilizados para definir as funcionalidades referente a manipulao
de arquivos na rede P2P;
codificao, o produto da implementao, que aplicao propriamente

dita. Consiste na implementao das funcionalidades para a criao e
manuteno da rede P2P, para a manipulao do backup e na interface
grfica. Nesta fase foram realizadas as seguintes etapas:
48
o desenvolvimento da interface grfica, a partir dela os usurios

solicitam as aes, que fazem a manipulao dos arquivos e das
funcionalidades da rede;
o criao do modelo de dados, que responsvel por armazenar
informaes dos arquivos enviados. Foi utilizado como base de
dados um arquivo XML para armazenar os dados dos arquivos
enviados e um arquivo de texto para armazenar o nome do usurio,
dispensando a utilizao de um SGBD;
o desenvolvimento das funcionalidades para a criao da rede e dos
mtodos utilizados pela aplicao durante o funcionamento.
Aps a implementao, foi necessrio realizar a validao da aplicao, com

o intuito de verificar se os requisitos citados foram cumpridos. Os testes foram
realizados sobre um ambiente virtual para simular uma rede de computadores, isto
devido s dificuldades de se criar um ambiente real. Em um ambiente real a
aplicao pode sofrer variao, como velocidade de trfego de dados, bloqueios
realizados por firewalls etc, que impacta a anlise e medio de desempenho da
soluo.
Para a validao foram realizados os seguintes testes na aplicao, sendo
que estes foram definidos:
Teste de interface: realizado de forma manual com intuito de verificar o

comportamento geral da aplicao e se o sistema oferece ao usurio o
que proposto. Nesse teste foram verificados layout, criao e
autenticao da rede P2P, aes de envio, de recuperao de arquivos e
configurao do sistema. Para esse teste foram utilizados usurios e
arquivos fictcios;
Teste de privacidade e autenticidade: realizado com intuito de verificar se

os usurios que possuem os arquivos conseguem visualizar os dados de
outros usurios, o que no deve ocorrer. Para realizar a verificao foi
enviado um arquivo qualquer para backup e, depois, na mquina destino,
foram realizadas tentativas de visualizar utilizando uma aplicao qualquer
que leia o formato do arquivo enviado. A garantia da privacidade e
autenticidade acontece quando um usurio da rede possui o arquivo, mas
no consegue abri-lo sem a chave secreta.
49
Essa seo apresentou as etapas executadas para o desenvolvimento do

projeto. Os resultados obtidos, os artefatos gerados e a descrio dos testes esto
apresentados na prxima seo.
50
RESULTADOS E DISCUSSES
O presente trabalho consistiu no desenvolvimento de uma aplicao de
backup P2P utilizando a plataforma JXTA, denominada Peer Backup. Essa aplicao
fornece ao usurio funcionalidades para a criao de cpias de segurana em
computadores de uma rede local, utilizando uma rede lgica P2P sobreposta a rede
fsica. Com isso, permite que os usurios se comuniquem diretamente e que
compartilhem dados e recursos como memria ram, espao em disco, ciclos de cpu.
Os pares da rede P2P so os usurios que esto utilizando a aplicao nos
computadores da rede. A comunicao entre os pares pode ser referente a busca
por pares e anncios e manipulao de arquivos. Cada par utiliza uma chave de
segurana que serve para cifrar arquivos e conectar-se aplicao.
Antes de serem enviados aos outros pares, os arquivos so cifrados com a
chave do usurio e os nomes so alterados e codificados utilizando o algoritmo
base64, com intuito de que outros usurios no tenham acesso ao nome e formato
de arquivo. Os dados so enviados integralmente para os pares, desta forma, para a
recuperao preciso da chave do usurio e um membro da rede possuir o arquivo.
importante ressaltar que as informaes enviadas aos outros pares devem
ser lidas e modificadas apenas por usurio que possui a chave de criptografia
referente ao arquivo. Para garantir a privacidade dos dados contidos nos arquivos,
utilizada a criptografia simtrica, na qual o usurio fornece uma chave que aplicada
na cifragem dos dados.
Os critrios e requisitos da aplicao so apresentados na metodologia, e
foram a base para o seu desenvolvimento. A partir dessas definies foram gerados
os artefatos de software que so apresentados no decorrer desta seo na seguinte
ordem:
Arquitetura da aplicao;
Estrutura interna da aplicao;
Cenrios possveis no uso da aplicao;
A aplicao Peer Backup; e
Testes.
51
4.1
Arquitetura da aplicao Peer Backup
As estruturas baseadas em redes P2P se distinguem pela existncia ou ausncia de

servidores que centralizam aes de controle da rede P2P. Nesse contexto, as redes
P2P so divididas em hbridas, parcialmente centralizadas e descentralizadas,
conforme foi descrito na seo 2.2.4.
A aplicao Peer Backup tem por objetivo utilizar recursos disponveis nas
mquinas de uma rede local, por isso foi utilizada a arquitetura descentralizada, que
dispensa a necessidade de aquisio de qualquer tipo de mquina para comandar
as aes da rede.
Por ser descentralizada, na Peer Backup os pares trabalham como servidor
e/ou cliente, comunicando-se diretamente entre si e podendo iniciar uma rede P2P
ou ingressar em uma j existente. A Figura 19 mostra a arquitetura da aplicao.
Figura 19 - Arquitetura Peer Backup
Na Figura 19 mostrado vrios pares conectados em uma rede P2P, sendo

que podem trabalhar como cliente ou servidor. Os pares que trabalham como cliente
enviam requisies para o par servidor atual. Existem mecanismos que selecionam
os pares com maior capacidade computacional para servir de servidor, na aplicao
caso
par
que
est atuando
como
servidor se
desconecte da rede,
automaticamente e de forma aleatria, outro escolhido, evitando que a rede fique

indisponvel. Com isso, garante-se a tolerncia a falhas.
52
A prpria aplicao presente em cada computador fornece as funcionalidades

de manipulao da rede (iniciar, autenticar, ingressar etc.) e realiza todo o processo
de forma transparente ao usurio. Assim, os pares da rede so procurados e
encontrados pela aplicao e no preciso que o usurio conhea informaes
sobre a localizao fsica dos demais ns como, por exemplo, endereo IP.
A implementao da aplicao foi feita em camadas, separando as
funcionalidades disponveis ao usurio das que so de uso exclusivo da aplicao. A
Figura 20 mostra a diviso entre as camadas do sistema.
Figura 20 - Funcionamento do Peer Backup
A aplicao Peer Backup se divide em duas camadas: interface e

funcionamento interno, como mostrado na Figura 20. A camada de interface fornece
ao usurio uma interface grfica, enquanto a camada de funciomento interno
responsvel pelos servios de rede e fornecer suporte camada superior.
A camada interface se refere parte visual da aplicao, atravs da qual o
usurio pode solicitar as aes de backup, como: envio, busca e recuperao de
arquivos. Essas aes utilizam mtodos existentes na camada inferior.
A camada funcionamento interno transparente ao usurio e fornece servios
camada de interface, como: a criao da rede,
autenticao de usurios e
53
comunicao entre os pares. Nessa camada so implementados os mtodos de

manipulao da rede, que implementam funcionalidades como verificao de
integridade dos dados, localizao de pares etc..
Na camada de funcionamento interno as tarefas que mantm a rede em
funcionamento so executadas por threads, de modo que as atividades de controle
so executadas em paralelo aos outros servios de rotina (autenticao do usurio,
recuperao de arquivos etc.).
As camadas do sistema possuem dependncias e trabalham em conjunto,
com intuito de executar as aes solicitadas pelo usurio. Os mtodos de
gerenciamento de arquivo so implementados na camada de funcionamento interno,
mas por meio da interface que o usurio faz as requisies das aes
implementadas pelos mtodos.
Para auxiliar no desenvolvimento das funcionalidades descritas nas camadas
do sistema foram gerados artefatos, que so detalhados na prxima seo.
4.2
Diagrama de classes
O diagrama de classes representa a estrutura da aplicao, como as classes
e o relacionamento entre elas, alm de demonstrar os atributos/propriedades e as

operaes do sistema referentes ao sistema. O diagrama de classes da aplicao
Peer Backup mostrado na Figura 21.
54
Classe::ListRequestor
-Resultado_Busca : ContentAdvertisement[]
-Opcao : int
-Thread_Manager : ThreadPoolExecutor
-Grupo_Backup : PeerGroup
-Arquivos : ArrayList<Arquivo>
+notifyMoreResults()()
Classe::Arquivo_Buscar_Thread
Classe::Arquivo
-id : String
-nome : String
-tamanho : long
-data_envio : calendar
-caminho_original : String
+toString()()
+getId()()
+setId(id)()
+getNome()()
+setNome(String nome)()
+getTamanho()()
+setTamanho(long tamanho)()
+Cifrar_Nome(String nome)()
+Decifrar_Nome(String nome)()
+Criptografar(String chave,Peer p)()
+getDataEnvio()()
+setDataEnvio(Calendar data)()
-Grupo_Backup
-Query_Busca
-List_Requestor
-Tempo_Inicio_Thread
-Opcao
-Arquivos
+run()()
Classe::JXTA_Service
-GrupoGlobal : PeerGroup
-DS_Padrao : DiscoveryService
-DS_Backup : DiscoveryService
-PGA_Backup : PeerGroupAdvertisement
-Grupo_Backup_ID : String
-Auth : Authenticator
+Comecar()()
+Iniciar_Rede()()
+Force_Iniciar_Grupo()()
+Pesquisar_Grupo_Existente()()
+Ingressar_Grupo(PeerGroup grupo)()
+Log(String texto)()
+Criar_Novo_Grupo()()
+getGrupo()()
Classe:Interface
Classe::Download
-Objetos : Object []
+Download(PeerGroup g, ContentAdvertisement c, File f, Object [] o)()
+notifyUpdate()()
+notifyDone()()
+notifyFailure()()
Classe::Download_Thread
-Anuncio : ContentAdvertisement
-Arquivo : File
-Objetos : Object []
+run()()
Classe::Share
-Pasta_Shared : File
-cms : CMS
+Iniciar_CMS()()
+run()()
-Peer : Peer
-Arquivos : ArrayList<Arquivo>
-Rede : JXTA_Service
-Pares_Thread : Peer_Thread
-Arquivo_Enviar : Arquivo
-Compartilhar : Share
-Logado : boolean
-inDownload : boolean
-Arquivos_Busca : ArrayList<Arquivo>
+Atualizar_Lista_Arquivos()()
+to16bytes(senha)()
+Login()()
+Verifica_Base()()
+Atualizar_Lista_Pares()()
+Carregar_Base()()
+Buscar_Meus_Arquivos()()
+main()()
Classe::Peer_Thread
-DS_Padrao : DiscoveryService
-Lista_Pares : JList
-Tempo_Inicio_Thread : long
+discoveryEvent(DiscoveryEvent d)()
+Gerar_Lista_Pares(Enumeration e)()
+sets()()
+run()()
Classe:Peer
-id : String
-nome : String
-password : String
+gets()()
+sets()()
+verifyPassword(senha)()
Figura 21 - Diagrama de classes da aplicao
Como mostrado no diagrama de classes da Figura 21, o sistema possui 10

classes. A classe Interface referente a parte grfica do sistema, sendo
responsvel por controlar o sistema e acionar mtodos de outras classes. As demais
classes do sistema, que fazem parte da camada de Funcionamento Interno,
possuem relacionamento direto ou indireto com a classe Interface
O detalhamento da classe Interface, de seus atributos e mtodos, est
presente na Tabela 2.
Tabela 1 - Classe Interface
Classe: Interface
55
Responsvel pela inicializao da aplicao, chamada de mtodos e interface visual

do sistema. Interage diretamente com o usurio.
Atributos:
Peer: referente ao usurio (classe Peer) que est conectado ao sistema;
Arquivos: lista de arquivos enviados pelo usurio;
Rede: instncia da classe JXTA_Service, responsvel por iniciar e controlar

a rede;
Pares_Thread: servio utilizado para realizar busca por pares conectados

rede;
Arquivo_Enviar: referente ao arquivo que o usurio pretende enviar;
Compartilhar: instncia de File referente pasta que possui os arquivos a

serem compartilhados pelo usurio;
inDownload: informa se existe um download em execuo;
Arquivos_Busca: lista de arquivos recuperados em uma varredura nos

pares online.
Mtodos:
Atualizar_Lista_Arquivos(): atualiza lista de arquivos enviados pelo

usurio;
to16bytes(): transforma a senha do usurio em um objeto de 16 bytes;
Login(): verifica se o usurio cadastrou uma senha para acessar o

sistema, e responsvel por permitir o acesso interface visual;
Verifica_Base(): faz a verificao e criao das pastas e arquivos de

dados necessrios para o funcionamento do sistema;
Atualizar_Lista_Pares(): realiza atualizao da lista de pares

conectados rede;
Carregar_Base(): carrega os arquivos de configurao referente aos

arquivos e dados do usurio;
Buscar_Meus_Arquivos(): inicia um servio de busca por arquivos nos

outros pares da rede;
Main(): mtodo de inicializao da aplicao.
56
Ao iniciar a Interface, so enviadas requisies para a classe

JXTA_Service, que implementa os servios de rede e inicia os servios da
tecnologia JXTA. Aps o usurio conectar-se ao sistema utilizando sua chave
secreta, a interface grfica do sistema exibida e so executados os processos
necessrios para o incio da rede, autenticao de usurios e comunicao entre os
pares.
Os mtodos e atributos da classe JXTA_Service so mostrados na Tabela
3.
Tabela 2 - Classe JXTA_Service
Classe: JXTA_Service
Contm as funcionalidades de iniciar e controlar a rede P2P.
Atributos:
GrupoGlobal: instncia de PeerGroup, grupo P2P novo reservado a iniciar

a rede;
Grupo_Backup: instncia PeerGroup referente ao grupo P2P reservado

para usurios que utilizam a aplicao;
DS_Padro: instncia de servio padro de descoberta de redes e dados

utilizado para buscar servios de rede disponveis;
DS_Backup: instncia de DescoveryService responsvel por servio da

rede backup, responsvel pela descoberta de servios da rede backup;
PGA_Backup: instncia de PeerGroupAdvertisement, responsvel pelos

anncios no grupo JXTA da rede;
Grupo_Backup_ID: identificao JXTA da rede;
Auth: credenciais de autenticao do usurio na rede;
Mtodos:
Comecar(): responsvel por executar os mtodos de criao, busca e

autenticao de grupo;
Iniciar_Rede(): inicia a rede P2P;
Forcar_Iniciar_Grupo(): faz requisio de criao de grupo e insere o

par no grupo criado;
57
Pesquisar_Grupo_Existente(): responsvel por encontrar grupos

existentes na rede P2P;
Ingressar_Grupo(): inclui um par no grupo backup;
Log(): adiciona registros de eventos ao log do usurio;
Criar_Novo_Grupo(): cria novo grupo na rede P2P;
getGrupo(): retorna a instncia do grupo backup.
Os mtodos e atributos apresentados na Tabela 3 so essenciais para o

funcionamento da rede P2P, sendo que as aes de controle da rede so
executadas a partir da classe JXTA_Service.
Alm das classes descritas, o sistema composto por outras classes:
Peer: contm informaes sobre o par ativo na aplicao, como senha, nome
e identificao;
Download: responsvel por buscar e recuperar arquivos requisitados pelo

sistema ou pelo usurio. Possu 3 mtodos para informar o status do
download;
Download_Thread: executa download de arquivos sem que seja necessrio

que a aplicao aguarde o seu trmino;
Share: cria e anuncia servios de compartilhamento e lista de arquivos na

rede;
Peer_Thread: executa servio de busca de pares e adiciona lista da

interface do sistema;
Arquivo: utilizada para representar qualquer tipo de arquivo;
Arquivo_Buscar_Thread: responsvel por iniciar servios de busca de

arquivos na rede. Recupera lista de arquivos do usurio e realiza a
proliferao dos arquivos na rede;
ListRequestor: busca por anncios de arquivos disponveis e recupera o

arquivo para a mquina local. Possui relacionamento somente com a classe
Arquivo_Buscar_Thread.
As classes identificadas com a terminao thread, so servios executados
pela aplicao, que no param ou bloqueiam a aplicao para executar uma tarefa.
58
Isto , esta abordagem permite a execuo de diversas tarefas em paralelo e, alm

disso, deixar a interface do usurio livre para uso.
A aplicao em geral, considerando at a tecnologia JXTA, geram arquivos de
configurao e dados do usurio. Estes arquivos e dados criados so mostrados na
seo seguinte.
4.3
Modelo de dados
A aplicao no usa um SGBD para armazenar os dados do usurio. Para a tarefa

de armazenamento foram utilizados arquivos no formato XML, que contm
informaes de arquivos enviados, senhas e configuraes. Quando uma rede
iniciada o JXTA cria arquivos que so metadados utilizados pela tecnologia referente
a configuraes de usurio e grupos P2P. Estes dados so configuraes de rede,
anncios espalhados pela rede, grupos criados etc.. A aplicao utiliza diretamente
apenas o arquivo que possui as definies do usurio, as demais so utilizadas
exclusivamente pela tecnologia. Para armazenar os dados criada uma pasta
denominada .jxta na raiz na qual a aplicao se encontra.
A pasta .jxta, armazena arquivos referentes a configurao do par e
metadados com informaes do grupo que o usurio ingressou, anncios de
arquivos disponveis, informaes de outros pares etc. A Figura 22 mostra os objetos
presentes na pasta .jxta.
Figura 22 - Pasta .jxta
A Figura 22 mostra o contedo pasta .jxta, criada pelo JXTA: a pasta cm e

um arquivo sem extenso de nome PlatformConfig. A pasta cm armazena os
metadados, sendo que o contedo dos arquivos dessa pasta no pode ser lido, pois
so os arquivos so criptografados pelo prprio JXTA.
59
O contedo de PlatformConfig uma estrutura XML, que contm

informaes do usurio como identificao, nome, chave de segurana, alm de
configuraes da plataforma, como endereo JXTA de servios de rede, protocolos
etc. A Listagem 1 mostra parte do contedo do arquivo PlatformConfig.
Listagem 1 - Arquivo PlatformConfig
A Listagem 1 mostra o trecho do arquivo PlatformConfig, que consiste em

uma estrutura XML contendo informaes como:
linha 4 elemento PID, que contm o endereo JXTA do par;
linha 7 elemento Name, que representa o nome do par que utilizado pela
aplicao para localizar arquivos e identificar o usurio na rede; e
linha 11 elemento Desc, que contm a descrio da configurao.
Alm das informaes mostradas na Listagem 1, o arquivo ainda possui outros

dados:
Endereo JXTA dos servios fornecidos pelo par;
Informaes sobre os protocolos de transporte usado (TCP, HTTP);
Configuraes do protocolo de propagao dos anncios; e
Chave privada do usurio.

Os dados do arquivo PlatformConfig so necessrios para o funcionamento
da rede JXTA e so gerados pela prpria tecnologia. Alm dos arquivos gerados
pelo JXTA, so criados arquivos pela aplicao, que so o banco de dados da
aplicao e diretrios de compartilhamento e download de arquivos. A Figura 23
mostra as pastas criadas pela aplicao.
60
Figura 23 - Pastas Peer Backup
As pastas Config, Downloads e Share, mostradas na Figura 23, so

criadas pela aplicao na sua primeira utilizao. A pasta Downloads contm os
arquivos recuperados de outros pares. A pasta Share contm os arquivos
criptografados do usurio e de outros pares da rede e compartilhada pelo sistema
para download e upload de arquivos de outros pares. A pasta Config possui a base
de dados do sistema, que contm informaes sobre o par e arquivos enviados.
A Figura 24 mostra os arquivos criados na pasta Config.
Figura 24 - Pasta Config
Na pasta Config so criados dois arquivos: Base.xml e Profile.ini. O

arquivo Profile.ini possui apenas o nome do par criptografado com a chave do
usurio, e usado para autenticao da senha do usurio na aplicao. O arquivo
Base.xml contm informaes dos arquivos enviados pelo par, informaes de data
de envio, nome do arquivo etc como mostrado na Figura 25.
61
Figura 25 - Arquivo "Base.xml"
O arquivo Base.xml contm apenas os dados referentes ao arquivo para

informar ao usurio os arquivos j enviados por ele na rede. Na linha 3 mostrado a
abertura de uma chave arquivo com o atributo id, que representa o nome do
arquivo cifrado, nome, sendo o nome original do arquivo, tamanho que a
quantidade de bytes do arquivo e data_envio, que quando o arquivo foi enviado
rede.
4.4
Cenrios de Uso
Ao ser utilizada a aplicao pode apresentar diversos comportamentos, que se

diferem de acordo com cada ao executada pelo usurio. Esses comportamentos
so representados por cenrios possveis relacionados manipulao de arquivos
na rede, sendo eles:
Primeiro acesso: apresenta os passos executados pelo sistema na

primeira utilizao, na qual o usurio realiza um backup de arquivos na
rede;
Recuperando lista de arquivos: mostra os passos necessrios para

retornar a lista de arquivos enviados e armazenados em outros pares;
Recuperar um arquivo: processo de download de um arquivo do usurio.
O primeiro cenrio de um usurio seu primeiro acesso aplicao, que vai

desde a configurao ao envio de arquivos na rede. Este cenrio mostrado na
Figura 26.
62
Figura 26 - Primeiro acesso
Na Figura 26 apresentado o funcionamento da aplicao quando o usurio

acessa pela primeira vez, sendo que os passos foram numerados de acordo com a
ordem que a ao executada:
Passo 1 - configurao de nome de usurio e senha, que so necessrios

para cifrar e restaurar os arquivos. Ao realizar a configurao, o sistema
registra o usurio na rede, caso esta esteja ativa, seno cria a rede.
Passo 2 o sistema realiza uma busca por redes P2P ativas; se nenhuma for
encontrada, ento uma criada;
Passo 3 - envio de arquivos do usurio para a rede. Para realizar o envio de

arquivos necessrio que tenha pelo menos dois usurios na rede, caso
haja, o usurio envia o arquivo, que cifrado com a senha do usurio antes
de ser enviado aos pares disponveis. O arquivo cifrado utilizando com a
chave do usurio utilizando a tecnologia AES, sendo que apenas o
proprietrio do objeto precisar conhecer a chave.
O usurio precisa configurar o sistema apenas uma vez em cada mquina que
utilizar, pois criada uma base de dados contendo seu nome de usurio e seus
arquivos enviados. A base de dados, que fica armazenada em arquivo no formato
XML no diretrio Config que se encontra junto com a aplicao, acessada
63
quando o usurio precisa saber quais arquivos foram guardados. O arquivo possui a
identificao dos arquivos enviados, nome, tamanho, data de envio etc.. Aps o
envio dos arquivos, o usurio pode recuper-lo de qualquer outro par da rede,
necessitando configurar apenas o login e senha novamente.
Na Figura 27 mostrado o cenrio de uso que representa o processo de
recuperao de arquivos.
Figura 27 - Recuperando lista de arquivos
Na Figura 27 mostrada a sequncia dos procedimentos necessrios para

que um usurio consiga recuperar seus arquivos enviados que so:
Passo 1 - realizada a configurao do sistema, de forma que o usurio

dever fornecer seu usurio e senha, que devem ser as mesmas do primeiro
envio de arquivos.
Passo 2 - a aplicao envia uma requisio de busca por arquivos na rede;
Passo 3 os pares conectados na rede fornecem uma resposta com os

arquivos disponveis do usurio;
Passo 4 retornada a resposta da consulta, que a lista de arquivos

disponveis do usurio, a lista ainda pode retornar vazia caso no seja
encontrado arquivos ou no exista pares disponveis.
64
Os arquivos so recuperados quando o usurio faz um requisio no sistema,

que realiza a busca pelos arquivos disponveis na rede e retorna a lista para a
interface do usurio.
A Figura 28 mostra o cenrio que representa o processo para realizar
download de arquivos.
Figura 28 - Recuperar um arquivo
Para realizar o download de um arquivo, o usurio precisa recuperar a lista

que contm os arquivos disponveis. Na lista o usurio pode escolher o arquivo
desejado para recuperar, na Figura 28 so mostrados os passos executados ao
realizar um download:
Passo 1 - realizada uma busca para verificar se o arquivo continua

disponvel;
Passo 2 o arquivo solicitado enviado ao par que fez a requisio. O

arquivo enviado chega ao par criptografado;
Passo 3 processo de decifrar o arquivo e a chave utilizada a senha que o

usurio configurou na aplicao. Feito o processo de decifrar o arquivo, ento
exibido para o par que solicitou.
Os cenrios de uso apresentados foram baseados nas possveis aes

descritas nos casos de uso, e foram utilizados como base para o desenvolvimento
65
da aplicao e o roteiro de execuo dos cdigos de implementao, que so

detalhados na prxima seo.
4.5
Implementao da aplicao Peer Backup
Nesta seo so apresentadas partes relevantes do cdigo e as telas da aplicao

desenvolvida. Durante o desenvolvimento da aplicao foi determinada uma
sequncia de aes, que demostrada na seguinte ordem:
Inicializao da aplicao:
o Verificao de dados (banco de dados e pastas);
o Criao e autenticao da rede;
o Conexo do usurio com o sistema;
Interface grfica:
o Acesso tela inicial;
o Envio de arquivos;
o Recuperao de arquivos
o Verificao de pares conectados;
o Acesso aos Logs de eventos.
A sequncia descrita representa o comportamento do sistema desde o incio

da execuo at a apresentao da parte grfica para o usurio, e so apresentadas
nas sees seguintes.
Iniciando aplicao
A fase de inicializao da aplicao funciona como um modelo de dependncias, na
qual uma ao s pode ser executada se a anterior tiver sido iniciada ou
completada. A Figura 29 mostra a sequncia de aes referentes inicializao da
aplicao.
66
Figura 29 - Sequncia de eventos na inicializao do Peer Backup
Na Figura 29 mostrada a sequncia de aes que o sistema executa para

mostrar a interface ao usurio, no qual Iniciando aplicao representa uma ao do
usurio, os quadrados de cor azul representa aes do sistema, os objetos de cor
vermelha representam condicionais no sistema, as excees so erros ocorridos
durante os processos e finalizam a aplicao, por fim a cor verde, que representa
telas do sistema.
Na inicializao do sistema qualquer erro gerado por algum dos mtodos
aborta a aplicao, isto porque as prximas requisies precisam do resultado
positivo gerado na anterior, como mostrado na Figura 29, nos itens verifica base e
pastas, criao e autenticao da rede e conexo do usurio com o sistema. A
primeira etapa da inicializao verificar a base de dados e as pastas necessrias
para o funcionamento da aplicao, pois informaes sobre o usurio como login,
chave de segurana, arquivos enviados esto presentes nesses arquivos e so
utilizados nos prximos mtodos, alm das pastas de arquivos recuperados e a
pasta em que os outros pares guardam suas cpias.
Todos os comandos P2P na rede so enviados para os servios iniciados na
etapa de criao e autenticao da rede. Nesta etapa, os pares so anunciados para
67
os demais, fornecendo seu endereo JXTA. Erros de localizao da rede e de

autenticao podem acontecer.
A conexo do usurio com o sistema a ltima etapa em que pode ocorrer
um erro que gere uma exceo e pare o sistema. Esta fase consiste, basicamente,
na conexo do usurio ao sistema, utilizando sua chave secreta. Um erro comum
nessa etapa digitao de chave invlida ou errada pelo usurio, o que impossibilita
que a aplicao continue sua execuo.
Verificao de dados
A verificao da base de dados e das pastas do sistema so necessrias, pois as
pastas Config, Downloads e Share so locais em que so armazenados os
arquivos dos usurios e as configuraes da aplicao. O arquivo Base.xml
tambm necessrio, pois, informaes sobre os arquivos enviados so gravadas
nele. A Figura 30 mostra a sequncia da criao dos dados.
Figura 30 - Fluxo verificar base e pastas
Na Figura 30 mostrada a sequncia de criao das pastas e da base, a

necessidade de cada um dos itens so detalhados na seo 4.2, no qual os objetos
de cor verde claro representam as pastas e arquivos a serem criados. Antes da
68
criao das pastas feita a verificao de sua existncia, pois, se existir no

necessrio criar. As pastas e arquivos so verificados e criados nessa ordem:
Config, Base.xml, Downloads e Share. Aps concluir a criao das pastas, o
sistema carrega o arquivo Base.xml para a memria e continua a execuo, que
a criao da rede.
Criao e autenticao da rede

O processo de criao da rede executado pela aplicao, mesmo que exista
alguma rede j ativa. Isto ocorre porque preciso iniciar os servios de busca de
uma rede genrica. A Figura 31 mostra os eventos executados para inicializao da
rede.
Figura 31 - Criao da rede P2P
Todo o processo de inicializao e autenticao da rede P2P, mostrado na

Figura 31, feito de forma transparente ao usurio. Na qual iniciada uma rede,
contendo os servios de uma rede P2P. Os servios de busca so utilizados para
encontrar um servio de rede existente. Como mostrado na Figura 31, existem
69
duas possibilidades quando se verifica a existncia de uma rede P2P, a rede estar
ativa ou a rede no existir.
Quando a rede encontrada, o sistema cria uma cpia do objeto de
referncia da rede, que inclui localizao, nome de grupos, pares ingressos e
anncios transmitidos. Caso o par servidor se desconecte, o objeto copiado
utilizado para iniciar uma nova rede contendo os pares existentes. Por fim o sistema
autentica o usurio na rede e realiza o procedimento para incluir o par no grupo e
anunci-lo para os outros pares.
Ao buscar e no encontrar um servio de rede disponvel, o prprio par
eleito como servidor. Para isso, necessrio somente autenticar o usurio na rede,
proceder com o ingresso do par no grupo criado e aguardar que novos pares se
conectem.
Para encontrar redes disponveis a aplicao utiliza o nome definido para a
rede P2P. Para a aplicao Peer Backup, foi definido o nome PeerBackup para
qualquer rede criada a partir dela, sendo que sistema busca por esta referncia. A
Listagem 2 mostra o trecho de cdigo que implementa as buscas por redes P2P.
Listagem 2 - Mtodo de busca por rede P2P
No mtodo Pesquisar_Grupo_Existente() da classe JXTA_Service,

que mostrado na Listagem 2, realizada a busca por redes P2P que possuam o
70
atributo Name igual a PeerBackup. Este processo executado cinco vezes e

aguarda dez segundos para cada nova busca.
linha 79 - criada uma varivel para armazenar uma coleo de objetos;
linha 80 - adicionadas informaes ao log de eventos;
linha 83 - utilizado o mtodo getLocalAdvertisements() da classe

DiscoveryService do JXTA, que retorna todos os elementos referentes a
grupos encontrados na busca na rede. Os argumentos informados ao mtodo
so, respectivamente, o tipo da busca (no caso, grupo), o atributo a ser
pesquisado e o que deve conter no atributo. Esse mtodo realiza a busca
utilizando os endereos JXTA contido nos metadados guardados na mquina
do usurio referente anncios de redes encontradas em outro momento;
Na linha 85 - verificada a existncia de algum elemento, quando encontrado

so executadas as linhas 86 e 87;
linha 86 - realiza uma cpia do objeto que responsvel pelos servios de

anncios JXTA;
linha 87 - efetuada uma cpia do objeto da rede;
linha 88 - inclui o par na rede;
linha 91 - caso no encontre nenhuma rede P2P utilizando o cache, ento

feita a busca por inundao, enviando anncios para todos os pares
disponveis na rede. O mtodo utilizado para propagar a requisio o
getRemoteAdvertisements(),
que
recebe
como
atributos
respectivamente o par especifico a buscar, no caso null, pois para todos,

tipo de anncio, atributo a ser buscado, o valor do atributo, e a quantidade de
respostas esperadas; e
linha 93 a aplicao executa esse processo de busca em cache e por

inundao, cinco vezes com um intervalo de 10 segundos;
Como mostrado na Figura 31 uma rede criada antes mesmo da busca por
outras existente, sendo utilizado apenas os servios de localizao. Quando no
encontra uma rede ativa, automaticamente criado um grupo P2P, no qual o usurio
conectado. Esse grupo anunciado como uma rede P2P para que novos pares
consigam conectar. O cdigo utilizado para criar o grupo mostrado na Listagem 3.
71
Listagem 3 - Cdigo criar novo grupo
O cdigo mostrado na Listagem 3 executado quando a aplicao cria um

novo grupo, isto ocorre quando no encontrado um grupo ativo. O cdigo executa
conforme a seguinte sequncia:
linha 154 - criado um objeto de ModuleImplAdvertisement, uma classe

do JXTA responsvel pelos servios de anncios. A varivel Anuncio recebe
como valor os servios de anncios referentes grupos, isso por meio do
mtodo getAllPurposePeerGroupImplAdvertisement();
Linha 154 - varivel GrupoGlobal referente ao grupo criado no momento

que a aplicao foi iniciada, e foi utilizada apenas para descobrir redes
disponveis e implementar os servios P2P;
linha 155 - criada uma varivel para identificao do grupo, no qual

gerado um endereo URN (Nome uniforme de recurso), que o identificados
utilizado para localizar o grupo na rede;
linha 157 - criado um novo grupo criado que recebe como parmetros no
construtor do mtodo a identificao do grupo, os servios disponveis de
grupo, o nome do grupo e a descrio. Aps a criao do grupo criado um
anncio para public-lo na rede;
linha 159 criado um anncio para publicar o par, na qual a varivel

PGA_Backup que do tipo PeerGroupAdvertisement, classe responsvel
por criar anncios de grupo. A varivel recebe o anuncio referente ao grupo
que foi criado;
linha 160 e 161 par publicado em cache e na rede utilizando o mtodo

publish da classe DiscoveryService.
72
O grupo criado fica disponvel na rede para novos pares se conectarem e

enviarem seus arquivos para backup.
Conexo do usurio com o sistema
Antes de obter acesso a interface grfica o usurio precisa cadastrar uma senha
para criptografia dos arquivos ou fazer login caso j tenha cadastrado. A Figura 32
mostra o processo executado para o usurio obter acesso interface da aplicao.
Figura 32 - Etapas de acesso aplicao
As etapas do processo de login mostrado na Figura 32 so necessrias para

que o usurio tenha acesso interface grfica da aplicao. Na primeira etapa
verificada a existncia da base de dados com as informaes do usurio. Essa base
consiste na pasta .jxta e no arquivo Profile.ini que criado na pasta Config.
Interface do sistema
A interface responsvel por receber interaes do usurio para realizar aes na
aplicao. Sendo que as informaes exibidas ao usurio so buscadas na base de
73
dados existente, que so dados referentes a nome do usurio, arquivos etc. Quando
no encontra a base o sistema exibe primeiramente a tela do JXTA para cadastro de
usurio e senha, que mostrada na Figura 33.
Figura 33 - JXTA Configurator
A Figura 33 mostra a tela referente ao JXTA Configurator, que uma

interface de configurao fornecida pelo JXTA, no qual aberto automaticamente
quando o usurio no realizou a configurao da tecnologia. O campo Peer Name
o nome que o usurio deseja utilizar na rede, sendo considerado como seu login e
deve ser utilizado sempre o mesmo, pois quando feita a recuperao de arquivos,
o sistema usa como referncia o nome do usurio. O campo Password deve ser
74
preenchido por uma senha do usurio de 8 ou mais caracteres, e o campo Verify

Password apenas a confirmao da senha.
Os botes mostrados no topo da Figura 33 so configuraes adicionais do
JXTA, que deve ser modificada por um usurio com experincia na tecnologia ou
pelo desenvolvedor da aplicao, caso seja necessria a utilizao de outras
configuraes diferentes da padro. As configuraes que podem ser alteradas so:
Log;
Proxy;
Protocolo TCP;
Protocolo HTTP.
Aps realizar a configurao utilizando o JXTA Configurator, automaticamente

aberta uma janela para a configurao da senha de criptografia que pode ser igual
a digitada na configurao do JXTA. A chave de criptografia utilizada para
conectar-se no sistema e cifrar/decifrar os arquivos do usurio. Aps digitar os dados
criada a pasta .jxta com os metadados do JXTA e o arquivo Profile.ini que
possui o nome do usurio digitado no JXTA Configurator criptografado com a chave
de criptografia.
Aps feita a criao da base mostrada a tela de login, que o usurio deve
digitar a chave de criptografia para acessar o sistema. Para verificar a autenticidade
da chave, feita a decifragem do arquivo Profile.ini. A Figura 34 mostra o processo
de verificao da chave.
75
Figura 34 - Verificao de chave
A verificao feita no login utilizando a chave simtrica como mostra a

Figura 34. Quando o usurio digita a chave, feita a tentativa de decifragem do
arquivo Profile.ini, que contm criptografado o nome de login definido no JXTA
Configurator. Caso seja possvel a descriptografia utilizando a chave fornecida pelo
usurio, ento feita a verificao apenas para conferir se a base existente do JXTA
referente a base de dados da aplicao. Ento verificado o nome de usurio
JXTA e o da base, caso seja igual mostrada a interface grfica. Quando a chave
invlida ou os dados encontrados na base da aplicao so diferente do JXTA ento
a aplicao encerrada. Um usurio pode se passar por outro, pois a verificao
apenas para verificao local, mas no conseguir recuperar os arquivos sem a
chave de descriptografia.
Aps esta etapa, ento, exibida ao usurio a tela da aplicao, que possui
as funcionalidades de backup como envio, busca e recuperao de arquivos. Alm
da tela de progresso de download, lista de arquivos enviados, logs etc. A tela inicial
da aplicao mostra a lista dos arquivos enviados pelo usurio, caso no tenha
enviado nenhum, a lista fica em branco, como mostrado na Figura 35.
76
Figura 35 - Interface grfica Peer Backup
As telas da aplicao so acessadas por meio das abas disponveis na

interface, como mostrado na Figura 35. A aba Buscar Arquivos disponibiliza uma
lista de arquivos disponveis que podem ser recuperados. Para fazer o envio de
arquivos o usurio deve acessar Enviar Arquivos. Em Downloads mostrado o
status dos arquivos que esto sendo recuperados. Em Peers Conectados o usurio
da aplicao pode verificar quais pares esto disponveis e conectados na rede. As
requisies feitas pelo sistema e erros so mostrados em Logs.
Envio de arquivos
Os arquivos do usurio so enviados para os outros pares por meio da aba Enviar
Arquivos e so criptografados com a chave do usurio utilizando a tecnologia de
criptografia AES, antes de serem compartilhados na rede. A cifragem do arquivo a
forma de garantir a confidencialidade da informao, na Listagem 4 mostra o cdigo
que cifra os arquivos.
Listagem 4 - Cdigo de cifragem AES
77
O trecho de cdigo mostrado na Listagem 4 uma parte do mtodo

Criptografar() da classe Arquivo, que responsvel por todas as
manipulaes de arquivo como criptografia, clculo de hash, etc. O cdigo segue
uma sequncia de execuo:
linha 197 - criada uma instncia OutputStream, objeto utilizado para auxiliar
na escrita dos bytes, que recebe como parmetro o arquivo que ser
criptografado.
linha 199 - a chave do usurio transformada em bytes, para ser usada na

construo da chave secreta de criptografia do tipo AES, na linha 200.
linha 201 a cifragem do arquivo feita utilizando a biblioteca crypto nativa

do Java, a classe Cipher faz parte dela, recebendo como parmetro o tipo
de criptografia, no caso AES.
linha 203 - o mtodo init da classe Cipher inicia o cifrador e configura o

modo de operao, recebendo como parmetro a operao, no caso
criptografar, e a chave transformada em bytes.
linha 204 - a varivel CIS, do tipo CipherInputStream, criada para ler os

bytes antes que seja criptografado, para garantir que o contedo pode ser lido
antes de ser escrito.
linhas 209 a 211 feita a leitura dos dados a cada 64 bytes, que depois so
escrito em arquivo fsico e colocado na pasta Share.
Alm da cifragem do contedo dos arquivos, tambm feita a codificao no

nome dos arquivos antes de envi-los para a rede. O nome do arquivo segue um
prefixo estabelecido na aplicao antes de ser codificado, que :
NOMEDOUSUARIO__DIA-MS-ANOHORAMINUTO__NOMEDOARQUIVO;
Exemplo: TARIK__13-06-2013-1510__FOTOS.ZIP.
Aps o nome ser modificado de acordo com o prefixo, o mesmo codificado

utilizando o algoritmo base64, cuja codificao reversvel. Dessa forma a aplicao
faz uma busca utilizando apenas o nome do usurio, quando preciso recuperar os
arquivos enviados.
78
Recuperao de arquivos
Quando um usurio da aplicao deseja recuperar um arquivo necessrio utilizar a
aba Buscar Arquivo. No momento que for feita a requisio, a aplicao faz uma
requisio classe Arquivo_Buscar_Thread, que o servio responsvel por
iniciar uma instncia da classe ListRequestor, como mostrado na Listagem 5.
Listagem 5 - Mtodo run() da thread Arquivo_Buscar_Thread
Quando a thread Arquivo_Buscar_Thread, mostrado na Listagem 5 iniciada, uma

verificao realizada com intuito de distinguir as requisies, isto , verificar se a
requisio foi feita pelo usurio, no caso busca por arquivos, ou pela aplicao,
arquivos de outros pares compartilhados na rede como mostrado na sequncia:
linha 44 - iniciada a verificao da requisio, caso seja uma requisio do

usurio (opcao == 0), ento a condio verdadeira e a aplicao executa as
linhas seguintes 45-61. A varivel opo importante para a aplicao, pois
define se a consulta deve retornar um resultado para o usurio (lista de
arquivos encontrados) ou se uma requisio do sistema com objetivo de
efetuar download de arquivos compartilhados na rede;
79
linha 46 - gravado na varivel Tempo_Inicio_Thread o valor da hora no

momento que o sistema executou a linha, para controlar o tempo de execuo
da thread. Para recuperar um arquivo utilizada a classe ListRequestor;
linha 51 - Na varivel List_Requestor, que passado como parmetro o

grupo peer-to-peer ativo, o nome do arquivo (Query_Buscar), a tabela que
exibe os resultados (JTable), o valor correspondente a opo para definir de
quem veio a requisio (no caso do usurio, 0) e a lista de arquivos em que
os resultados so salvos.
classe
ListRequestor
herda
as
caractersticas
da
classe
CachedListContentRequest do JXTA, que responsvel por buscas. Para que

se adeque s necessidades do sistema foi modificado o mtodo que informa os
resultados obtidos pela busca, o notifyMoreResults(). A Figura 36 mostra o
funcionamento do mtodo.
Figura 36 - Mtodo notifyMoreResults()
O mtodo mostrado na Figura 36 implementado pelo JXTA e sobrescrito

pela aplicao, sendo responsvel por notificar resultados de buscas. Quando
executado, o mtodo verifica se a requisio est sendo feita por um usurio ou pelo
sistema. Caso seja uma requisio do prprio sistema, ento feita a busca por
todos os arquivos de todos os usurios, e quando encontra realiza o download
automaticamente com intuito de propagar as cpias pela rede. Quando a busca
feita por usurio, ento realizada uma busca pelos arquivos enviados pelo usurio
80
que por fim retorna a lista de arquivos encontrados disponveis para download na
aba Buscar Arquivos da interface, como mostrado na Figura 37.
Figura 37 - Aba Buscar Arquivos
Na aba Buscar Arquivos mostrada na Figura 37, o local no qual os

usurios da aplicao podem recuperar seus arquivos enviados. Ao utilizar o boto
Buscar meus arquivos o sistema busca por dois minutos anncios de arquivos que
contenham no nome o prefixo referente ao nome do usurio, aps o trmino do
tempo exibido os resultados encontrados. Isto , ao realizar a requisio para a
classe
ListRequestor,
no
atributo
Query_Buscar
passado
valor
NOMEDOPAR*, sendo que qualquer valor que possua o nome do par no incio do
arquivo considerado dele. A query de busca feita deste modo porque os arquivos
so renomeados antes de serem compartilhados com intuito de facilitar no momento
da busca.
Aps o retorno da lista de arquivos, o usurio pode escolher e recuperar um
arquivo, utilizando o boto Download da tela. A requisio de download inicia um
servio da classe Download_Thread, que responsvel por invocar os mtodos da
classe Download, tendo como objetivo de recuperar o arquivo.
A classe Download herda os mtodos da classe GetContentRequest do
JXTA, que responsvel pelo download de arquivos presentes na rede. A classe
Download recebe como parmetro no construtor: o grupo ativo, o anncio de
contedo, o local que o arquivo deve ser salvo na mquina e o objeto que deve ser
manipulado para exibir informaes de status do download. Para informar sobre a
situao do download, existem trs mtodos que so sobrescritos da classe
superior, que so:
81
notifyUpdate(): exibe informaes de progresso em tempo real do

arquivo que est sendo recuperado;
notifyDone(): informa quando o download foi concludo;
notifyFailure(): utilizado para informar falha no download de

contedo.
Os mtodos descritos trabalham diretamente com a aba Download da

interface da aplicao, para informar o usurio do progresso do download. O usurio
tambm pode cancelar um download em progresso, na Figura 38 mostra a aba
Downloads.
Figura 38 - Aba "Download"
Ao realizar uma requisio de download, automaticamente o progresso

exibido na aba Download, como mostrado na Figura 38. Por meio da interface, o
usurio pode cancelar uma requisio em andamento ou abrir o arquivo quanto o
processo estiver concludo.
No momento que concludo o processo de
recuperao feita a decifragem do arquivo utilizando a chave do usurio, caso seja

diferente o sistema retorna uma mensagem de erro e o arquivo no pode ser aberto.
Verificao de pares conectados
Por meio da interface grfica o usurio pode verificar se existem pares conectados
rede, e ainda quais so eles utilizando a aba Peers Conectados. O JXTA fornece
os mtodos necessrios para buscar por anncios de pares e verificar se ainda so
vlidos. Este procedimento feito pela classe Peer_Thread, que herda e
sobrescreve o mtodo de descoberta da classe DiscoveryListener, como
mostrado na Listagem 6.
82
Listagem 6 - Mtodo discoveryEvent classe Peer_Thread
O mtodo discoveryEvent, mostrado na Listagem 6, responsvel por

fazer a descoberta de pares ativos na rede e retornar os resultados. A execuo do
cdigo segue desta forma:
linha 55 - inicializada a varivel Response, que uma instncia de

DiscoveryResponseMsg, responsvel por obter respostas de anncios de
pares na rede. A resposta enviada pelos pares so status, localizao na
rede, etc.;
linha 56 - as respostas so numa varivel do tipo Enumeration, que ordena

o conjunto de itens e remove dados repetidos;
linha 57 mostrada na interface do usurio os pares disponveis.
Na interface do usurio mostrada a lista dos pares encontrados pela

aplicao, como mostrado na Figura 39.
Figura 39 - Aba Peers Conectados
Quando um usurio faz uma requisio para atualizar a lista de pares

conectados, utilizando o boto Atualizar Lista mostrado na Figura 39, a aplicao
executa uma instncia de Peer_Thread que faz a buscar de pares por dois minutos
e atualiza a lista caso tenha pares conectados. Caso ocorra algum erro durante o
processo, adicionado ao log do sistema.
83
Acesso ao log de eventos

Os logs de eventos da aplicao serve para informar ao usurio erros ocorridos e
informativos sobre servios executados. A lista de ocorrncias fica disponvel para o
usurio na aba Logs da aplicao, como mostrado na Figura 40.
Figura 40 - Aba Logs
O registro de eventos mostrado na Figura 40, uma forma de deixar o

usurio informado de problemas ocorridos no sistema, requisies feitas por ele,
etc.. Caso o usurio deseje, possvel limpar os logs mostrados.
As funcionalidades desenvolvidas podem apresentar excees no previstas,
e que podem impedir seu funcionamento correto, desta forma preciso validar sua
utilizao. Desta forma foram efetuados testes de interface, rede, funcionalidades e
tambm de autenticidade, e so detalhados na prxima seo.
4.6
Testes realizados sobre a aplicao
Segundo Tomelin (2000, p.4), atividade de teste o processo de executar um

programa com a inteno de descobrir um erro. Alm de descobrir erros, testes de
software so realizados para a validao das funcionalidades de uma aplicao, isto
, verificar se os requisitos propostos so atendidos.
Para a realizao dos testes, foi utilizado um ambiente virtual com trs
mquinas, com o sistema operacional Windows XP, criado pelo aplicativo VMWare.
As configuraes de hardware so indiferentes, necessitando apenas a instalao
do Java verso 7.
Para verificar o funcionamento da aplicao Peer Backup, foram criados trs
usurios fictcios. Alm disso, foi seguido um roteiro para cada teste, que consiste
em:
84
Testes de interface e mtodos: verificar as funcionalidades propostas no

projeto.
o Inicializao da aplicao e rede;
o Envio de arquivo;
o Busca por pares;
o Busca e recuperao de arquivos.
Teste de confidencialidade dos arquivos enviados: verificar se os arquivos

enviados podem ser lidos somente pelo dono que possui a chave de
criptografia.
Os testes foram feitos de forma manual, simulando as aes que seriam

realizadas por usurios comuns.
Teste de Interface
O teste de interface foi iniciado com a execuo da aplicao, e foi utilizado um
usurio denominado Lord para simular um usurio real. Para o usurio foram
definidos seu login, senha e os arquivos a serem enviados, como mostrado na
Tabela 3.
Tabela 3 - Atributos par Lord
Login/Nome do Par
Lord
Senha/Chave de criptografia
1234567890
1 arquivo de imagem tipo JPG
Arquivos
1 arquivo compactado tipo ZIP

1 arquivo de texto tipo TXT
Os dados login e senha, exibidos na Tabela 3, foram utilizados na

configurao da aplicao, que feita no JXTA Configurator e na configurao da
chave de criptografia utilizada para o usurio Lord, como mostrado na Tabela 4.
85
Tabela 4 - Definindo usurio e senha da aplicao
Ao
Captura de tela
Definindo Peer Name e

Password do JXTA.
Definindo
chave
de
criptografia e login.
Interface
da
aplicao
aps configurao.
Aps a execuo e a definio de login e senha da aplicao do usurio,

como mostrado na Tabela 3, automaticamente foram criados os arquivos e pastas
necessrios para o funcionamento da aplicao. As pastas criadas foram: .jxta,
Config, Share e Downloads. J os arquivos criados foram: metadados do JXTA,
Base.xml e Profile.ini. A interface grfica do sistema mostrada ao usurio
86
somente quando a rede P2P est ativa e quando os arquivos de dados esto
criados, confirmando ento a funcionalidade da rede.
Para ser possvel criar a rede e realizar os prximos testes, foi necessrio
criar mais dois usurios fictcios para simular um ambiente de rede real. Para cada
usurio foi criada uma mquina virtual e foram definidos usurios e senhas,
mostrados na Tabela 5.
Tabela 5 - Usurios de teste
Login/Nome do Par
Linus
abc112233
Raider
02201001
Os usurios mostrados na Tabela 5 foram criados para que sejam feitos os

testes de compartilhamento de arquivos, que inclui envio, busca e recuperao da
informao.
Envio de arquivo
O usurio Lord enviou os trs arquivos mostrados na Tabela 6 e obteve sucesso.
Sendo que o tamanho dos arquivos no foram alterados pela criptografia.
Tabela 6 - Arquivos enviados pelo usurio Lord
Arquivo
Desktop.zip
Resposta do sistema
Compartilhado
com
sucesso!
IMG_20121208_18
Compartilhado
2054.jpg
sucesso!
concurso.txt
Nome do arquivo gerado
Compartilhado
sucesso!
TG9yZA==#3#2__MTUtNS0yMD
EzLTgzM19EZXNrdG9wLnppcA
==#3#2
com
TG9yZA==#3#2__MTUtNS0yMD
EzLTgzNF9JTUdfMjAxMjEyMDhf
MTgyMDU0LmpwZw==#3#2
com TG9yZA==#3#2__MTUtNS0yMD
EzLTgzMl9jb25jdXJzby50eHQ=#
87
3#2
Os arquivos mostrados na Tabela 7 foram compartilhados e a aplicao que

estava sendo executada nos outros pares armazenou os arquivos para a pasta
Share local. O sucesso no envio dos arquivos foi confirmado por meio da aba
Arquivos Enviados, mostrado na Figura 41.
Figura 41 - Arquivos enviados por Lord
Depois de confirmar o envio dos arquivos por meio, como exibido na Figura
41, foi necessrio verificar se os demais pares da rede realizaram armazenaram os
arquivos do par Lord. Para confirmar foi verificada a pasta Share dos pares Linus e
Raider. Na verificao constatou-se que a pasta Share dos dois ns possua os
trs arquivos gerados mostrados na Tabela 6. Os arquivos so mostrados na Figura
42.
Figura 42 - Arquivos da pasta Share dos pares
88
Os arquivos no possuem extenso e possuem seu nome codificado como

mostrado na Figura 42. Estes arquivos so replicados pelo sistema entre os pares
ativos na rede.
Busca por pares
O prximo passo dos testes foi verificar se existem pares conectados na rede para
que seja feita uma busca dos arquivos enviados. A verificao de pares serve para o
usurio no executar aes sem necessidade, pois se no tem pares conectados,
no tem arquivos disponveis para serem recuperados.
A verificao dos pares da rede foi feita pela interface do usurio Lord, que
retornou uma lista contendo os pares Linus e Raider, que mostrado na Figura 43.
Figura 43 - Peers conectados
A existncia dos pares conectados mostrado na Figura 43, a partir disso foi
feita uma busca pelos arquivos de Lord, utilizando a aba Buscar Arquivos. Ao fazer a
requisio de busca, ento o sistema retornou uma lista com os arquivos
disponveis, que mostrado na Figura 44.
Figura 44 - Lista de arquivos disponveis
89
Os arquivos mostrados na Figura 44 foram recuperados um a um, e foram

guardados na pasta Downloads. Os arquivos foram descriptografados e podem ser
abertos por seus respectivos softwares.
Esta etapa de teste realizada foi executada com o objetivo de testar as
funcionalidades bsicas do sistema, afim de verificar se erros poderiam afetar o seu
funcionamento. Como o objetivo do trabalho garantir que usurios no tenham
acesso aos dados de outro, foi realizado o teste de confidencialidade.
Teste de confidencialidade
O teste tem o objetivo de verificar se um usurio no possa visualizar os dados
enviados por outro, mesmo utilizando seu login. Como a rede no tem controle de
login, ento foi criado uma nova mquina virtual e realizada uma nova configurao
no Peer Backup, que mostrado na Tabela 7.
Tabela 7 - Configuraes de usurio falso
Login/Nome do Par
Lord
00000000
Os dados citados na Tabela 7 foram utilizados na configurao da chave de

criptografia e do JXTA Configurator. No teste o usurio falso conseguiu visualizar a
lista de arquivos enviados pelo usurio verdadeiro, mas no momento que tenta fazer
download no consegue descriptografar o arquivo. Isto ocorre porque a senha de
criptografia diferente da utilizada quando o arquivo foi enviado, na Figura 45
mostra os processos de verificao.
90
Figura 45 - Tentativa de recuperao de usurio falso
Qualquer usurio pode enviar seus arquivos quando conectado rede e

somente o dono pode recupera-lo, como mostrado na Figura 45. O usurio envia um
arquivo para a rede, quando um usurio mal intencionado cria um cadastro com o
mesmo login envia uma requisio de download mas no consegue recuperar a
informao por causa da chave de criptografia.
Os testes foram realizados para verificar o funcionamento da aplicao, e
tambm se o objetivo do projeto foi atendido.
Detalhes relevantes do projeto, dificuldades encontradas so apresentados
na prxima seo.
91
CONSIDERAES FINAIS
A utilizao de dados digitais tem aumentado com o passar dos anos, principalmente
pela expanso da internet. Dentre estes dados esto documentos, fotos, msicas e
outros objetos digitais que um usurio pode possuir no seu computador. Muitas
pessoas, e at empresas, esto se desfazendo das cpias fsicas e substituindo-as
por cpias digitais, visando, entre outras coisas, a economia de espao fsico e a
facilidade de busca.
O foco desse trabalho foi o compartilhamento de espao em disco disponvel
nas mquinas de uma rede de computadores, por meio de uma arquitetura Peer-toPeer descentralizada. Para isso, foi desenvolvida a aplicao Peer Backup, que
possui os mtodos necessrios para envio, busca e recuperao de arquivos em
uma rede P2P. Para acessar as funcionalidades foi implementada uma interface em
que o usurio conseguisse executar as aes de backup.
Para realizar a manipulao da rede P2P foi utilizada a tecnologia JXTA, uma
ferramenta de cdigo aberto e disponvel em vrias linguagens de programao, foi
um dos pontos definidos no objetivo do trabalho, pois fornece os mtodos
necessrios para implementar a rede P2P e realizar a comunicao entre os pares
da rede.
Para verificar se a aplicao oferecia as funcionalidades definidas e no
apresentava problemas na utilizao, foram realizados testes de interface e
funcionamento, isto em um ambiente virtual, devido as dificuldades de se montar um
ambiente real. Foram realizados testes de interface para verificar o funcionamento
da aplicao simulando usurios de uma rede e teste de confidencialidade para
garantir que somente o proprietrio dos arquivos possa recuper-lo. Nos resultados
dos testes foi demostrado o funcionamento real da aplicao e as sadas obtidas
durante sua execuo, que ao final foi comprovado seu funcionamento.
Alm
dos
testes
bsicos
de
funcionamento,
foi
realizado
de
confidencialidade, pois importante garantir que os dados no possam ser lidos

lidos por outros usurios, a no ser o dono. Com os testes, foi possvel concluir que
92
os dados armazenados em outras mquinas so legveis apenas pelo dono,

fornecendo uma segurana e confiana a mais para o usurio.
Uma das dificuldades encontradas no desenvolvimento do trabalho foi na
utilizao do JXTA, sendo que existe uma grande quantidade de material terico,
mas pouco pode ser encontrado quanto implementao. A tecnologia, por sua vez,
consumiu cerca de 90% da memria RAM da mquina que a est executando, o que
dificultou a realizao dos testes, pois havia a necessidade de executar em mdia 3
a 4 instncias da aplicao ao mesmo tempo nas mquinas virtuais. O JXTA
forneceu todos os mtodos necessrios para atender os objetivos do trabalho e
possui outros recursos no explorados, durante sua utilizao, que podem ser
utilizados para outros tipos de aplicao P2P
Este trabalho oferece a possibilidade de continuao e aprimoramento, o que
pode ser realizado em trabalhos futuros:
Verificao de integridade dos arquivos enviados e recuperados utilizando

hash. Umas das formas de implementar compactar o arquivo a ser enviado
junto com seu hash e, no momento da recuperao, realizar um novo clculo
de hash do arquivo recebido e verificar com o que est compactado;
Utilizao de um servidor apenas para autenticao dos usurios, como uma

forma de reforar a segurana na rede com intuito de impedir que usurio mal
intencionados se passem por outros; e por meio desse servidor fornecer
acesso da lista de arquivos enviados somente pelo dono;
A incluso dos trabalhos propostos na aplicao podem aumentar a confiana

dos usurio em questo do uso, pois garantir a integridade dos arquivos, alm da
privacidade dos dados.
93
REFERNCIAS BIBLIOGRFICAS
ANDROUTSELLIS-THEOTOKIS, S., SPINELLIS, D.A Survey of Peer-to-Peer

Content Distribution Technologies.2004.Disponvel
em<http://web.eecs.utk.edu/~itamar/courses/ECE553/Project_Papers/AS04.pdf>.Acesso em 19 novembro 2012.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Sistemas Distribudos
Conceitos e Projetos. 4. Ed. ARTMED EDITORA S.A. 2007.
FARIA, H., M. Bacula -Ferramenta Livre de Backup.2010.
GONG, L. JXTA: A Network Programming Environment. 2001. Disponvel em

<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=935182>. Acesso em
15 novembro 2012.
IBM. IBM DB2 UDB versus Oracle backup andrecovery. 2004. Disponvel em
<http://www.ibm.com/developerworks/data/library/techarticle/dm0407tham/index.html>. Acesso em 15 novembro 2012.
JUNIOR, B., P. GERENCIAMENTO CENTRALIZADO DE BACKUPS
DISTRIBUDOS. 2010. Disponvel em
<http://siaibib01.univali.br/pdf/Braz%20Pereira%20Junior.pdf>. Acesso em 19
novembro 2012.
LIPP, K., J. WHY ARCHIVE IS ARCHIVE, BACKUP IS BACKUP AND BACKUP

AINT ARCHIVE. 1999. Disponvel em <http://adsmsymposium.oucs.ox.ac.uk/1999/papers/kelly-paper.pdf>. Acessoem 16 novembro
2012.
94
LOEST, S. R. UM SISTEMA DE BACKUP COOPERATIVO TOLERANTE A

INTRUSES BASEADO EM REDES P2P. Curitiba: PUC-PR, 2007.67 p.
Dissertao(Mestrado)- Programa de Ps-Graduao em Informtica Aplicada.
LUA, K. CROWCROFT, J., PIAS, M., SHARMA, R., LIM, S.A Survey and
Comparison of Peer-to-Peer Overlay Network Schemes.2004. Disponvel
em<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.6124>. Acesso em
19 novembro 2012.
MAIBAUM, N.; MUNDT, T. JXTA: A Technology Facilitating Mobile Peer-To-Peer

Networks. 2002. Disponvel em
<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1166946>. Acesso
em 15 novembro 2012.
RODRIGUES, R., DRUSCHEL, P. Peer-to-Peer Systems. 2010. Disponvel em

<http://www.cs.princeton.edu/courses/archive/spr11/cos448/web/docs/week11_optio
nal1.pdf>. Acesso em 19 novembro 2012.
SUN MICROSYSTEMS. JXTA v2.0 ProtocolsSpecification. 2007. Disponvel em

<http://jxta.kenai.com/Specifications/JXTAProtocols2_0.pdf>. Acesso em 15
novembro 2012.
SUN MICROSYSTEMS. Project JXTA v2.0: Java ProgrammersGuide. 2003.
Disponvel em <http://pagespersosysteme.lip6.fr/Sebastien.Monnet/PSIA/docs/JxtaProgGuide_v2.pdf>. Acesso em 15
novembro 2012.
SUN MICROSYSTEMS. Project JXTA: A Technology Overview. 2001. Disponvel

em <ftp://jano.ucauca.edu.co/cursos/Memorias/CITA2002/JITTDocumentos/Ubicua2/Fuentes/Papers/TechOverview.pdf>. Acesso em 15 novembro
2012.
SUN MICROSYSTEMS.JXTA Java Standard Edition v2.5: Programmers
Guide.2007.Disponvel em: <http://java.net/projects/jxta-
95
guide/sources/svn/content/trunk/src/guide_v2.5/JXSE_ProgGuide_v2.5.pdf> .Acesso
em 15 novembro 2012.
TANENBAUM, A. S. Sistemas Distribudos Princpios e Paradigmas.2. Ed. So
Paulo: Person. 2007.
TOMELIN, M. TESTES DE SOFTWARE A PARTIR DA FERRAMENTA VISUAL

TEST. 2000. Disponvel em <http://campeche.inf.furb.br/tccs/2001-I/20011marciotomelinvf.pdf>. Acesso em 17 junho 2013.
VITHOFT, M., H. UM SERVIO DE GERENCIAMENTO SEGURO DE

CONTEDOS P2P COMPARTILHADOS EM MANET. Curitiba: PUC-PR, 2009. 117
p. Dissertao(Mestrado)- Programa de Ps-Graduao em Informtica Aplicada.

Desenvolvimento de Uma Ferramenta de Backup Descentralizada Utilizando JXTA

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Desenvolvimento de Uma Ferramenta de Backup Descentralizada Utilizando JXTA

Transféré par

Droits d'auteur :

Formats disponibles

Jan Tarik Martins Nazorek

DESENVOLVIMENTO DE UM SOFTWARE DE BACKUP

Jan Tarik Martins Nazorek

Trabalho de Concluso de Curso (TCC)

bacharel em Sistemas de Informao pelo

Orientador: Prof. Mestre Madianita Bogo

JAN TARIK MARTINS NAZOREK

Trabalho de Concluso de Curso (TCC)

bacharel em Sistemas de Informao pelo

Orientador: Prof. Mestre Madianita Bogo

Aprovada em xxxxxxx de 20XX.

REFERENCIAL TERICO ................................................................................. 13

Aspectos de Projeto ............................................................................... 14

Motivaes e dificuldades ...................................................................... 18

Modelos de Sistemas Distribudos......................................................... 19

Distribuio de contedo utilizando redes P2P...................................... 23

Arquiteturas P2P de Distribuio de Contedo...................................... 24

Arquiteturas Desestruturadas ................................................................ 25

Tecnologia JXTA .......................................................................................... 33

Arquitetura JXTA ................................................................................... 36

Protocolos JXTA .................................................................................... 37

Arquitetura Peer-to-Peer (P2P) .................................................................... 21

Sistemas Distribudos ................................................................................... 13

Backup Cooperativo ..................................................................................... 39

Tipos de backup .................................................................................... 39

Backup em rede ..................................................................................... 41

MATERIAIS E MTODOS ................................................................................. 44

RESULTADOS E DISCUSSES ....................................................................... 50

Arquitetura da aplicao Peer Backup ......................................................... 51

Diagrama de classes .................................................................................... 53

Modelo de dados .......................................................................................... 58

Implementao da aplicao Peer Backup .................................................. 65

Testes realizados sobre a aplicao ............................................................ 83

CONSIDERAES FINAIS ............................................................................... 91

REFERNCIAS BIBLIOGRFICAS ................................................................... 93

Figura 1Troca de mensagens entre servidor e clientes ........................................... 14

Figura 33 - JXTA Configurator................................................................................... 73

LISTA DE ABREVIATURAS E SIGLAS

Com a expanso da internet e a facilidade de acesso aos recursos computacionais e

descentralizado utilizando P2P, no qual as cpias podem ficar armazenadas em ns

funcionalidades da rede, fornece ao usurio mtodos para realizao de backups em

assuntos 2.1 Sistemas Distribudos, 2.2 Arquitetura Peer-to-Peer, 2.3 Tecnologia

Nesta seo so abordados os principais conceitos referentes ao projeto, que so:

As redes de computadores possibilitam que computadores se conectem e troquem

Figura 1Troca de mensagens entre servidor e clientes

Na Figura 1, os usurios acessam a aplicao cliente que envia para o

2.1.1 Aspectos de Projeto

No projeto dos Sistemas Distribudos um conjunto de aspectos devem ser

crescimento da demanda, entre outras caractersticas desejadas em um sistema de

ocorra um problema na mquina que est o documento original, a cpia pode

Facilidade de administrao: mesmo com incluso muitas organizaes

A utilizao de sistemas distribudos interessante em diversas situaes,

as motivaes que levam a criao dos sistemas distribudos e a dificuldades

Compartilhamento de recursos: capacidade de utilizar recursos disponveis

Capacidade de concorrncia: caso a escala de usurios aumentar de forma

Capacidade de expanso: possibilidade de aumentar o poder de

Tolerncia a falhas: o sistema pode continuar funcionando mesmo quando

Por outro lado, se comparado a outros tipos de sistemas, o seu desenvolvimento

distribudos so complexos, levando em considerao a sua dimenso e que

Segurana: como os dados so compartilhados, preciso garantir que os

Rede de comunicao: a rede pode saturar por causa da quantidade de

Ao se decidir pelo desenvolvimento de um sistema distribudo, deve-se definir

Figura 2 - Servidor FTP