UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ADICIONANDO COMPORTAMENTO BASEADO EM BITTORRENT À
REDE LOP2P
Área de Sistemas Distribuídos
por
Jorge Fuck Junior
Rafael de Santiago, M.Sc.
Orientador
Itajaí (SC), junho de 2011
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ADICIONANDO COMPORTAMENTO BASEADO EM BITTORRENT À
REDE LOP2P
Área de Sistemas Distribuídos
por
Jorge Fuck Junior
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Rafael de Santiago, M. Sc.
Itajaí (SC), junho de 2011
i
AGRADECIMENTOS
A meus pais Jorge Fuck e Denise Porciuncula Fuck e minha irmã Marina Porciuncula Fuck
devo minha vida, seja por, dentre inúmeras razões, a alegria, perseverança, confiança e honestidade
que me passam diariamente. Sem a educação e compreensão que tive de meus pais, que sempre me
ajudaram em momentos de dificuldade e me exaltaram em momentos de felicidade, não consigo
imaginar como seria minha vida hoje.
A pessoa que mais me compreende neste mundo, sem que sequer eu diga alguma palavra.
Namorada, companheira, amiga, faltam palavras para descrever o seu papel na minha vida srta.
Camila Beaumord. Agradeço as suas correções de português, dicas de texto e sua paciência
também, tive meus momentos de mal humor e voce estava lá para me ajudar. Thanks dear!
Ao meu orientador e, acima de tudo amigo (de longa data), Professor e Mestre Rafael de
Santiago, expresso minha gratidão pela confiança e sabedoria passadas, sempre me auxiliando com
minhas dúvidas, perguntas e mais perguntas sobre tudo. Obrigado Rafa!
Tive grandes colegas durante todo o curso, gostaria de agradecer em especial os amigos
Ronie Pastorino de Oliveira e Rafael Piemontez, que estiveram comigo no início, embora tenhamos
perdido contato durante alguns momentos no decorrer do curso, a amizade que fizemos no primeiro
semestre de aulas ficou.
Agradeço a Prefeitura de Itajaí e a equipe do CTIMA, que quando enfrentei dificuldades no
desenvolvimento deste, foram compreensivos e me cederam tempo valioso para que pudesse me
concentrar.
Gostaria de extender meus agradecimentos também a algumas pessoas que, durante este
capítulo da minha vida, tive o prazer de conhecer dentre os ambientes profissionais em que estive.
Os amigos Ivan, Maicon, Paulo, José, muito aprendi com vocês, espero que tenhamos a chance de
trabalhar juntos novamente no futuro.
ii
SUMÁRIO
LISTA DE ABREVIATURAS................................................................... v
LISTA DE FIGURAS ................................................................................ vi
LISTA DE TABELAS .............................................................................. vii
RESUMO ..................................................................................................viii
ABSTRACT ................................................................................................ ix
1. INTRODUÇÃO ...................................................................................... 9
1.1. PROBLEMATIZAÇÃO ................................................................................... 12
1.1.1. Formulação do Problema ............................................................................... 12
1.1.2. Solução Proposta ............................................................................................. 12
1.2. OBJETIVOS ...................................................................................................... 13
1.2.1. Objetivo Geral ................................................................................................. 13
1.2.2. Objetivos Específicos ...................................................................................... 13
2. FUNDAMENTAÇÃO TEÓRICA ...................................................... 16
2.1. OBJETOS DE APRENDIZAGEM .................................................................. 16
2.1.1. SISTEMAS LOWARE (LEARNING OBJECTS – WARE) ...................... 18
2.1.2. Redes de repositórios ...................................................................................... 22
2.2. REDE LOP2P .................................................................................................... 26
2.2.1. Plugin loware ................................................................................................... 28
2.2.2. Camada de Mediação ..................................................................................... 28
2.3. REDES P2P ........................................................................................................ 30
2.3.1. Exemplos de Aplicações P2P .......................................................................... 31
2.3.2. Impactos Sociais das Tecnologias P2P .......................................................... 37
2.4. FRAMEWORK JXTA ...................................................................................... 38
2.4.1. JxtaCast............................................................................................................ 42
3. Desenvolvimento ................................................................................... 45
3.1. COMPORTAMENTO BITTORRENT .......................................................... 45
3.1.1. Divisão por blocos dos arquivos de OAs ....................................................... 45
3.1.2. Tipos de mensagens......................................................................................... 47
3.1.3. Comunicação entre peers ................................................................................ 51
3.1.4. Interação entre os peers e suas camadas ....................................................... 51
3.2. ANALISE DO CÓDIGO-FONTE LOP2P ANTERIOR ............................... 52
3.3. MUDANÇAS DO COMPORTAMENTO BITTORRENT APLICADAS AO
LOP2P 54
3.3.1. JxtaCast............................................................................................................ 54
3.3.2. Alterações no código ....................................................................................... 55
3.3.3. Segmentação e agrupamento dos OAs .......................................................... 60
3.3.4. Busca por blocos .............................................................................................. 62
iii
3.4. EXPERIMENTOS COM O COMPORTAMENTO BITTORRENT LOP2P
64
3.4.1. Resultados do ambiente controlado .............................................................. 65
3.4.2. Resultados em ambiente real ......................................................................... 71
4. CONSIDERAÇÕES FINAIS .............................................................. 75
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 77
iv
LISTA DE ABREVIATURAS
ARIADNE
CM
EA
ERP
IEEE
IP
IMS DRI
LCMS
LMS
LOP2P
LOR
LOWARE
LTSC
MD5
MOODLE
OA
OAI PMH
OER
P2P
PBP
PDP
PIP
PRP
RIVED
RVP
SBC
TCC
TCP/IP
UNIVALI
XML
Alliance of Remote Instructional Authoring and Distribution Network for
Europe
Camada de Mediação
Enterprise Architect
Endpoint Routing Protocol
Institute of Eletrical and Eletronics Engineer
Internet Protocol
Instructional Management Systems for Digital Repository Interoperability
Learning Content Management Systems
Learning Management Systems
Learning Objects Peer to Peer
Learning Object Repositories
Learning Objects - Ware
Learning Technology Standards Comitee
Message Digest Algorithm 5
Modular Object-Oriented Dynamic Learning Environment
Objeto de Aprendizagem
Open Archive Initiative Protocol for Metadata Harvesting
Open Education Resource
Peer to Peer
Pipe Binding Protocol
Peer Discovery Protocol
Peer Information Protocol
Peer Resolver Protocol
Rede Internacional Virtual de Educacíon
Rendezvous Protocol
Sociedade Brasileira de Computação
Trabalho de Conclusão de Curso
Transmission Control Protocol - Internet Protocol
Universidade do Vale do Itajaí
Extensible Markup Language
v
LISTA DE FIGURAS
Figura 1. Exemplo ilustrando o LOP2P com um comportamento BitTorrent ...................................11
Figura 2. Componentes de um LMS ..................................................................................................18
Figura 3. Componentes de um LCMS ................................................................................................ 20
Figura 4. Itens fundamentais para um repositório de OA ..................................................................21
Figura 5. Funções na camada de mediação IMS DRI ........................................................................25
Figura 6. Cenário com a rede LOP2P ................................................................................................ 27
Figura 7. Arquitetura da CM e integração com o sistema loware......................................................30
Figura 8. Exemplo de uso da Aplicação Napster ...............................................................................32
Figura 9. Exemplo de uso da aplicação Gnutella ...............................................................................33
Figura 10. Exemplo de uso da Aplicação BitTorrent .........................................................................36
Figura 11. Camadas do framework JXTA .......................................................................................... 39
Figura 12. Pipes e intermediários entre peers ....................................................................................41
Figura 13. Grupos de peers e Rendezvous nodes ...............................................................................42
Figura 14. Divisão do arquivo em blocos .......................................................................................... 46
Figura 15. Uso das mensagens entre os peers ....................................................................................50
Figura 16. Diagrama de sequência com a Interação entre os peers e suas Camadas de Mediação ...51
Figura 17. Engenharia reversa do código-fonte LOP2P, pacote Network Communication Device –
envio de mensagens. ...................................................................................................................53
Figura 18. Engenharia reversa do código-fonte LOP2P, pacote Network Communication Device recebimento de mensagens. ........................................................................................................54
Figura 19. Diagrama de classes do pacote protoSubmitDevice .........................................................57
Figura 20. Diagrama de classes do pacote protoNetCommunicationDevice .....................................59
Figura 21. Diagrama de classes do pacote protoSearchDevice .........................................................59
Figura 22. Segmentação do OA, de forma detalhada .........................................................................61
Figura 23. Agrupamento do OA, de forma detalhada ........................................................................62
Figura 24. Busca por blocos dentre os peers ......................................................................................63
Figura 25. Diagrama de redes para a infra-estrutura descrita na tabela 3 ..........................................66
Figura 26. Camada de Mediação do peer LOP2Pb2 ..........................................................................67
Figura 27. LOP2Pb2 após o agrupamento dos blocos e com o arquivo original aberto ....................68
Figura 28. LOP2Pb4 realizando o download de todos os blocos e os agrupando.............................. 69
Figura 29. Diagrama de redes para a estrutura descrita na tabela 4 ...................................................70
Figura 30. LOP2Pb1 realiza o download de todos os blocos a partir de LOP2Pb4 e LOP2Pb5 .......71
Figura 31. Diagrama de redes com a estrutura descrita na tabela 5 ...................................................72
Figura 32. LOP2Pb6 após o download dos blocos.............................................................................73
Figura 33. Diagrama de redes detalhando a estrutura descrita na tabela 6 ........................................74
vi
LISTA DE TABELAS
Tabela 1. Comparativo entre redes de repositórios ............................................................................23
Tabela 2. Comparativo entre as aplicações P2P .................................................................................37
Tabela 3. Dispositivos para o primeiro experimento em ambiente controlado ..................................65
Tabela 4. Dispositivos para o segundo experimento em ambiente controlado ..................................69
Tabela 5. Dispositivos para o primeiro experimento em ambiente real .............................................72
Tabela 6. Dispositivos para o segundo experimento em ambiente real .............................................73
vii
RESUMO
FUCK JUNIOR, Jorge. Adicionando comportamento baseado em BitTorrent à rede LOP2P.
Itajaí, 2011. 80 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro
de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2011.
As soluções na área de sistemas distribuídos se encontram em constante evolução e adaptação
devido ao surgimento de novos conceitos, modelos, hardwares e necessidades impostas pelo
contexto ao qual estão aplicadas. Este trabalho relata uma mudança à arquitetura LOP2P, que faz
uso da tecnologia P2P para distribuir objetos de aprendizagem entre instituições de ensino por meio
da Internet. A arquitetura LOP2P realiza a conexão entre os repositórios de instituições de ensino e
foi concebida de forma que, quando um arquivo é solicitado, o mesmo deve ser enviado por
completo em uma conexão, de uma única origem, não tolerando falhas ou interrupções na mesma.
Isso se torna um problema quando se trata de arquivos de grande volume; a mudança que este
projeto propôs visa alterar a forma como estes arquivos são enviados e recebidos. Para tal, foi
adicionado um comportamento baseado em características semelhantes a do protocolo BitTorrent,
que foi passível de implementação através do uso do framework especifico para aplicações P2P, o
JXTA. Após a implementação do comportamento BitTorrent, tornou-se possível que arquivos sejam
segmentados, em partes com tamanho pré-definido, para que sejam enviados ao software solicitante
que se responsabiliza por juntar as partes recebidas, tornando assim o arquivo completo e pronto
para ser executado ou visualizado. Esta mudança tem como objetivo dar uma maior escalabilidade à
arquitetura LOP2P, deixando a ferramenta mais robusta e mais tolerante a falhas, dado ao
comportamento BitTorrent, para que a mesma possa crescer em seu uso pelas instituições de ensino
que desejam compartilhar seus objetos de aprendizagem.
Palavras-chave: Sistemas Distribuídos. LOP2P. BitTorrent.
viii
ABSTRACT
The solutions in the area of Distributed Systems are in constant evolution and adaptation due to the
emergence of new concepts, models, hardware and requirements imposed by the context to which
they are applied. This project details a change in the LOP2P architecture, which uses P2P
technology to distribute learning objects among learning institutions through the Internet. The
LO2P architecture connects learning institutions repositories and was designed so that when a file
is requested, it must be sent completely in one connection, from a single source, not tolerating
failures or interruptions. This becomes a problem when it comes to files with greater volumes; the
changes donehere seek to modify the way these files are sent and received. To do so, the project
consists in adding a behavior based on similar characteristics of the BitTorrent protocol, which
were implemented due to the use of a framework specifically designed for P2P applications, JXTA.
After the implementation of the BitTorrent behavior, it became possible for files to be segmented
into parts with predefined size, so they are sent to the requester who will be responsible for piecing
together the parts received, thus making the file complete and ready to be executed or displayed.
This change aims to give a higher scalability to the LOP2P Architecture, leaving the tool more
robust and fault tolerant due to the BitTorrent behavior, so that it can grow in its use by learning
institutions that wish to share their learning objects.
Keywords: Distributed Systems. LOP2P. BitTorrent.
ix
1. INTRODUÇÃO
Um Sistema Distribuído é definido por Jia e Zhou (2005) como um sistema constituído de
uma coleção de maquinas autônomas conectadas por uma rede de comunicação e equipadas com
um sistema de software desenhado para produzir um ambiente de computação integrado e
consistente. Levando em conta essa definição, a área de sistemas distribuídos tem sido beneficiada
por um rápido processo de avanço tecnológico, como por exemplo, os componentes citados por Jia
e Zhou (2005), o aumento de banda de Internet que tivemos nos últimos anos e a quantidade e poder
de computadores desktops, que têm aumentado com novas tecnologias de processamento multi-core
a custo mais acessivel.
Dentre as soluções criadas em sistemas distribuídos, pode-se citar o popular Napster, que
teve seu inicio em 1999 e se popularizou em 2000, criando uma rede em que cada desktop agia
como cliente e servidor, tornando-se assim uma rede de compartilhamento de músicas através da
Internet. Embora tenha tido um promissor inicio, conseguindo até oito milhões de usuários
conectados e um volume de 20 milhões de músicas sendo trocadas diariamente, grandes gravadoras
e selos musicais detentores dos direitos destas músicas não aprovaram a ideia de uma rede em que
suas músicas por direito seriam distribuídas sem nenhum lucro para as mesmas. Começaram-se
então os processos judiciais que acabaram pelo fim do Napster em março de 2001. Passado o
choque ocasionado tanto pelo inicio quanto pelo fim do Napster, uma grande ideia havia sido
popularizada e o legado havia sido deixado para aplicações similares que viriam a usar uma forma
de distribuir arquivos, o P2P.
A tecnologia P2P, conforme a definição de Shirky (2000), é uma classe de aplicações que
toma vantagem de recursos (ex. storage, cycles, conteúdo) disponíveis em computadores
conectados à Internet (chamados também de peers edge). Tendo uma definição ampla, as
tecnologias P2P tem sido extensivamente usadas para diversos tipos de aplicações, como Napster,
Gnutella, Kazaa, Limewire, BitTorrent e até Skype.
Dentre as ferramentas mais populares para distribuição de arquivos, o BitTorrent introduziu
dois importantes conceitos: (i) o fato de não usar um sistema ou um protocolo próprio para busca de
arquivos, a busca é feita através de paginas na Internet que contenham arquivos .torrent; (ii) outro
conceito é o de File Swarming, que quer dizer que, uma vez que se começa a baixar parte de um
arquivo, essa parte já se torna disponível a outros peers também interessados no mesmo arquivo,
isso tudo controlado por um software que utiliza o protocolo HTTP, chamado tracker, que pode
9
manter e controlar informações úteis como velocidade de download e upload de seus peers e saber
onde na rede está o próximo segmento do arquivo que está sendo baixado.
As aplicações com a tecnologia P2P são muitas. Este trabalho em questão aborda uma
alteração de comportamento em uma ferramenta já existente, o LOP2P, que é uma arquitetura que
possibilita o compartilhamento de Objetos de Aprendizagem, definido por Wiley (2000) como
qualquer recurso digital que pode ser reutilizado para apoiar a aprendizagem. Proposta por Santiago
(2009), a arquitetura LOP2P possibilita que instituições de ensino compartilhem seus repositórios,
buscando assim quebrar o isolamento que ocorre com os Objetos de Aprendizagem no cenário
atual, em que esse material é desenvolvido e armazenado, mas falha no seu propósito de ser
reaproveitado e reusado por outras instituições.
A arquitetura LOP2P utiliza o modelo peer-to-peer, em que instituições de ensino utilizam
um plugin LOP2P junto ao seu atual Ambiente Virtual de Aprendizagem (ou Sistema de
Distribuição de Objetos de Aprendizagem), como, por exemplo, o MOODLE, para se conectarem a
uma rede na qual ocorre a troca de mensagens (SANTIAGO, 2009).
A principio, o LOP2P distribui os objetos de uma forma em que, caso haja alguma
interrupção no serviço de Internet ou qualquer outra interrupção durante o download, o Objeto de
Aprendizagem que está sendo feito o download é perdido e o usuário terá de ser realizar o
download novamente do inicio; isso se torna um problema quando tratamos de Objetos de
Aprendizagem com grandes tamanhos e quando o peer interessado ou o peer que possui o arquivo
estão apresentando algum problema com o link de Internet. Outro problema que não é abordado
pelo LOP2P é de que a velocidade do download de Objetos de Aprendizagem é sempre nivelada
pela taxa de upload de determinado peer que possui o arquivo a ser baixado, pois o arquivo é
baixado por completo de somente um peer. O problema se dá nesse caso porque a taxa de upload é
sempre relativamente menor a taxa de download em links banda larga disponíveis no Brasil
(tecnologia ADSL).
Implementar um comportamento BitTorrent ao LOP2P significa dar mais flexibilidade no
download de Objetos de Aprendizagem, fazendo com que eles possam ser baixados em segmentos,
aproveitando melhor assim a banda de internet das instituições. Significa também adicionar um
modulo similar ao tracker HTTP do BitTorrent, para manter abrigadas informações de download e
upload de vários peers para melhorar o método de download/upload no uso da ferramenta por
outras instituições de ensino.
Uma maior disponibilidade dos Objetos de Aprendizagem pode ser alcançada com o
comportamento BitTorrent, pois, como complemento às tecnologias P2P, ela utiliza dos benefícios
10
de um cenário em que haja muitas pessoas interessadas no mesmo arquivo, já que, com um apenas
um segmento baixado já é possível contribuir através do compartilhamento deste com a rede.
Um exemplo do comportamento acima é ilustrado na Figura 1, onde a instituição de ensino
A quer fazer o download de um Objeto de Aprendizagem X. O resultado da pesquisa realizada por
A é de que as instituições B, C e D possuem esse arquivo, mas B e C possuem somente alguns
segmentos porque ainda estão realizando o download do mesmo conteúdo também, enquanto D
possui o arquivo completo; o processo de download é então iniciado para A, de forma que B e C
ainda continuam realizando o download dos segmentos aos quais já estavam fazendo normalmente.
Figura 1. Exemplo ilustrando o LOP2P com um comportamento BitTorrent
Ao realizar essa alteração de comportamento na arquitetura LOP2P, estará preparando-a para
abrigar cada vez mais instituições interessadas em compartilhar materiais de ensino, visto que, com
o comportamento BitTorrent, é possível tornar o maior interesse de peers em determinado arquivo
em disponibilidade do mesmo na rede LOP2P.
11
1.1. PROBLEMATIZAÇÃO
1.1.1. Formulação do Problema
A principal característica dos Objetos de Aprendizagem (OAs) é a sua reusabilidade. No
cenário atual, muitas instituições de ensino possuem um sistema loware (Learning Objects - Ware)
para armazenar estes objetos e distribuí-los aos seus alunos de acordo com seu curso e grade
curricular; os mesmos até gerenciam o aprendizado do aluno. Com base nesse contexto, foi criada
uma rede para fortificar a característica de reusabilidade destes OAs, fazendo com que sistemas
loware de diversas instituições de ensino pudessem ampliar os seus repositórios, compartilhando-os
entre si.
A rede LOP2P visa à maior distribuição de OAs por instituições de ensino através de seus
sistemas loware, conectando-as entre si utilizando um modelo P2P em que as instituições de ensino
realizam as buscas diretamente em outras.
Mesmo dando-se a possibilidade às instituições de ensino de compartilhar seus OAs, a rede
ainda pode aproveitar-se de outras vantagens de uma rede P2P. Visto que, com o advento da rede
LOP2P, essas instituições de ensino compartilharão cada vez mais objetos entre si, muitos OAs que
antes eram disponibilizados por somente uma delas, estarão disponíveis em um grupo de peers.
Com o numero crescente de instituições de ensino procurando por este determinado objeto, a carga
de rede pode ser muito alta e não bem aproveitada, tornando-se um gargalo, visto que há um grande
grupo de peers com o determinado objeto e que estão ociosos, enquanto o download é realizado de
somente uma instituição.
1.1.2. Solução Proposta
Este trabalho relata uma alteração à rede LOP2P, especificamente na forma como a qual
distribui os arquivos às instituições de ensino, baseando-se no protocolo BitTorrent e nos conceitos
que o mesmo introduziu às atuais soluções de distribuição de arquivos em redes P2P.
Esta solução visa adicionar a divisão por blocos destes arquivos a serem distribuídos, para
que instituições de ensino possam aproveitar ao máximo de suas conexões e façam download de
não um só peer, mas sim de vários outros pertencentes ao grupo e que possuam o arquivo
procurado, empregando assim também princípios cada vez mais avançados de sistemas distribuídos.
12
Este trabalho tem como objetivo solucionar os problemas de crescimento da rede LOP2P por
adicionar um comportamento BitTorrent a mesma, aumentando assim a escalabilidade do projeto
original. Isso possibilitará às instituições de ensino que distribuam seus OAs de maneira mais
eficaz, tirando proveito máximo de suas conexões e não sobrecarregando suas redes internas e
acessos externos.
1.2. OBJETIVOS
1.2.1. Objetivo Geral
O Objetivo Geral deste trabalho é adaptar o comportamento BitTorrent à arquitetura LOP2.
1.2.2. Objetivos Específicos
Os Objetivos Específicos a serem atingidos são:

Pesquisar sobre redes peer-to-peer e BitTorrent;

Pesquisar sobre Objetos de Aprendizagem e sistemas loware;

Pesquisar sobre o framework JXTA, procurando a melhor forma de criar o
comportamento BitTorrent;

Pesquisar se há alguma solução já desenvolvida em algum outro framework;

Analisar e compreender atual código do LOP2P;

Realizar uma modelagem a fim de redefinir um modelo da arquitetura com a nova
característica;

Implementar as mudanças propostas;

Avaliar peers na WAN;

Realizar a validação do produto final em ambiente real; e

Documentar todo o desenvolvimento e resultados.
13
1.3.
Metodologia
Para atender com as necessidades do projeto proposto, as atividades foram divididas e
realizadas da seguinte forma:

Definição do Tema: nesta etapa teve foram definidos assuntos relacionados ao tema,
como tecnologias a serem estudadas, frameworks a serem pesquisados, como o tema se
aplicaria e como poderia se forrnar um trabalho de conclusão;

Definição de Introdução, Escopo e Objetivos: após definido o tema, foi necessário
elaborar uma Introdução ao trabalho, que foi de ajuda também para melhor exemplificar
a idéia central do trabalho e definir o escopo ao qual este projeto se propõe. Pesquisas
quanto a redes P2P, LOP2P e Objetos de Aprendizagem foram realizadas a fim de
definir e chegar a um consenso do que seria o escopo do projeto;

Estudos: levantamento bibliográfico foi realizado nessa etapa com o propósito de
verificar o material necessário para a escrita da Fundamentação Teórica e de base para
construção do projeto. Foram utilizados recursos como e-books, dissertações e artigos.
Após o levantamento do material necessário, deu-se inicio ao processo de leitura do
mesmo, realizando anotações durante e escrevendo a Fundamentação Teórica em
paralelo;

Projeto: após a conclusão da Fundamentação Teórica, deu-se inicio ao capítulo referente
ao projeto a ser desenvolvido, levando em conta os objetivos definidos no inicio das
atividades e as soluções já levantadas. Durante a escrita do Projeto, ainda foram
realizadas leituras sobre o protocolo JxtaCast e o protocolo BitTorrent, assim como a
engenharia reversa do código LOP2P, a fim de definir o projeto a ser implementado;

Desenvolvimento: nesta etapa deu-se inicio o desenvolvimento do comportamento
proposto, com base no projeto especificado. Foi diagnosticado nesta etapa a deficiência
do protocolo JxtaCast, que é explicado em detalhes no capítulo Desenvolvimento e como
foi possível implementação do comportamento sem o mesmo.

Experimentos e Resultados: foram realizados experimentos com o comportamento já
aplicado a arquitetura LOP2P e documentados. Nesta etapa também foram identificadas
mínimas alterações necessárias para o melhor funcionamento do comportamento.
14
1.4.
Estrutura do trabalho
Este documento está estruturado em quatro capítulos. Em seguida, é feita uma breve
descrição sobre eles.
O Capítulo 1, Introdução, apresentou uma visão geral e histórica do peer-to-peer, Objetos de
Aprendizagem, a rede LOP2P e a motivação para a escolha do tema. Foram definidos os objetivos e
detalhado a problematização ao qual este trabalho se refere, além da metodologia aplicada ao
projeto.
No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica sobre temas
relevantes ao projeto proposto, como objetos de aprendizagem, rede LOP2P e framework JXTA,
assim como uma análise a respeito de redes P2P no geral.
O Capítulo 3 apresenta o Desenvolvimento detalhado do comportamento proposto,
especificando-o textualmente e por meio de diagramas de sequência e diagramas de classe. Este
capítulo também discute como foi implementado o comportamento BitTorrent e o que teve de ser
alterado na arquitetura da rede LOP2P, além de apresentar a metodologia utilizada no
desenvolvimento do projeto. Ao final deste capitulo, são apresentados o experimentos realizados
com a arquitetura já carregando o comportamento BitTorrent.
Concluindo, no Capítulo 4, apresentam-se as Considerações Finais, onde são abordados os
resultados, mudanças de algumas estratégias de desenvolvimento do projeto, alterações realizadas
ao cronograma, dentre outros.
15
2. FUNDAMENTAÇÃO TEÓRICA
Este capítulo documenta a pesquisa teórica relacionada aos temas deste TCC, explicando
conceitos e aplicações. São abordados os seguintes temas: objetos de aprendizagem, repositórios e
redes de repositórios para objetos de aprendizagem, redes P2P com foco no protocolo BitTorrent,
rede LOP2P, framework JXTA e o protocolo JxtaCast.
2.1. Objetos de Aprendizagem
Wiley (2000) define um OA como qualquer recurso digital ou não, que pode ser utilizado e
reutilizado para auxiliar o aprendizado; estes objetos possuem uma característica fortemente similar
ao conceito de Orientação a Objetos, em que os mesmos podem ser usados e reusados em contextos
diferentes de aprendizado, independentemente de que abranjam uma pequena ou grande quantidade
de assuntos. Um OA também pode ser visto como uma entidade digital que pode ser distribuída via
Internet, viabilizando assim o seu acesso simultâneo por um grande volume de pessoas; essa visão
separa o antigo e o novo conceito de OA, o qual este trabalho de baseia; exemplos de antigos OA
seriam os recursos não digitais como uma fita-cassete ou algum outro material físico, do novo,
vídeos distribuídos de forma digital, programas educacionais, textos.
O padrão atual de OA é mantido e promovido pela LTSC (Learning Technology Standards
Comitee). Formada em 1996 pela IEEE (Institute of Eletrical and Eletronics Engineer), a LTSC tem
como objetivo assegurar de que a interoperabilidade entre os OA seja mantida.
A principal característica de um OA é a sua reusabilidade. Uma vez que um OA é criado, ele
deve ser reusado ao máximo nos demais contextos ao qual for adequado. Tomando como exemplo,
para se entender o conceito de reusabilidade e abrangência de um OA, pode-se pensar no ensino de
teoria e pratica sobre um instrumento musical. Um objeto trataria do ensino de um instrumento,
como o contrabaixo, assim como outros tratariam dos demais instrumentos musicais, como violão
ou piano, ensinando técnicas e particularidades de cada instrumento. Estes objetos podendo ser
vídeos explicativos ou aulas em forma de um programa interativo. Podem existir também outros
OAs que sejam mais abrangentes, como um que ensine teoria musical, o qual pode ser parte de um
contexto de aprendizagem que envolva quaisquer outros instrumentos de cordas, de forma que a
mesma teoria musical pode ser reaproveitada e reaplicada para o ensino de diversos instrumentos de
cordas.
16
Devido à característica principal dos OAs, que é a reusabilidade, é imprescindível que eles
possam ser utilizados livremente, sendo que o uso de licenças restritivas atrapalha este reuso.
Embora as leis de propriedade intelectual no Brasil e outros países como Estados Unidos e
Inglaterra protejam o direito do autor a partir do momento que o produto, seja ele uma obra literária,
software, música, trabalho artístico é criado, lhe dando os devidos direitos legais sobre o produto de
tais criações (LOW et al., 2008; WILEY, 2000), isso cria uma barreira no reuso de OAs por
terceiros, Wilhelm e Wilde (2005) afirmam que o encargo de obter licença de copyrights para que
um OA possa ser usado no curso da produção de um contexto de aprendizado envolvendo diversos
OAs pode bloquear todo o processo de produção do contexto em si.
O processo de obtenção de copyrights para utilização de OAs com o autor ou detentor dos
direitos do mesmo envolve dois custos ao usuário que esteja querendo adaptar ou realizar quaisquer
modificações ao OA solicitado. O primeiro é o custo financeiro em troca do direito de uso e
adaptação do OA, caso o autor ou detentor dos direitos julgue necessário. O segundo é o tempo
gasto em descobrir o autor ou quem detêm os direitos do OA que está sendo utilizado, entrar em
contato com o mesmo e negociar um contrato ao qual dá os direitos necessários ao usuário que
deseja realizar as adaptações ou modificações.
Em 2002, a fundação William and Flora Hewlett apresentou o termo OER (Open
Educational Resource, ou recurso de educação aberto). A definição apresentada é de que se trata de
recursos educacionais provenientes de tecnologia, abertos para consulta, uso e adaptação por uma
comunidade de usuários para objetivos não comerciais. São tipicamente disponibilizados livremente
pela Internet. Seu principal uso é por professores e instituições de ensino, mas também podem ser
usados diretamente por estudantes. Recursos educacionais abertos incluem OAs como material de
leitura, simulações, experimentos e demonstrações, assim como syllabi, curricula e guias de
professores (UNESCO, 2002).
A idéia proposta isenta o individuo que deseja reutilizar algum OA de custos agregados ao
licenciamento tradicional, visto que os recursos de educação abertos descritos podem utilizar
licenças como a Creative Commons License e a GNU Free Document License, que permitiriam o
livre acesso.
17
2.1.1. Sistemas loware (Learning Objects – ware)
São denominados sistemas loware (SANTIAGO, 2009) softwares que possuam suporte a
OAs. Nas próximas Subseções, alguns destes sistemas citados na literatura serão classificados e
definidos.
2.1.1.1.
LMS (Learning Management Systems)
De acordo com Irlbeck e Mowat (2007), LMS são sistemas que simplificam a administração
do aprendizado, possibilitando aos estudantes planejar e monitorar a sua jornada de aprendizado,
facilitando também a interação dos estudantes entre si e com o professor, através da criação de
turmas, salas de bate-papo, fóruns.
Na Figura 2 é mostrado o relacionamento dos componentes que estão envolvidos em um
LMS, sendo o Gerenciador de Estudante responsável por acompanhar os passos do aluno, e o
Gerenciador de Aprendizagem um componente que define a configuração da jornada do
aprendizado (SANTIAGO, 2009).
Figura 2. Componentes de um LMS
Fonte: adaptado de Irlbeck e Mowat (2007)
18
Podem-se citar três exemplos de sistemas LMS utilizados hoje: o (i) MOODLE, o (ii)
Teleduc e o (iii) WebCT.
O MOODLE (Modular Object-Oriented Dynamic Learning Environment) possui código
aberto e é amplamente utilizado no Brasil devido a sua ativa comunidade de software livre, o que
permite atualizações e correções de possíveis problemas com a ferramenta. Ele é utilizado
atualmente pela UNIVALI (Universidade do Vale do Itajaí) para gerenciar o aprendizado de seus
alunos e foi o escolhido pela rede LOP2P para os primeiros testes com a ferramenta, que é discutida
na Subseção 2.2.
2.1.1.2.
LCMS (Learning Content Management Systems)
Irlbeck e Mowat (2007) afirmam que LCMS trata-se de um software voltado a autoria de
materiais de aprendizagem digitais, permitindo que o conteúdo produzido seja gravado, gerenciado
e reusado através de um sistema integrado de bases de dados gerenciáveis pelos autores.
Na Figura 3 é mostrado o relacionamento entre os componentes que formam um LCMS.
Muito há em comum com um sistema LMS, visto que um LCMS se trata basicamente de um LMS
com suporte a autoria de OAs (SANTIAGO, 2009).
19
Figura 3. Componentes de um LCMS
Fonte: adaptado de Irlbeck e Mowat (2007)
2.1.1.3. LOR (Learning Object Repositories)
Os repositórios de objeto de aprendizagem têm como principal objetivo armazenar OA
(Objeto de Aprendizagem), facilitar a localização dos mesmos por meio de buscas nestes
repositórios partindo de tópicos (como temas, autores, formato) e fazer a distribuição destes
arquivos a seus solicitantes. Estes geralmente são utilizados em conjunto com um LMS ou LCMS.
O RIVED (Rede Internacional Virtual de Educacíon) é um exemplo de um repositório de
OA aplicado a América Latina. Segundo Nascimento e Morgado (2008), a ferramenta foca o uso de
tecnologias digitais para as áreas de ciências e matemática do ensino médio. Os OAs utilizados pelo
repositório são produzidos através de uma serie de passos, que são desempenhados por uma equipe
multidisciplinar em cada pais participante (NASCIMENTO; MORGADO, 2008).
20
Segundo Santiago (2009), a arquitetura básica de um repositório contém três itens
fundamentais: (i) repositório de conteúdo, onde os OA são armazenados junto com seus metadados,
(ii) Mecanismo de Indexação e Pesquisa, que realiza a indexação com base nestes metadados e
provê um sistema de busca e (iii) Mecanismo de Interface, que fornece a funcionalidade de pesquisa
para um software ou usuário final. A Figura 4 descreve os itens citados.
Figura 4. Itens fundamentais para um repositório de OA
Fonte: adaptado de Santiago (2009)
Tendo visto a arquitetura básica de sistemas loware, devemos entender como os repositórios
destes sistemas podem ser unidos, mesmo partindo de iniciativas diferentes, para que possam
manter uma comunicação entre si e compartilhar estes OAs armazenados com seus usuários.
21
2.1.2. Redes de repositórios
De acordo com Irlbeck e Mowat (2007), a iniciativa de implantar e manter um repositório de
Objetos de Aprendizagem é comum em diversas instituições de ensino. Muitas produzem OAs para
uso próprio ou para filiados e precisam de um repositório para mantê-los organizados. Percebe-se
então que, mesmo com o fato de manter repositórios, a característica de reusabilidade que os OAs
possuem ainda não está em seu total uso, tendo que sua área de abrangência acaba-se limitando a
somente um repositório, uma instituição de ensino.
A fim de unir estes repositórios, as redes de repositórios têm como objetivo integrar
repositórios e definir padrões de interoperabilidade para os mesmos (SANTIAGO, 2009)
Exemplos de redes de repositórios podem ser visualizados na Tabela 1. Segue a descrição de
alguns deles:

ARIADNE: é citado na tabela como uma rede de repositórios que interliga outras redes
de repositórios, como o Edusource. A diferença entre os dois está em que o ARIADNE
fornece uma busca através de um endereço publicado na Web, o Edusource fornece uma
API que habilita aplicações clientes a realizarem buscas por OAs;

Lomster: conecta usuários que desejam compartilhar OAs e não repositórios como nos
exemplos vistos anteriormente. Possui uma característica que o destaca que é a
indexação dos OAs através do um padrão de metadados; e

LOP2P: é explicada em mais detalhes na Subseção 2.2.
22
Tabela 1. Comparativo entre redes de repositórios
Iniciativas
Conecta quem
Como conecta
Principalmente
OAs Livres
ARIADNE
(Edutella)
Redes de
repositórios e provê
pesquisa federada
Conecta repositórios com um
provedor peer-to-peer e provê
aplicação cliente para
pesquisa
Não
Edusource
Rede que conecta
repositórios
Uma API para criação da
conexão com a rede de
repositórios é disponibilizada
Não
Lomster
Conecta pessoas que
desejam
compartilhar OAs
Conecta os usuários através de
uma rede peer-to-peer e
publica os OAs
compartilhados
Não
LOP2P
Conecta
principalmente
instituições de
ensino para
compartilhamento de
OAs. Pode conectar
repositórios
Conecta a instituição de
ensino através dos sistemas de
gerenciamento de aprendizado
(LMS)
Sim
Fonte: Santiago (2009)
Para que uma rede de repositórios possa realizar a integração de repositórios de OA, é
necessário haver um padrão de interoperabilidade entre eles. Segundo Hatala et al. (2004), podem
ser considerados dois padrões para a integração de repositórios de OA distribuídos, o (i) OAI PMH
(Open Archive Initiative Protocol for Metadata Harvesting) e o (ii) IMS DRI (Digital Repository
Interoperability). Como a rede LOP2P, a qual esse trabalho pretende realizar uma mudança no
comportamento, utiliza-se primordialmente do IMS DRI, detalhado na subseção a seguir.
23
2.1.2.1.
IMS DRI (Digital Repository Interoperability)
A IMS é um consorcio global que, de acordo com Hatala (2004), foca-se em padrões de
aprendizagem e desenvolve especificações para o contexto de ensino, que são divididos em três
documentos: (i) modelos de informação, (ii) convenções XML e (iii) um guia de melhores praticas
de programação.
O IMS DRI (Digital Repository Interoperability) é um padrão que especifica uma
arquitetura funcional e um modelo de referencia para interoperabilidade de repositórios, sendo
necessária em casos de repositórios diferentes, provenientes de iniciativas divergentes que não se
comunicam, estabelecendo então uma camada de adequação no intuito de integrar estes repositórios
para que se pareçam com uma unidade (SANTIAGO, 2009).
As principais funções que o padrão aborda para esta camada de mediação, por parte do
utilizador de recursos ou um sistema loware são: search, submit, gather, alert, request. Quanto aos
repositórios, as funções implementadas são as de store, manage, expose e deliver. Pode-se
visualizar o modelo e suas iterações de forma mais clara na Figura 5.
24
Figura 5. Funções na camada de mediação IMS DRI
As linhas vermelhas indicam as iterações entre as funções, repositórios e utilizadores destes
recursos, funções estas que garantem que a interoperabilidade seja mantida entre eles. Tais funções
podem ser descritas como:

Search/Expose: procura o metadado de um ou mais repositórios e retorna os registros
encontrados;

Gather/Expose: recolhe registros de metadados de um ou mais repositórios para prover
um repositório de registros agregados;

Alert/Expose: dispara um alerta quando um metadado é modificado em um ou mais
repositórios. A razão de essas funções estarem ligadas por uma linha pontilhada é a de
até o momento, a função Alert se encontrar somente como sugestão de melhores práticas,
25
podendo ter como forma de distribuição o protocolo de e-mail SMTP para distribuição
de tais alertas;

Submit/Store: envia o OA e seu metadado a um repositório, onde a função Store
armazena ambos metadados e OA no repositório; e

Request/Deliver: solicita um determinado OA a um repositório, onde Deliver é a reposta
a solicitação feita, por parte do repositório selecionado.
A rede LOP2P, que será apresentada em seguida, faz uso primordial do padrão de
interoperabilidade IMS DRI descrito, utilizando-se dos conceitos propostos pelo padrão como a
camada de mediação e suas funções de repositórios interoperáveis, que também serão vistos em
seguida.
2.2. Rede LOP2P
Proposta por Rafael de Santiago (2009), a rede LOP2P fornece uma integração para sistemas
loware de instituições de ensino baseado em uma rede P2P. Segundo o autor, a característica
principal do LOP2P é viabilizar o compartilhamento de OAs entre instituições de ensino por meio
de seu sistema loware, em vez de computadores pessoais. Deste modo, cada instituição conectada é
considerada um peer.
A conexão entre os sistemas loware das instituições é feita utilizando dois componentes, (i)
uma Camada de Mediação, para se conectar a rede LOP2P e o (ii) Plugin loware (Learning Object Ware) que conecta o sistema loware da instituição à Camada de Mediação.
Pode-se visualizar na Figura 6 um ambiente com a rede LOP2P, onde peer 1 realiza uma
busca por OA (X); essa pesquisa então é disparada para os outros peers conectados a rede, peer 2
envia uma mensagem à peer 1 comunicando-o que possui o OA em questão, então o download é
iniciado a partir de peer 2:
26
Figura 6. Cenário com a rede LOP2P
A arquitetura da rede LOP2P provê os seguintes serviços, baseados no padrão IMS DRI:

Publicação de OAs: publicar o OA no repositório local e buscas realizadas em outras
instituições conseguem visualizar esse OA em seus resultados;

Busca por OA: pode ser conduzida uma busca por OA localizados em outras instituições
conectadas a rede;

Download: uma vez localizado o OA desejado, pode ser feito o download do mesmo; e

Visualização: em caso de OA que seja configurado para visualização online, ele pode ser
visualizado e utilizado online.
27
A rede LOP2P consegue facilmente abrigar novas instituições que estejam interessadas em
distribuir seus OAs para outras. É necessário somente que a instituição utilize o Plugin loware, que
é explicado em mais detalhes na subseção a seguir, em conjunto com o seu sistema loware. A partir
daí, o mesmo conseguirá se comunicar com a Camada de Mediação, detalhada na Subseção 2.2.2,
que por sua vez, fará a integração com os demais repositórios.
2.2.1. Plugin loware
Para que o sistema loware consiga se comunicar com a Camada de Mediação e possa utilizar
os serviços da rede LOP2P, é necessário que haja um software junto ao sistema loware. Este
software é chamado de Plugin, pois suas funcionalidades complementam as funções do loware. Um
Plugin deve viabilizar com a Camada de Mediação um canal de comunicação através do uso de
sockets (SANTIGO, 2009).
Pode-se visualizar o Plugin loware dentro de um peer na Figura 6.
2.2.2. Camada de Mediação
A Camada de Mediação (CM) é responsável por promover a comunicação do sistema
loware à rede LOP2P, garantindo a interoperabilidade através de funções baseadas no padrão IMS
DRI. São elas:

Mecanismo de Tradução: responsável por fazer a tradução da requisição realizada pelo
sistema loware para a Camada de Mediação, para que a mesma possa as requisições
dessa aplicação. Realiza também a tradução de mensagens originadas da Camada de
Mediação para o sistema loware;

Mecanismo de Interface para a comunicação com o sistema loware: recebe as mensagens
do sistema loware e as repassa aos mecanismos da Camada de Mediação, responsável
também por receber as mensagens da CM e entregá-las ao sistema loware;

Mecanismo de Comunicação com a rede P2P: responsável por manter a Camada de
Mediação conectada a rede P2P e por garantir que os serviços disponibilizados pelo
sistema loware sejam divulgados na rede e estejam à disposição de outros peers
interessados;
28

Submit/Store: função de mesmo nome do padrão IMS DRI, é responsável por receber a
solicitação de recuperação de OAs, solicitados pelo sistema loware, provenientes de
algum peer na rede;

Request/Deliver: função de mesmo nome do padrão IMS DRI, é responsável por
fornecer um meio para a exibição de OAs, no qual o peer realiza a solicitação a Camada
de Mediação a visualização de um objeto previamente pesquisado, então a CM solicita a
visualização ao sistema loware que o transmite para o peer solicitante;

Search/Expose: função de mesmo nome do padrão IMS DRI, é responsável pela busca e
disponibilização dos OAs a partir do sistema loware; e

Gather: função concebida a partir do padrão OAI PMH, trata especificamente de manter
repositórios intermediários, que seriam repositórios que não armazenam OAs
propriamente, mas sim metadados de OAs provenientes de outros repositórios. A rede
LOP2P trata estes Repositórios Intermediários por incorporar os mesmos a todos os
peers, mantendo sempre uma listagem atualizada de metadados de OAs de outros
sistemas loware em todos os peers.
A iteração entre os componentes descritos fica clara na Figura 7, que representa um peer na
rede LOP2P.
29
Figura 7. Arquitetura da CM e integração com o sistema loware
Fonte: Santiago (2009)
2.3. Redes P2P
De acordo com Taylor e Harrison (2009), nos seus primórdios, uma rede P2P poderia ser
descrita como uma conversa ao telefone, na qual envolve duas pessoas de igual status, ou seja, uma
rede ponto-a-ponto entre dois participantes (peers) de igual importância. Atualmente, com o
advento de computadores pessoais e dispositivos móveis conectados a Internet, a criação e o uso de
redes P2P têm sido aplicados em diversos casos e situações ou condições específicas. Não há hoje
uma definição mundialmente aceita para redes P2P; muitos sistemas atuais, mesmo não tendo uma
relação exatamente igual entre seus peers, ainda são considerados P2P. No final da década de 90,
quando houve o grande crescimento de aplicações usando um modelo similar ao P2P, uma
definição foi proposta por Shirky (2000), segundo ele, P2P pode ser definido como uma classe de
aplicações que toma vantagem de recursos como storages, cycles, conteúdo, presença humana,
disponíveis em peers edge da Internet.
Segundo Taylor e Harrison (2009), o termo True P2P descreve a arquitetura ideal em uma
rede P2P, que emprega o uso de um design puramente descentralizado, onde todos os peers
30
participam de forma igual na rede, como cliente e servidor; como pode ser constatado pela
definição, uma aplicação totalmente P2P é algo muito difícil de ser implementado e pode não
necessariamente trazer os melhores resultados.
De acordo com Androutsellis-Theotokis e Spinellis (2004), podem-se classificar as redes
P2P no grau de centralização ao qual elas possuem:

Puramente descentralizadas: uma rede na qual todos os peers executam as mesmas
funções, agindo como servidores e clientes, não havendo uma coordenação centralizada
na rede. Redes True P2P encaixam-se nessa classificação;

Parcialmente
centralizadas:
alguns
peers
possuem
maior
importância
ou
responsabilidade que outros, tornando-os assim supernodes, que podem ser responsáveis
por manter em cache informações sobre outros peers; e

Hibridas: redes onde existem estruturas centrais que facilitem a interação entre os peers.
As redes P2P também podem ser classificadas de acordo com como a busca dentro de suas
redes é realizada:

Desestruturada: para se encontrar determinado recurso na rede, deve-se propagar uma
busca a todos os peers na rede;

Estruturada: onde existe um sistema central que é capaz de endereçar os peers na rede,
os peers então submetem a pesquisa a esse sistema central para localizar o recurso
especificado; e

Parcialmente estruturada: tentando unir as vantagens das duas abordagens anteriores,
define para os arquivos uma localização e uma rota.
2.3.1. Exemplos de Aplicações P2P
Muitos são os programas que fazem uso total ou de parte do conceito de P2P, sejam
programas de file sharing, computação distribuída, bate-papo. Nos tópicos a seguir serão
endereçadas características dos mais importantes e que mais contribuíram para o crescimento e a
popularização das redes P2P.
31
2.3.1.1.
Napster
Segundo Taylor e Harrison (2009), teve seu ápice no inicio dos anos 2000, mas perdeu o seu
uso e sua popularidade muito rapidamente. Ao fim de 2001 já havia perdido muitos usuários e
recebia varias ações judiciais por violação de copyrights, o que será discutido mais adiante. O
Napster compartilhava arquivos de música utilizando uma arquitetura mista, em que a busca por
arquivos e peers é feita em servidores centralizados, mas a transferência de arquivos entre os
usuários é feita diretamente entre eles.
Na Figura 8 é mostrada a primeira conexão de um usuário ao Napster, onde ele, User B, se
registra no servidor Napster.com, o servidor adiciona as suas músicas ao seu banco de dados e
fornece essas informações à usuários que requisitarem alguma música que User B possua.
Figura 8. Exemplo de uso da Aplicação Napster
Fonte: Taylor e Harrison (2009)
A Figura 6 também mostra uma busca originada por User A, onde o servidor Napster.com
acha o arquivo solicitado no peer User C e informa o User A da localização, que conecta ao User C
e inicia o download da música.
32
2.3.1.2.
Gnutella
Segundo a Free Software Foundation (2010), trata-se de um protocolo de distribuição de
arquivos, que teve varias implementações pelos mais variados clientes, como o LimeWire, que
utilizou um protocolo baseado na rede Gnutella, e o Morpheus, quando passou a utilizar o
Gnucleus, um software de código aberto compatível com o Gnutella. De acordo com Taylor e
Harrison (2009), pode ser considerado um True P2P, possui um sistema de busca e peers totalmente
descentralizado, onde as consultas são realizadas e propagadas pelos peers até que seja encontrado
o arquivo originalmente, tornando-se um problema visto que isso leva a um grande numero de
consultas pela rede e a busca não se torna muito otimizada, já que o arquivo solicitado pode estar no
ultimo peer a receber a consulta original.
Na Figura 9, o User A deseja se conectar a rede Gnutella, é utilizado então um GnuCache,
onde ele obtém o endereço de um peer, a partir deste, ele inicia uma descoberta de outro peers por
envio de pings a esse primeiro peer que responde a ele os peers próximos a ele. User A então inicia
a sua busca por determinado arquivo disparando a sua solicitação a todos os peers encontrados por
ele, o arquivo é encontrado em D e o download é iniciado em seguida.
Figura 9. Exemplo de uso da aplicação Gnutella
Fonte: Taylor e Harrison (2009)
33
2.3.1.3.
Kazaa
Um programa para compartilhamento de arquivos que utiliza o protocolo Fast Track. Criado
em 2001 pelos mesmos desenvolvedores do Skype, o protocolo Fast Track tem uma vantagem sobre
o Gnutella, pois utiliza supernodes, que são nós que mantem cache de grupos de usuários e
diminuem assim o gargalo que seria causado por uma pesquisa no estilo do protocolo Gnutella,
aumentando também a disponibilidade de recursos no protocolo (TAYLOR e HARRISON, 2009).
2.3.1.4.
Skype
Diferente de outros sistemas VoIP (Voz sobre IP), o Skype usa um sistema P2P para sua
comunicação, através do processamento em background de seu aplicativo, enquanto outros sistemas
VoIP necessitam um servidor para tal feito (TAYLOR e HARRISON, 2009). A tecnologia por traz
do Skype é closed source, então são poucos os detalhes técnicos divulgados sobre.
2.3.1.5.
BitTorrent
Criado por Bram Cohen, teve sua primeira versão apresentada em 2002 e desde então, de
acordo com a revista Wired (2007), obteve o posto de uma das maiores ferramentas de
compartilhamento de arquivos da Internet. Com o sucesso gerado, Cohen fundou a BitTorrent Inc.
em Setembro de 2004, detentora da marca, que inclui o protocolo e a aplicação BitTorrent e
µTorrent, que utilizam o protocolo.
Protocolo utilizado para a distribuição de arquivos, segundo Taylor e Harrison (2009), os
dois principais conceitos introduzidos pelo protocolo BitTorrent são:

Integração com a Web na busca por arquivos: a busca por arquivos é realizada através de
webservers comuns que podem ser vistos como repositórios de metadados. Fica a
encargo destes organizar e prover ao usuário final a melhor forma de pesquisar por
arquivos .torrent, arquivos estes que serão descritos em seguida; e

File Swarming: conceito qual não havia nos demais protocolos criados até o momento, o
file swarming possibilita que, uma vez que o usuário começou a baixar determinado
arquivo, parte desse arquivo já se torna disponível aos demais peers interessados no
mesmo arquivo. Esse comportamento adotado pelo protocolo foi essencial para que o
mesmo tivesse a aceitação e a popularidade que possui hoje.
34
Taylor e Harrison (2009) definem também os componentes e terminologias utilizadas em
uma rede BitTorrent:

Arquivos .torrent: trata-se de um arquivo de metadados com informações sobre o
arquivo que o usuário está interessado, informações como localização do Tracker,
quantidade de pedaços que formam o arquivo inteiro, nome do arquivo. São distribuídos
e organizados em webservers, para que o usuário faça a pesquisa através do mesmo e
faça o download desse arquivo metadado. Uma vez em posse desse arquivo, ele é aberto
com o cliente BitTorrent do usuário e o mesmo carrega as informações e procura o
Tracker especificado pelo arquivo para iniciar o download;

Swarm: é o grupo de peers interessados em um determinado arquivo, especificado pelo
arquivo .torrent;

Tracker: é o servidor responsável por manter informações sobre todos os usuários que
formam um swarm de um determinado arquivo .torrent. Conforme peers entram e saem
da rede, o Tracker mantem uma lista de peers ativos e interessados no arquivo. Trackers
recebem informações de cada peer em seus swarms contendo estatísticas sobre a
quantidade de download e upload efetuada até o momento, característica essa muito
importante, pois é dessa forma que o Tracker consegue efetuar o controle tit-for-tat;

Tit-for-tat: do inglês olho-por-olho, forma qual o Tracker faz o controle de prioridades
para os seus peers, baseado em informações estatísticas que o mesmo recebe. Cada peer
possui uma proporção (ou ratio) que deve manter, definida pelo Tracker, que geralmente
é em torno de um para um. Ou seja, um peer que tenha feito um download de 5mb deve,
por sua vez, fazer o upload desse arquivo em sua totalidade, para que o Tracker possa
liberar o acesso desse peer a mais peers que ele controla, aumentando assim a
velocidade de download desse peer para solicitações futuras. Desta maneira o protocolo
BitTorrent consegue eliminar os usuários que não contribuem com o upload de
determinado arquivo, impedindo que o mesmo consiga continuar fazendo downloads
sem contribuir para o seu swarm;

Seed:é o peer que possui uma copia inteira do arquivo em que o swarm está interessado.
Tanto pode ser o peer que originou o arquivo .torrent quanto usuários que conseguem
35
terminar seus respectivos downloads, eles continuam como seeds para que outros peers
possam completar seus downloads; e

Choked: estado qual um peer não deseja fazer upload de informações no presente
momento, uma dos momentos que isto pode acontecer é quando um peer possui
conexões demais.
Na Figura 10, o seed Ian faz o upload de um arquivo .torrent a um determinado website que,
em seguida, já se torna disponível para download por outros peers. Um usuário então faz o
download do .torrent no website que Ian o armazenou e abre o mesmo com o seu Cliente
BitTorrent, que, por sua vez, contata o Tracker especificado no arquivo .torrent e recebe os
endereços de peers interessados no mesmo arquivo. Esse usuário então se conecta aos outros peers
e inicia o download de pedaços do arquivo que lhe são necessários:
Figura 10. Exemplo de uso da Aplicação BitTorrent
Fonte: Taylor e Harrison (2009)
36
O estudo do BitTorrent é de suma importância, pois a mudança qual este trabalho propõe à
rede LOP2P é fundamentada com base nos princípios detalhados nesta subseção, como os conceitos
de file swarming e segmentação de arquivos. O estudo dos mesmos possibilita um maior
entendimento sobre a motivação para a alteração no comportamento da rede LOP2P.
2.3.1.6.
Comparativo entre as aplicações P2P
Na Tabela 2, é elaborado um comparativo com as aplicações P2P que são abordadas neste
trabalho:
Tabela 2. Comparativo entre as aplicações P2P
Napster
Gnutella
Kazaa
Arquivos em
Compartilhamento Músicas
Músicas
geral
Skype
BitTorrent
Voz,
Texto, Arquivos em
Bate-papo
Geral
Parcialmente
Estruturada Desestruturada Desestruturada Estruturada
Estruturada
Puramente
Parcialmente
Puramente
Hibrida
Hibrida
Descentralizada Centralizada
Descentralizada
Não
Sim
Não
Não
Não
Busca
Centralização
True P2P
Envio
Arquivos
Blocos
pedaços)
de
por
(ou
Não
Não
Não
Não
Sim
2.3.2. Impactos Sociais das Tecnologias P2P
Os impactos sociais causados pela tecnologia P2P são muitos. Processos judiciais, ações de
grandes corporações contra usuários, enfim, o novo modo de compartilhar arquivos e outras
informações abriu portas para varias outras questões além das de cunho tecnológico. Autores como
Rainsford (2003) e Drahos e Braithwaite (2003) usam o termo Feudalismo na Informação,
originado da seguinte colocação de Drahos e Braithwaite (2003);
O atual impulso pelo controle do direito a propriedade intelectual cresceu a
uma situação análoga a de um sistema feudal no período medieval. Em
resumo, compositores e cientistas trabalham para os senhores feudais
corporativos, licenciando suas próprias invenções em troca de um espaço e
do direito de ‘cultivar a terra’ da sociedade da informação.
Drahos e Braithwaite (2003) citam a troca de espaço com os senhores feudais e a concessão
ao direito de “cultivar a terra” como analogia a relação que hoje desenvolvedores tem com grandes
37
corporações, que cedem apenas o espaço necessário para os mesmo trabalharem na tecnologia,
música, ciência, mas que os resultados sejam em prol da empresa, gerando lucros e propriedade
intelectual para as grandes corporações. Já outros autores como Rimmer (2003) levantam
argumentos de que se as alegações dos usuários P2P é de que estão apoiando a liberdade de
expressão e contribuindo para o conhecimento, então eles têm que realmente faze-lo; o que Rimmer
quer dizer com isso é que o P2P não está mantendo as expectativas de uma tecnologia
revolucionária na distribuição de arquivos como foi concebida, e que seu uso seria mais bem visto
por grandes corporações se não fossem a grande quantidade de material com infrações de copyright
que são distribuídos nas mais conhecidas redes de P2P.
2.4. Framework JXTA
Segundo Taylor e Harrison (2009), devido à quantidade de projetos e a maturidade que as
aplicações P2P atingiram atualmente, percebe-se que essas aplicações possuem um conjunto em
comum de necessidades especificas a serem tratadas e implementadas por seus desenvolvedores.
Com essa afirmação em mente, foi criado pela Sun Microsystems o framework JXTA, que vem do
termo juxtapose, que em português significa lado a lado.
O framework JXTA é um projeto open source que define um conjunto padrão de protocolos
XML, desenvolvidos para resolver problemas de funcionalidade comuns em redes P2P,
possibilitando que peers possam formar redes dinâmicas, independentes de seu sistema operacional
e linguagem de programação. De acordo com Flenner et al.(2002), o framework JXTA habilita o
desenvolvedor a delegar todo o trabalho mais complexo da criação de uma aplicação P2P ao JXTA,
para que o foco do mesmo seja em trabalhar no que deixa a sua aplicação única entre as demais.
Os três principais objetivos a serem atingidos quando fora desenvolvido o framework JXTA
eram:

Interoperabilidade: aplicações P2P atuais são desenvolvidas com um único tipo de
serviço a disponibilizar, sendo elas o Napster para compartilhamento de músicas, o
Gnutella para compartilhamento descentralizado de arquivos, Skype para bate-papo; o
resultado disso é de que os desenvolvedores de aplicações P2P tendem a criar códigos
específicos para estes serviços, resultando na falta de interoperabilidade e na duplicação
de código desnecessária. O framework JXTA cria uma linguagem comum para que os
peers possam se comunicar;
38

Independência de Linguagem/Plataformas: por usar protocolos definidos em uma
representação textual como o XML, o JXTA consegue atingir um alto nível de
independência de fatores como linguagem de programação, sistemas operacionais e até
métodos de transporte como TCP/IP e Bluetooth; e

Ubiquidade: o JXTA foi desenvolvido para funcionar em quaisquer dispositivos por
mais limitados ou incompatíveis que sejam. Aparelhos como PDAs, celulares, storages,
servidores podem ingressar em uma rede JXTA.
Segundo Flenner et al.(2002), a estrutura do framework pode ser dividida em três camadas,
como podemos ver na Figura 11. São elas: (i) núcleo, ou JXTA Core; (ii) serviços, ou JXTA
Services; e (iii) aplicações, ou JXTA Applications.
Figura 11. Camadas do framework JXTA
Fonte: Flenner et al.(2002)

Núcleo (JXTA Core): é responsável pelos protocolos e pelas funções básicas para
habilitar uma rede P2P. Inclui descoberta, transporte, segurança e criação de peers ou
grupos de peers.

Serviços (JXTA Services): a camada de serviços provê funções mais genéricas que são
usadas em diversas aplicações P2P, mas não necessariamente em todas, sendo elas
autenticação de peers, indexação, distribuição de arquivos.
39

Aplicações (JXTA Applications): camada voltada para o suporte de aplicações
desenvolvidas, sejam elas para distribuição de arquivos, bate-papo.
Foram definidos seis protocolos pelo JXTA (TAYLOR e HARRISON, 2009), sendo eles:

PRP (Peer Resolver Protocol): o mecanismo pelo qual o peer realiza uma consulta para
outros peers e recebe sua resposta;

PDP (Peer Discovery Protocol): mecanismo qual o peer pode publicar os seus recursos e
descobrir novos recursos de outros;

PIP (Peer Information Protocol): onde peers podem obter informações sobre outros
peers, como estado, tempo ativo, tráfego;

PBP (Pipe Binding Protocol): possibilita a conexão de pipes entre peers;

ERP (Endpoint Routing Protocol): faz o roteamento das mensagens JXTA; e

RVP (Rendezvous Protocol): mecanismo qual permite que peers possam submeter ou
subemeter outros peers à propagação de determinado serviço.
Taylor e Harrison (2009) definem os peers JXTA como diferenciados entre si por um
identificador Peer ID, combinado com o seu próprio endereço na rede e o nome do peer, torna
impossível a replicação de um peer na mesma rede, tanto mais em todas as possíveis redes.
Peers podem tornar disponíveis para uso do protocolo JXTA uma ou mais interfaces de seus
dispositivos ou seus recursos disponíveis através de advertisements, que são mensagens
estruturadas no padrão XML que são passados pela rede através de datagramas (mensagens).
Essas mensagens são enviadas aos demais peers através de pipes, sendo eles um método de
transferência assíncrono e unidirecional, podendo suportar a transferência de qualquer objeto, como
um código binário ou uma string de dados. Pipes não são necessariamente uma conexão entre peers
com uma ligação direta entre si. O cenário na Figura 12 ilustra a possibilidade de haver outros
dispositivos interligando peers (no caso de peer 1 e peer 2 temos um firewall e um servidor entre
eles):
40
Figura 12. Pipes e intermediários entre peers
Podemos chamar cada um, desde o firewall ao servidor entre o caminho de peer 1 e peer 2,
de hop, que podem ser descritos como os intermediários que são necessários para se entregar uma
mensagem de um ponto a outro (TAYLOR; HARRISON, 2009). Existem dois tipos de pipes, o (i)
ponto-a-ponto, que liga somente dois peers, um enviando e outro recebendo mensagens e o de (ii)
propagação, em que um peer é responsável por enviar a mensagem a mais de um peer.
Os grupos de peers JXTA são definidos com base em peers que são capazes de conversar
com o mesmo conjunto de protocolos, formando uma coleção de peers que colaboram para prover
um conjunto em comum de serviços (pode-se visualizar um grupo de peers na Figura 13).
41
Para compensar a falta de um servidor central em uma rede JXTA, peers comuns podem ser
nomeados à Rendezvous nodes. Estes agem como um ponto de encontro entre grupos de peers
JXTA, mantendo informações sobre outros peers comuns e também sobre outros Rendezvous nodes,
podendo ser vistos como gateways para vários grupos de peers, conforme a Figura 13.
Figura 13. Grupos de peers e Rendezvous nodes
Fonte: Taylor e Harrison (2009)
Outro tipo de peers são os Relay, utilizados para rotear messages entre peers atrás de
firewalls, caso o mesmo esteja bloqueando mensagens entre peers tentando uma comunicação.
Sendo um projeto de código livre, o JXTA possui uma comunidade Java bastante ativa e
conta com suporte de outros usuários, e-books ajudando em sua programação e novos protocolos
para endereçar a situações mais especificas do uso do JXTA. No tópico a seguir será falado de um
protocolo promissor baseado no JXTA, o JxtaCast.
2.4.1. JxtaCast
42
Criado pelo usuário slowhog do fórum JXTA, suportado e mantido pela comunidade Java, o
JxtaCast é um protocolo para transmissão de mensagens utilizado para distribuir arquivos aos
membros de um grupo de peers, é necessário que os mesmos estejam rodando uma mesma
aplicação que faça uso do protocolo (CLARK, 2003).
Segundo Clark (2003), o diferencial que o protocolo JxtaCast traz ao projeto JXTA original
é que, com o uso do JxtaCast, é feita uma divisão em blocos dos arquivos enviados aos peers, onde
estes blocos são colocados em mensagens e são enviados através de pipes propagate. Os peers que
recebem os blocos enviados ficam encarregados de remontar o arquivo original a partir destes
blocos. Caso haja uma perca de blocos durante a transmissão de um peer a outro, os peers são
capazes de negociar quais os blocos faltantes e os mesmo são enviados novamente. A divisão por
blocos é feita por vetores de bytes que armazenam o arquivo a ser transmitido, dividem-no em
blocos de bytes e então estes blocos são colocados em mensagens, que são enviados ao requisitante.
São implementadas pelo protocolo cinco tipos de mensagens (CLARK, 2003), sendo elas:

FILE: mensagem contendo um bloco do arquivo a ser enviado e informações sobre o
mesmo;

FILE ACKNOWLEDGE: mensagem enviada pelo peer destinatário ao peer remetente,
avisando-o do recebimento com sucesso do bloco requisitado;

FILE REQUEST: mensagem contendo a requisição de um arquivo OA ou determinado
bloco de arquivo;

FILE REQUEST RESPONSE: mensagem resposta da requisição, é idêntica a mensagem
FILE, mudando somente o campo de identificação da mensagem; e

CHAT: tipo de mensagem para troca de textos entre peers, bate-papo.
O protocolo JxtaCast ainda está em desenvolvimento, mas na sua versão atual, pode-se
utilizá-lo para uma transmissão de um arquivo de imagem de um peer a outro, constatando assim a
funcionalidade do protocolo (CLARK, 2003).
Para o trabalho proposto, o protocolo JxtaCast é um passo importante dado rumo ao
comportamento BitTorrent. Conforme será discutido adiante no Capitulo 3, as definições das
mensagens JxtaCast serão parte importante deste trabalho, visto que será necessário somente
43
adaptá-las para a situação especifica no qual este trabalho se aplica, que é a necessidade de receber
arquivos de vários peers e montá-los, tendo de manter a integridade dos blocos durante o
recebimento.
44
3. DESENVOLVIMENTO
Neste capitulo é documentado o desenvolvimento do projeto proposto por esse TCC, a
mudança de comportamento proposta à arquitetura LOP2P. Neste capitulo também é discutido o
problema encontrado com o protocolo JxtaCast em detalhes, a razão de o mesmo não ter sido
utilizado e como foi possível a implementação sem o mesmo. Foram levados em consideração os
objetivos previamente definidos, definição de escopo e são utilizados diagramas de sequência e
diagramas de classe para melhor entendimento do produto final. Ao final deste capítulo, são
descritos os experimentos realizados com o comportamento BitTorrent e os resultados obtidos.
3.1.
Comportamento BitTorrent
Conforme visto na Seção 2.3.2.5, o conceito de file swarming proposto pelo protocolo
BitTorrent foi algo que o diferenciou dos demais protocolos antecessores de P2P. O estudo
realizado a partir do protocolo viabilizou a idéia de um conceito similar, aplicado a uma arquitetura
existente e voltada à distribuição de OAs, no caso o LOP2P. O novo comportamento proposto para
a arquitetura LOP2P tem em comum com o conceito de file swarming o fato de, no caso do novo
comportamento, realizar a quebra dos arquivos OAs a serem transmitidos em blocos de tamanhos
pré-definidos e enviados ao grupo de interesse em tal arquivo, de acordo com os blocos requisitados
por tais peers dentro do grupo.
Para a implementação de tal comportamento, o estudo sobre o framework JXTA foi
essencial para que fosse possível tanto o melhor entendimento sobre tecnologias P2P quanto sobre
como tal comportamento poderia ser implementado utilizando um framework.
3.1.1. Divisão por blocos dos arquivos de OAs
No novo comportamento BitTorrent, os OAs são transformados em blocos por uma função
que carrega determinado arquivo em um vetor de bytes na memória e cria blocos, salvando-os em
uma pasta com a ID do OA em questão, possuindo cada um deles o nome de quadro.
Tal função age da seguinte forma: com um tamanho para os blocos pré-definido em 512
Kbytes, ela recebe um arquivo e calcula o seu tamanho. Com esse tamanho, ela divide o arquivo em
blocos, sendo o ultimo o bloco com tamanho variável dependendo do tamanho do arquivo, e
45
armazena o bloco a ser enviado em um arquivo denominado “quadro”, o qual então é anexado à
mensagem e encaminhado para envio.
A diferenciação destes blocos é feita através do nome do arquivo, que marca o ultimo byte
que aquele quadro possui, ex: quadro.512, quadro.1024. Na Figura 14, o OA de 1536Kbytes sendo
lido em pedaços de 512Kbytes e estes pedaços sendo armazenados em arquivos menores,
denominados a partir do ultimo valor lido.
Figura 14. Divisão do arquivo em blocos
O peer que recebe a mensagem, no final da transmissão, armazena o bloco recebido na pasta
com a ID do OA ao qual este pertence. Mesmo que blocos cheguem fora de ordem, estes blocos são
46
armazenados na pasta do peer requisitante com nomes distintos, não interferindo na montagem final
do arquivo posteriormente.
O fato de estes blocos serem mantidos em posições referentes aos seus números definidos
com base em um tamanho pré-definido possibilita não só o recebimento de blocos fora de ordem,
que outrora seriam descartados, mas também o envio de blocos recebidos por parte destes peers que
ainda não completaram os seus downloads, uma vez que estes peers podem responder pedidos de
blocos de arquivo que já os tenham.
São quatro os tipos de mensagens e suas requisições que os peers com comportamento
BitTorrent suportam, sendo estas baseadas nas mensagens já utilizadas pelo LOP2P.
3.1.2. Tipos de mensagens
Os quatro tipos de mensagens e requisições enviadas e recebidas por peers no novo
comportamento são:

TORRENT_DOWNLOAD: mensagem enviada pelo peer requisitante contendo a
identificação do bloco de arquivo solicitado para download;

TORRENT_UPLOAD: mensagem enviada pelo peer destinatário ao peer requisitante,
contendo o bloco solicitado;

TORRENT_REQUEST: mensagem enviada pelo peer requisitante contendo a requisição
de quais blocos o peer destinatário possui de determinado OA; e

TORRENT_SUBMIT: mensagem enviada pelo peer destinatário, informando ao peer
requisitante quantos blocos o mesmo possui.
3.1.2.1. Mensagem TORRENT_DOWNLOAD
A mensagem que armazena o bloco requisitado (TORRENT_DOWNLOAD) é estruturada
da seguinte forma:

Identificação do tipo da Mensagem: denominada TORRENT_DOWNLOAD;

ID do peer remetente: ID único do peer remetente, definido pelo protocolo JXTA;
47

ID do peer destinatário: ID único do peer destinatário, definido pelo protocolo JXTA;

Chave única: uma chave única identificando a transmissão da mensagem;

Nome do arquivo: não contemplando o seu caminho dentro do peer, somente o nome do
arquivo a ser transmitido; e

Bloco requisitado: somente identificação do bloco requisitado;
3.1.2.2. Mensagem TORRENT_UPLOAD
Mensagem enviada pelo peer destinatário ao peer requisitante contendo o bloco solicitado
na mensagem anterior (TORRENT_DOWNLOAD). A mensagem é estruturada da seguinte forma:

Identificação do tipo da Mensagem: denominada TORRENT_UPLOAD;

ID do peer remetente: ID único do peer remetente, definido pelo protocolo JXTA;

ID do peer destinatário: ID único do peer destinatário, definido pelo protocolo JXTA

Chave única: uma chave única identificando a transmissão da mensagem;

Nome do arquivo: não contemplando o seu caminho dentro do peer, somente o nome do
arquivo a ser transmitido; e

Bloco
requisitado:
a
partir
da
identificação
do
bloco
recebida
(TORRENT_DOWNLOAD), o mesmo é anexado a mensagem e enviado;
3.1.2.3. Mensagem TORRENT_REQUEST
Mensagem enviada pelo peer requisitante à todos os peers conhecidos, solicitando
informações sobre a quantidade de blocos que os mesmos possuem. Esta mensagem é enviada no
momento que o peer requisitante fez a busca, encontrou o OA que deseja e solicitou o download. A
mensagem é estruturada da seguinte forma:
48

Identificação do tipo da mensagem: denominada TORRENT_REQUEST;

ID do peer remetente: ID único do peer remetente, definido pelo protocolo JXTA;

ID do peer destinatário: ID único do peer destinatário, definido pelo protocolo JXTA

Chave única: uma chave única identificando a transmissão da mensagem; e

Metadado do OA solicitado: metadado de posse do peer remetente, contendo uma
contagem de blocos nula referente ao mesmo, identificando o OA ao qual o peer
requisitante deseja informações;
3.1.2.4. Mensagem TORRENT_SUBMIT
Mensagem
enviada
pelo
peer
destinatário,
informando
ao
peer
requisitante
(TORRENT_REQUEST) a quantidade de blocos que o mesmo possui. A mensagem é
estruturada da seguinte forma:

Identificação do tipo da mensagem: denominada TORRENT_SUBMIT;

ID do peer remetente: ID único do peer remetente, definido pelo protocolo JXTA;

ID do peer destinatário: ID único do peer destinatário, definido pelo protocolo JXTA

Chave única: uma chave única identificando a transmissão da mensagem; e

Metadado do OA solicitado: metadado de posse do peer contendo a quantidade de
blocos qual o mesmo possui, identificando também o OA qual o peer requisitante
solicitou informações;
3.1.2.5. Uso das mensagens
A melhor compreensão do uso das mensagens pode ser alcançada visualizando a Figura 15,
que mostra as mensagens sendo trocadas entre os peers, que são universidades fazendo a troca de
OAs.
49
O protocolo para o envio das mensagens entre os peers deve funcionar da seguinte forma; o
peer interessado faz a busca por um determinado OA, encontrado o objeto desejado, é feito a
solicitação de download. Após esta solicitação de download se dá inicio o a mudança de
comportamento proposta; são enviados então TORRENT_REQUEST para os peers conhecidos, em
busca de peers que possuam blocos do OA desejado, mesmo que não possuam todos os blocos do
mesmo. Recebido os blocos pertencentes aos peers através do TORRENT_SUBMIT, o peer
requisitante
inicia
o
processo
de
download
dos
blocos,
enviando
solicitações
TORRENT_DOWNLOAD e esperando-as em TORRENT_UPLOAD, não importando a ordem quais
estes blocos são recebidos, verificando assim o recebimento de todos os blocos necessários e, ao
final, montando-os em um arquivo único para o peer requisitante.
Figura 15. Uso das mensagens entre os peers
50
3.1.3. Comunicação entre peers
São usados pipes JXTA para a comunicação entre os peers. Conforme visto na Subseção
2.4, eles são responsáveis pela comunicação entre peers. Foi usado somente um tipo de pipe para o
projeto, o pipe ponto-a-ponto.
O
pipe
ponto-a-ponto
é
usado
para
as
mensagens
TORRENT_DOWNLOAD,
TORRENT_UPLOAD, TORRENT_REQUEST e TORRENT_SUBMIT. Todas as solicitações devem
ser atendidas ponto-a-ponto, nunca envolvendo broadcast entre todo um grupo JXTA.
3.1.4. Interação entre os peers e suas camadas
Na Figura 16, temos um diagrama de sequência detalhando um exemplo de uma interação
entre os peers dentro da rede LOP2P com o comportamento BitTorrent já adaptado e as interações
das camadas dentro destes peers. O exemplo ilustra a transferência de um OA contando com três
participantes, um requisitante e dois fornecedores do arquivo em questão.
Figura 16. Diagrama de sequência com a Interação entre os peers e suas Camadas de Mediação
51
3.2.
Analise do código-fonte LOP2P anterior
A partir do código-fonte da arquitetura LOP2P anterior, fez-se um processo de engenharia
reversa utilizando a ferramenta EA (Enterprise Architect). Deste modo, retornou-se as classes
utilizadas para a implementação do projeto e suas iterações. Foi possível notar o uso de funções do
padrão IMS DRI estudadas, como Search/Expose, Request/Deliver e Submit/Store.
Na Figura 17, pode-se observar parte do pacote Network Communication Device, onde se
encontram as classes implementadas utilizando o framework JXTA. Pode-se visualizar as seguintes
classes na parte selecionada, sendo elas responsáveis pela construção e pelo envio da mensagem:

NCDConfiguration: responsável por fornecer a estrutura necessária para configuração de
todas as classes pertencentes ao pacote Network Communication Device. Abriga
informações de configuração do peer na rede e é responsável também por nomear as
mensagens requisitadas pelo sistema loware à CM e consequentemente, a rede LOP2P;

NCDMessageSender: esta classe é encarregada de realizar o envio das mensagens,
provenientes de uma fila de mensagens que a arquitetura mantêm, onde são abrigadas
mensagens a serem despachadas aos peers. Podem-se ser visualizados também os tipos
de mensagens e seus respectivos nomes; e

LOP2PMessage: classe onde são originadas as mensagens que serão enviadas a outros
peers. Nesta mensagem são armazenados os OAs aos quais a arquitetura LOP2P
distribui e então enviadas aos peers solicitantes.
52
Figura 17. Engenharia reversa do código-fonte LOP2P, pacote Network Communication Device –
envio de mensagens.
Na Figura 18 é selecionada outra parte do pacote Network Communication Device, esta
sendo responsável pelo recebimento e tratamento posterior das mensagens. Podem-se visualizar
principalmente as seguintes classes na parte selecionada:

NCDConfiguration: mencionado anteriormente, abriga informações de configuração do
peer na rede;

NCDMessageReceiver: é responsável por receber as mensagens e armazená-las assim
que chegam em uma lista de mensagens a serem lidas; e

NCDMessagesReceiverVerifier: após o recebimento das mensagens, essa classe é
responsável por tratar as mensagens.
53
Figura 18. Engenharia reversa do código-fonte LOP2P, pacote Network Communication Device recebimento de mensagens.
A seguir são discutidas as mudanças realizadas à arquitetura LOP2P.
3.3. Mudanças do comportamento BitTorrent aplicadas ao LOP2P
Neste subtópico são discutidas as mudanças aplicadas à arquitetura LOP2P, discutindo a
implementação através de figuras e diagramas de classe.
3.3.1. JxtaCast
Durante os estudos e testes com o protocolo JxtaCast, implementando pequenas aplicações e
verificando seu funcionamento mais detalhadamente, pode-se notar que a mesma não se adaptaria
da melhor forma ao novo comportamento BitTorrent do LOP2P. O protocolo propõe um obrigatório
broadcast de mensagens, forçando desta forma que todos os peers do grupo venham a obter o
arquivo que esteja em questão, não sendo este o foco do LOP2P. É de entendimento deste que o
protocolo, que vinha sendo mantido por somente um usuário, está vindo a ser descontinuado, não
54
sendo oferecido qualquer tipo de suporte, conclusão tirada visto o fato de que não foram mais
encontradas noticias sobre o protocolo na internet e a pagina do mesmo não está mais disponível.
Mesmo diante destes problemas, medidas alternativas foram tomadas tentando ainda a
utilização do protocolo, mas não foi possível nenhuma forma que, em tempo hábil, fosse possível
aplicar o protocolo mantendo os princípios propostos, mantendo ainda a coerência no modelo de
classes.
Em função dos problemas relatados, foi decidido não utilizar o protocolo JxtaCast. Desta
forma, toda a codificação, segmentação de arquivos, tratamento de mensagens, tratamento e junção
dos blocos teve de ser feita sem auxilio do mesmo.
3.3.2. Alterações no código
As classes que abrigaram novo código para a implementação do comportamento BitTorrent
foram:

LOP2PMessage: conforme já detalhada no subtópico 3.2, é a classe aonde são
originadas as mensagens que são enviadas aos peers. Nesta classe, foram adicionadas as
mensagens propostas pelo novo comportamento, são elas TORRENT_DOWNLOAD,
TORRENT_UPLOAD, TORRENT_REQUEST e TORRENT_SUBMIT;

GDGather: classe responsável por receber a solicitações do loware de publicar um
determinado OA. Foi necessária a modificação nesta classe a fim de, quando o OA é
publicado, além de todo o processo de criação do metadado, é necessário neste momento
que, a classe seja capaz de segmentar o OA e armazenar os blocos referentes à mesma na
pasta designada. É necessário agora também que, no metadado, seja identificado quantos
blocos este OA terá;

LOP2PMetadata: classe aonde são originados os metadados referentes aos OAs que são
publicados na CM. Nesta classe foi necessário adicionar uma lista onde ficam guardadas
a quantidade de blocos que o OA referente possui, sendo criado também getters e setters
para atualizar a quantidade de blocos que determinado peer possui;

NCDData: classe responsável por possuir dados necessários para a configuração da
comunicação do peer entre os seus demais, possui também a lista de peers conhecidos
55
por este. Nesta, foi criada uma estrutura de listas aonde se abriga a quantidade de OAs
pesquisados pelo comportamento BitTorrent, quantos peers os têm e quantos blocos
cada um tem.

NCDMessagesReceiverVerifier: conforme já detalhado no subtópico 3.2, classe
responsável por tratar as mensagens quando recebidas. Foram adicionados nesta classe
os tratamentos para os novos tipos de mensagens; e

SuDSubmit: classe responsável pelas funções de download e upload dos OAs. Nesta,
foram alteradas as funções store, a fim de, quando uma solicitação de download seja
feita, seja chamada a classe SuDDownloadHandler, que será explicada a seguir. Foram
feitas também alterações no storeSubmit, que é responsável por receber a mensagem
TORRENT_DOWNLOAD, verificar o OA e, após modificação, o bloco que deve ser
enviado ao peer requisitante e envia-lo em sequência.
Foi necessária também a criação das seguintes classes:

SDTorrentRequest: possui a função search, que dispara buscas TORRENT_REQUEST
para os peers conhecidos, em busca de seus metadados solicitados e a quantidade de
blocos que os mesmo possuem, além da função searchExpose que envia o
TORRENT_SUBMIT ao peer requisitante contendo, no metadado solicitado, a
quantidade de blocos que possui;

SuDDownloadHandler: classe responsável por tratar de todo o processo de busca,
download e agrupamento dos blocos recebidos. A partir dela é chamada a função search
de SDTorrentRequest para a procura de blocos; são criadas threads SuDBitHandler, que
serão explicadas a seguir, para tratar do download de cada bloco e; agrupados os blocos,
montando o arquivo final; e

SuDBitHandler: classe, que extende thread, responsável por baixar cada bloco solicitado
pelo SuDDownloadHandler. Após o download, escreve no seu metadado que o
determinado bloco foi baixado com sucesso.
No diagrama de classes expresso na Figura 19, pode-se visualizar a interação entre as classes
do pacote protoSubmitDevice, contendo as novas classes SudDownloadHandler e SuDBitHandler,
além da SuDSubmit, que precisou de alterações, e a SuDConfiguration.
56
Figura 19. Diagrama de classes do pacote protoSubmitDevice
No diagrama de classes expresso na Figura 20, o pacote protoNetCommunicationDevice,
aonde estão as classes LOP2PMessage, NCDData e NCDMessageReceiverVerifier, que precisaram
ser alteradas conforme explicado anteriormente neste subtópico. Em conjunto a elas, no diagrama
também estão outras classes pertencentes ao pacote, para melhor visualização do resultado final.
57
58
Figura 20. Diagrama de classes do pacote protoNetCommunicationDevice
No diagrama de classes expresso na Figura 21, o pacote protoSearchDevice, onde se
encontra a classe SDTorrentRequest, criada por este projeto e mencionada neste subtópico.
Figura 21. Diagrama de classes do pacote protoSearchDevice
59
3.3.3. Segmentação e agrupamento dos OAs
Conforme discutido no subtópico 3.1.1, um aspecto crucial para que se possa ter um
comportamento BitTorrent, é a segmentação dos OAs; divindo-os em blocos para que, após
transmissão, possam ser agrupados, independente de suas origens diferentes, mas mantendo a
integridade quando o agrupamento tomar forma.
A classe GDGather, discutida no subtópico 3.1.2.1, é responsável pela publicação dos OAs
na CM e, após a mudança proposta por este projeto, pela segmentação dos OAs também. Ela atua
de forma que, quando o loware solicita a publicação de determinado OA na CM, a função
receiveMetadataFromLoware faz a publicação do OA na CM e aliado a isso, faz a segmentação do
OA, determinando também no seu metadado, a quantidade de blocos que o mesmo possui.
O processo de segmentação é iniciado calculando o tamanho do OA e com base nisso,
escreve em seu metadado quantos blocos este OA irá possuir. Inicia-se então a leitura do arquivo
em uma sequencia de bytes e a partir disto são criados novos arquivos que, com base na leitura
sequencial, são preenchidos com 512Kbytes do arquivo original, sendo o ultimo bloco com
tamanho variável. Estes arquivos são salvos em um diretório de caminho (./blocks/LOID/quadro.*),
onde LOID é o ID do OA e * é o numero final da sequencia de bytes que aquele bloco específico
possui.
Na Figura 22 podemos visualizar de forma mais detalhada o que acontece durante a
segmentação do OA.
60
Figura 22. Segmentação do OA, de forma detalhada
Quando o download dos blocos de determinado OA é finalizado, a classe
SuDDownloadHandler, após verificar que todos os blocos foram baixados, inicia o agrupamento
destes blocos.
O agrupamento é feito de forma similar à segmentação; um novo arquivo é instanciado e
salvo no diretório destino, após isto, a função começa a ler os quadros de forma sequencial e a
gravar os seus bytes no arquivo antes mencionado. Ao final da leitura e escrita, o arquivo é
finalizado, deixando o arquivo pronto para utilização do usuário.
Na Figura 23 podemos visualizar o agrupamento dos blocos de forma mais detalhada.
61
Figura 23. Agrupamento do OA, de forma detalhada
3.3.4. Busca por blocos
Após o processo comum de busca por OAs do LOP2P, quando o usuário seleciona o OA que
deseja fazer o download, é iniciada a busca por blocos, feita pela classe SDTorrentRequest, função
run, por este OA em peers conhecidos.
Uma vez que o peer tenha iniciado o download de um OA, o metadado respectivo a este já é
armazenado e passível de busca para os outros peers neste processo de procura por blocos, mesmo
que o peer possua alguns ou todos os blocos deste OA; caracterizando o file swarming discutido no
subtópico 3.1, visto que, mesmo que o peer em questão ainda esteja fazendo o download dos
blocos, ele pode fornecer estes que já possui a outros peers interessados.
62
Feita a busca por blocos e recebidos os resultados, a classe SuDDownloadHandler busca por
blocos contidos no próprio peer, referente a aquele OA, adicionando assim outra característica
mencionada no subtópico 3.1, o resumo de downloads inacabados.
A classe SuDDownloadHandler busca baixar um bloco de cada peer que foi encontrado na
busca anterior por blocos, se mesmo assim não sejam feitos os downloads de todos os blocos, é
selecionado um peer e feito o download do máximo de blocos que o mesmo possui, a fim de
completar a quantidade de blocos.
Na Figura 24 se pode ver um cenário com três peers LOP2P, onde peer A faz a busca pelo
OA X, que tem um total de três blocos, dos quais o mesmo já possui um bloco, resultado de um
download interrompido anteriormente.
Figura 24. Busca por blocos dentre os peers
63
3.4. Experimentos com o comportamento BitTorrent LOP2P
Nesta seção são discutidos os experimentos e seus resultados, que foram realizados para a
validação do projeto, estes divididos em duas etapas; os (i) testes em ambiente controlado e (ii)
testes em ambiente real. A definição das duas etapas:

Ambiente controlado: para os experimentos em ambiente controlado, foram necessários
somente quatro desktops, sendo eles maquinas virtuais com sistemas operacionais
Microsoft Windows XP ou Linux Fedora 14, com a instalação de um LMS e seu
repositório, no caso o MOODLE, em cada um deles. Foram feitos testes de requisição de
arquivos e fornecimentos de OA. Foram avaliados os clientes de cada peer e avaliados
também os pacotes trafegados pela LAN utilizando uma ferramenta especifica para
monitoramento destes pacotes trafegados. Um cenário de sucesso se dá no caso de todo o
grupo de peers conseguirem efetivamente trocar mensagens, receber os blocos enviados
de diversos peers dentro do grupo, verificar os blocos com sucesso e montar estes
arquivos de OA.

Ambiente real: Foram selecionados três servidores ativos de uma empresa X, localizada
na cidade de Itajaí, e um servidor caseiro, aos quais o autor deste projeto possui acesso,
para serem instalados o LMS e seu repositório em cada um deles. Estes servidores ficam
localizados atrás de vários hops1, incluindo firewalls e switches, os quais também são
fundamentais para a validação deste projeto. Foram então configurados estes peers para
a rede LOP2P com o novo comportamento BitTorrent e feitos testes de requisição e
fornecimento de OAs entre o grupo. Foram avaliados os resultados em cada peer. Um
cenário de sucesso no ambiente real é similar ao ambiente controlado, o mesmo se dá no
caso de o grupo conseguir encontrar a si mesmos na internet e o grupo poder ser
efetivamente criado, todo o grupo de peers conseguir trocar mensagens entre si, receber
os blocos enviados de diversos peers dentro do grupo, verificar os blocos com sucesso e
montar estes arquivos de OA.
1
Hops: intermediários que são necessários para se entregar uma mensagem de um ponto a outro, por exemplo,
firewalls, switches de rede e hubs.
64
Estas duas etapas foram realizadas após a mudança de comportamento BitTorrent proposta.
Para cada teste, foram relacionadas quatro características quais diferenciam os peers de seus
demais, são elas:

UID: Identificador único de cada peer, por se tratar de um número extenso, são
apresentados somente os quatro últimos dígitos de cada peer;

SO: é apresentado o sistema operacional utilizado para cada peer, levando em conta a
diversidade apropriada para o experimento;

IP: endereço IP do peer. Nos experimentos em ambiente controlado, são utilizados IPs
LAN, ou não válidos. Para os experimentos em ambiente real, são utilizados IPs WAN,
ou válidos; e

Blocos: quantidade de blocos que cada peer descrito possui no início de cada teste.
No subtópico a seguir, são detalhados os experimentos e expostos os resultados.
3.4.1. Resultados do ambiente controlado
Foram realizados dois testes em ambiente controlado, de acordo com o subtópico 3.4. Para o
primeiro teste, os computadores foram configurados da seguinte forma, expressa na Tabela 3.
Tabela 3. Dispositivos para o primeiro experimento em ambiente controlado
Nome
UID
LOP2Pb1
Final 2203
LOP2Pb2
Final DD03
SO
Fedora 14
Fedora 14
IP
192.168.174.150
192.168.174.149
Blocos 1(512) e
4(2048)
Blocos
Bloco 3(1536)
LOP2Pb4
LOP2Pb5
Final B203
Final EB03
Windows XP - Windows XP Professional
Professional
192.168.174.132
192.168.174.129
Nenhum
Todos
No diagrama de redes exposto na Figura 25, pode-se visualizar a estrutura descrita na Tabela
3.
65
Figura 25. Diagrama de redes para a infra-estrutura descrita na Tabela 3
Para este teste, foi utilizado como objeto de pesquisa um OA denominado Pilha, com o
tamanho de 1,68MB (ou 1.723 KB). Inicialmente, o LOP2Pb2 solicita os blocos dois e três para
finalizar o seu download, feito isso, o LOP2P 4 solicita blocos e faz download dos mesmos de todos
os peers na rede.
Na Figura 26, é mostrada a interface da CM, onde podemos visualizar os blocos recebidos.
O LOP2Pb2 fez o download com sucesso dos blocos que lhe faltavam, baixando um bloco de cada
peer presente na rede.
66
Figura 26. Camada de Mediação do peer LOP2Pb2
Na Figura 27, o LOP2Pb2, com todos os blocos referentes ao OA desejado, consegue juntar
os blocos e formar o arquivo original. A estrutura mantida no diretório /blocks é de o arquivo
original, depois de agrupado, em sua raiz e uma pasta nomeada com o ID do OA contendo os blocos
para envio aos peers requisitantes.
67
Figura 27. LOP2Pb2 após o agrupamento dos blocos e com o arquivo original aberto
Na Figura 28, o peer LOP2Pb4 fez a requisição de download de blocos e realiza o download
de todos, sendo um de cada peer que o possui e os agrupa, formando o arquivo original.
68
Figura 28. LOP2Pb4 realizando o download de todos os blocos e os agrupando
Em outro experimento em ambiente controlado, foram utilizados três computadores dentro
da rede LOP2P, são eles descritos na Tabela 4.
Tabela 4. Dispositivos para o segundo experimento em ambiente controlado
Nome
UID
LOP2Pb1
Final 9404
SO
Fedora 14
IP
Blocos
192.168.174.150
Nenhum
LOP2Pb4
Final 7703
Windows
XP
Professional
192.168.174.132
Nenhum
LOP2Pb5
Final 7903
– Windows
XP
Professional
192.168.174.129
Todos
-
No diagrama de redes exposto na Figura 29, pode-se visualizar a estrutura descrita na Tabela
4.
69
Figura 29. Diagrama de redes para a estrutura descrita na Tabela 4
Para este teste, foi utilizado como objeto de pesquisa um OA denominado Pilha, com o
tamanho de 21.9MB (ou 21.645KB). Inicialmente, o LOP2Pb4 solicita blocos para LOP2Pb5, após
a transferência com sucesso, os mesmos são agrupados e o arquivo aberto. LOP2Pb1 entra na rede e
baixa o OA a partir dos 2 peers. Após o download, o arquivo é agrupado e aberto novamente.
Na Figura 30, o peer LOP2Pb1 fez o download de blocos dos peers LOP2Pb5 e LOP2Pb4,
após isto, eles são agrupados e, na camada de mediação, podemos visualizar a mensagem de
agrupamento com sucesso.
70
Figura 30. LOP2Pb1 realiza o download de todos os blocos a partir de LOP2Pb4 e LOP2Pb5
3.4.2. Resultados em ambiente real
Foram realizados dois testes em ambiente real, de acordo com o subtópico 3.4. Para
ambos os testes, foram utilizados três servidores de uma empresa X e outro servidor montado. Nos
servidores da empresa X, LOP2Pb1 e LOP2Pb2 estavam ambos com endereços válidos na WAN,
mas no mesmo pool de endereços cedidos à empresa X, portanto, com comunicação direta entre
eles mas atrás de um firewall bridge para a internet. O LOP2Pb6, também localizado na empresa X,
estava na rede válida da Oi Telecom, atuando como peer relay para LOP2Pb5. O LOP2Pb5, por sua
vez, estava conectado à um serviço de ADSL domestica GVT, atrás de um firewall NAT.
Na Tabela 5, os servidores foram configurados da seguinte forma para estes experimentos.
71
Tabela 5. Dispositivos para o primeiro experimento em ambiente real
Nome
UID
LOP2Pb1
Final 4203
LOP2Pb2
Final 3403
SO
Fedora 14
Fedora 14
IP
187.44.99.73
187.44.99.72
Blocos
Nenhum
Nenhum
LOP2Pb5
LOP2Pb6
Final BD03
Final EE03
Windows XP Fedora 14
Professional
WAN: jorgelop2p.dyndns.org
200.215.80.164
LAN: 198.168.1.5
Todos
Nenhum
No diagrama de redes exposto na Figura 31, pode-se visualizar a estrutura descrita na tabela
5.
Figura 31. Diagrama de redes com a estrutura descrita na Tabela 5
No primeiro teste, foi utilizado um OA denominado Pilha, com o tamanho de 1,68MB (ou
1.723 KB), onde o peer LOP2Pb1 realiza a busca pelo OA desejado, faz o download dos blocos a
partir do peer LOP2Pb5 e agrupa os mesmos, possuindo então o arquivo completo e se tornando um
72
seed para os outros peers interessados no OA Pilha. Após isto, o peer LOP2Pb2 realiza o mesmo
processo e baixa os blocos tanto de LOP2Pb5 quanto de LOP2Pb1 e os agrupa, formando o arquivo
original. Por ultimo, LOP2Pb6 realiza o mesmo processo, realizando o download dos blocos a partir
dos três outros peers na rede.
Na Figura 32, o LOP2Pb6, com todos os blocos baixados, cada um a partir de um peer na
rede que agia como seed para o OA solicitado.
Figura 32. LOP2Pb6 após o download dos blocos
Foi realizado também, para o segundo experimento, a troca um OA denominado Pilha, com
o tamanho de 21.9MB (ou 21.645KB). Para este, foram utilizados somente três dos quatro
servidores utilizados anteriormente, conforme descritos na Tabela 6.
Tabela 6. Dispositivos para o segundo experimento em ambiente real
Nome
UID
SO
LOP2Pb1
Final 4203
Fedora 14
IP
187.44.99.73
Blocos
Nenhum
LOP2Pb5
Final 3403
Windows XP - Professional
WAN: jorgelop2p.dyndns.org
LAN: 198.168.1.5
Todos
73
LOP2Pb6
Final EE03
Fedora 14
200.215.80.164
Nenhum
No diagrama de redes exposto na Figura 33, pode-se visualizar a estrutura descrita na Tabela
6.
Figura 33. Diagrama de redes detalhando a estrutura descrita na tabela 6
Similar aos outros experimentos, LOP2Pb1 faz a solicitação do OA desejado ao peer
LOP2Pb5, faz o download e agrupa os blocos formando o arquivo original. Após isto, LOP2Pb6 faz
a pesquisa pelo mesmo OA e realiza o download a partir de LOP2Pb5 e LOP2Pb1.
74
4. CONSIDERAÇÕES FINAIS
Este trabalho apresentou uma mudança no comportamento da arquitetura LOP2P, que
compartilha objetos de aprendizagem entre peers, no caso, sistemas loware de instituições de
ensino. Antes deste projeto, a forma de compartilhamento destes objetos de aprendizagem não
dispunha ao peer escalabilidade ao fazer download de determinado arquivo. O mesmo deveria ser
baixado por completo de somente um peer, independente da carga de rede no momento do
download e tamanho do arquivo, estando suscetível a interrupções na transmissão.
A solução proposta se baseou em conceitos consolidados, aprovados e utilizados
diariamente em grande escala por usuários em todo mundo, presentes estes no protocolo BitTorrent.
Os conceitos que este projeto julgou necessário para criar um novo comportamento para a
arquitetura LOP2P, como o de file swarming, são características que a auxiliarão a suportar um
numero grande de instituições de ensino e se manter na vanguarda das tecnologias envolvendo
sistemas P2P.
Os objetivos definidos para este projeto concluídos com sucesso. O estudo feito sobre
Objetos de Aprendizagem, sistemas loware e redes de repositórios possibilitou o entendimento do
contexto ao qual o projeto fora aplicado, qual o ambiente que atuará e quais serão os tipos de
arquivos que devem ser compartilhados. Foi feito também um estudo da documentação da
arquitetura LOP2P, visando entender como a mesma funciona, camadas e modelos utilizados para a
sua implementação foram estudados a fundo. O conhecimento sobre outras redes de repositórios
aliado com o estudo realizado sobre o LOP2P foi importante para avaliar a situação atual de todas
as soluções e traçar um comparativo entre o LOP2P e alternativas existentes.
A pesquisa por redes peer-to-peer e pelo protocolo BitTorrent, auxiliou na construção da
Fundamentação Teórica e na base de conhecimento necessário para desenvolvimento do projeto
final. Aliado ao estudo realizado sobre o framework JXTA, foi possível projetar e implementar o
comportamento BitTorrent proposto.
Houveram problemas com o protocolo JxtaCast, discutido em sua grande parte na
Fundamentação Teorica, mas embora tenha sido um contratempo, a solução encontrada, de
implementar a funcionalidades sem a ajuda do mesmo, funcionou de forma melhor do que se previa
na primeira etapa do projeto.
75
Com a falta do protocolo JxtaCast, foi necessário implementar as mensagens necessárias e o
controle de envio e recebimento destas desde o início, utilizando o framework JXTA e mensagens
utilizadas anteriormente pela arquitetura LOP2P. Toda a segmentação dos OAs em blocos e o
agrupamento dos mesmos tiveram de ser feito do inicio também, o que atrasou pouco o
desenvolvimento, mas resultou em um código mais apropriado para as necessidades do
comportamento proposto.
Os objetivos definidos para o sucesso nos experimentos realizados foram cumpridos, foram
feitos experimentos com sistemas operacionais diversos, variados tipos de estruturas de rede, foi
alterado o tamanho dos arquivos, resultando em maior quantidade de blocos. Todos estes tiveram os
resultados esperados e foram documentados de forma extensa, gerando material para análise
detalhada.
O LOP2P possui um alto potencial para crescimento, tanto no quesito de reconhecimento,
com a sua adoção e utilização em diversas instituições de ensino, compartilhando seus OAs no
estado-da-arte se tratando de redes P2P, quanto no quesito cientifico e tecnológico. Para trabalhos
futuros envolvendo o comportamento BitTorrent implementado ao LOP2P, posso citar; (i)
implementação de maiores funcionalidades relacionadas ao novo comportamento BitTorrent no
plugin loware, como o maior controle do usuário quanto aos blocos a serem baixados, velocidade e
status de downloads e uploads e (ii) utilização de técnicas de otimização para o download de
blocos, levando em conta aspectos de rede como proximidade, resposta e latência de peers.
76
REFERÊNCIAS BIBLIOGRÁFICAS
ARIADNE. The ARIADNE Knowledge Pool System. 2006. Disponível em: <http://www.ariadneeu.org/index.php?option=com_content&task=view&id=27&Itemid=38 >. Acesso em: 10 set. 2010.
ANDROUTSELLIS-THEOTOKIS, Stephanos; SPINELLIS, Diomidis. A Survey of Peer-to-Peer
Content Distribution Technologies. ACM Computing Surveys, New York, v.36, p.335-371, 2004.
ISSN: 0360-0300
CLARK, J. JxtaCast: Broadcast files through propagation pipes. 2003. Disponível em:
<https://jxtacast.dev.java.net/>. Acesso em: 22 set. 2010.
DRAHOS, Peter; BRAITHWAITE, John. Information feudalism: who owns the knowledge
economy?. New York US: New Press, 2003.
FLENNER, Robert; ABBOTT, Michael; BOUBEZ, Toufic; COHEN, Frank; KRISHNAN,
Navaneeth; MOFFET, Alan; RAMAMURTI, Rajam; SIDDIGUI, Bilal; SOMMERS, Frank. Java
P2P: Unleashed. New Jersey, US: Sams Publishing, 2002. ISBN 0-672-32399-0
FREE SOFTWARE FOUNDATION. Gnutella: regarding Gnutella. 2010. Disponível em:
<http://www.gnu.org/philosophy/gnutella.html>. Acesso em: 01 set. 2010.
HATALA, Marek; RICHARDS, Griff; EAP, Timmy; WILLMS, Jordan. The interoperability of
learning object repositories and services: standards, implementations and lessons learned. In:
WORLD WIDE WEB CONFERENCE, 13., 2004, New York. Proceedings… New York: ACM
Press, 2004. ISBN: 1-58113-844-X.
IMS. IMS Digital Repositories Interoperability. 2003. Disponivel em:
<http://www.imsglobal.org/digitalrepositories/driv1p0/imsdri_infov1p0.html#1247983>. Acesso
em: 10 set. 2010.
IRLBECK, Sonja; MOWAT, Joanne. Learning Content Management System (LCMS). In:
KOOHANG, Alex; HARMAN, Keith. Learning Objects: standards, metadatas, repositories, and
LCMS. Santa Rosa: Informing Science Press, 2007. P157-184. ISBN 83-922337-5-1
JIA, Weijia; ZHOU, Wanley. Distributed network systems, from concepts to implementations.
Boston: Springer, 2005. vol. 15. ISBN: 0-387-23840-9.
LOW, Boon; CASSIDY, Kathryn; FERGUSSON, David; ATKISSON, Malcolm; MEER, Elizabeth
Vander; MCGEEVER, Mags. Distributed Computing Education, Part 5: coming to terms with
intellectual property rights. IEEE Distributed Systems Online, v.9, n.12, dez. 2008. ISSN 1541492.
NASCIMENTO, Anna C.; MORGADO, Eduardo. Um projeto de colaboração internacional na
América Latina. 2008. Disponível em: <http://rived.mec.gov.br/artigos/rived.pdf>. Acesso em: 10
set. 2010.
77
RAINSFORD, M.. P2P: revolution or evolution? 2003. Disponível em:
<http://www.opendemocracy.net/ debates/article--1666.jsp>. Acesso em: 18 set. 2010
RIMMER, M. The genie's revenge: a response to Siva Vaidhyanathan.2003. Disponivel em:
<http://www.opendemocracy.net/content/articles/PDF/1639>. Acesso em: 18 set. 2010
SANTIAGO, Rafael. LOP2P: arquitetura para compartilhamento de Objetos de Aprendizagem
entre Instituições de Ensino. 2009. 129 p. Dissertação (Mestrado em Computação Aplicada) Universidade do Vale do Itajaí, São José, 2009.
SHIRKY, Clay. OPENP2P, Modern p2p definition. 2000. Disponível em:
<http://www.openp2p.com/pub/a/p2p/2000/11/24/shirky1-whatisp2p.html>. Acesso em: 10 set.
2010.
SLOANE, Julie. WIRED 13.01: The BitTorrent Effect. 2007. Disponível em:
<http://www.wired.com/techbiz/startups/news/2007/12/YE_10_startups>. Acesso em: 16 set. 2010.
TAYLOR, Ian J.; HARRISON, Andrew. From P2P and grids to services on the web, evolving
distributed communities. 2.ed. London UK: Springer, 2009.
UNESCO. UNESCO Promotes New Initiative for Free Educational Resources on the Internet.
2002. Disponível em: <http://www.unesco.org/education/news_en/080702_free_edu_ress.shtml>.
Acesso em: 09 set. 2010.
WILEY, D. A. Connecting learning objects to instructional design theory: a definition, a metaphor,
and a taxonomy. In: WILEY, D. A. (Ed.), The instructional use of learning objects: online
version. 2000. Disponível em : < http://reusability.org/read/chapters/wiley.doc >. Acesso em: 10
set. 2010.
WILHELM, Pierre.; WILDE, Russ. Developing a university course for online delivery based on
learning objects: from ideals to compromises. Philadelphia US: Open Learning, 2005.
78