UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO"

Transcrição

1 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

2 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

3 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

4 SUMÁRIO LISTA DE ABREVIATURAS... v LISTA DE FIGURAS... vi LISTA DE TABELAS... vii RESUMO... viii ABSTRACT... ix 1. INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos FUNDAMENTAÇÃO TEÓRICA OBJETOS DE APRENDIZAGEM SISTEMAS LOWARE (LEARNING OBJECTS WARE) Redes de repositórios REDE LOP2P Plugin loware Camada de Mediação REDES P2P Exemplos de Aplicações P2P Impactos Sociais das Tecnologias P2P FRAMEWORK JXTA JxtaCast Desenvolvimento COMPORTAMENTO BITTORRENT Divisão por blocos dos arquivos de OAs Tipos de mensagens Comunicação entre peers Interação entre os peers e suas camadas ANALISE DO CÓDIGO-FONTE LOP2P ANTERIOR MUDANÇAS DO COMPORTAMENTO BITTORRENT APLICADAS AO LOP2P JxtaCast Alterações no código Segmentação e agrupamento dos OAs Busca por blocos iii

5 3.4. EXPERIMENTOS COM O COMPORTAMENTO BITTORRENT LOP2P Resultados do ambiente controlado Resultados em ambiente real CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS iv

6 LISTA DE ABREVIATURAS ARIADNE Alliance of Remote Instructional Authoring and Distribution Network for Europe CM Camada de Mediação EA Enterprise Architect ERP Endpoint Routing Protocol IEEE Institute of Eletrical and Eletronics Engineer IP Internet Protocol IMS DRI Instructional Management Systems for Digital Repository Interoperability LCMS Learning Content Management Systems LMS Learning Management Systems LOP2P Learning Objects Peer to Peer LOR Learning Object Repositories LOWARE Learning Objects - Ware LTSC Learning Technology Standards Comitee MD5 Message Digest Algorithm 5 MOODLE Modular Object-Oriented Dynamic Learning Environment OA Objeto de Aprendizagem OAI PMH Open Archive Initiative Protocol for Metadata Harvesting OER Open Education Resource P2P Peer to Peer PBP Pipe Binding Protocol PDP Peer Discovery Protocol PIP Peer Information Protocol PRP Peer Resolver Protocol RIVED Rede Internacional Virtual de Educacíon RVP Rendezvous Protocol SBC Sociedade Brasileira de Computação TCC Trabalho de Conclusão de Curso TCP/IP Transmission Control Protocol - Internet Protocol UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language v

7 LISTA DE FIGURAS Figura 1. Exemplo ilustrando o LOP2P com um comportamento BitTorrent Figura 2. Componentes de um LMS Figura 3. Componentes de um LCMS Figura 4. Itens fundamentais para um repositório de OA Figura 5. Funções na camada de mediação IMS DRI Figura 6. Cenário com a rede LOP2P Figura 7. Arquitetura da CM e integração com o sistema loware Figura 8. Exemplo de uso da Aplicação Napster Figura 9. Exemplo de uso da aplicação Gnutella Figura 10. Exemplo de uso da Aplicação BitTorrent Figura 11. Camadas do framework JXTA Figura 12. Pipes e intermediários entre peers Figura 13. Grupos de peers e Rendezvous nodes Figura 14. Divisão do arquivo em blocos Figura 15. Uso das mensagens entre os peers Figura 16. Diagrama de sequência com a Interação entre os peers e suas Camadas de Mediação Figura 17. Engenharia reversa do código-fonte LOP2P, pacote Network Communication Device envio de mensagens Figura 18. Engenharia reversa do código-fonte LOP2P, pacote Network Communication Device - recebimento de mensagens Figura 19. Diagrama de classes do pacote protosubmitdevice Figura 20. Diagrama de classes do pacote protonetcommunicationdevice Figura 21. Diagrama de classes do pacote protosearchdevice Figura 22. Segmentação do OA, de forma detalhada Figura 23. Agrupamento do OA, de forma detalhada Figura 24. Busca por blocos dentre os peers Figura 25. Diagrama de redes para a infra-estrutura descrita na tabela Figura 26. Camada de Mediação do peer LOP2Pb Figura 27. LOP2Pb2 após o agrupamento dos blocos e com o arquivo original aberto Figura 28. LOP2Pb4 realizando o download de todos os blocos e os agrupando Figura 29. Diagrama de redes para a estrutura descrita na tabela Figura 30. LOP2Pb1 realiza o download de todos os blocos a partir de LOP2Pb4 e LOP2Pb Figura 31. Diagrama de redes com a estrutura descrita na tabela Figura 32. LOP2Pb6 após o download dos blocos Figura 33. Diagrama de redes detalhando a estrutura descrita na tabela vi

8 LISTA DE TABELAS Tabela 1. Comparativo entre redes de repositórios Tabela 2. Comparativo entre as aplicações P2P Tabela 3. Dispositivos para o primeiro experimento em ambiente controlado Tabela 4. Dispositivos para o segundo experimento em ambiente controlado Tabela 5. Dispositivos para o primeiro experimento em ambiente real Tabela 6. Dispositivos para o segundo experimento em ambiente real vii

9 RESUMO FUCK JUNIOR, Jorge. Adicionando comportamento baseado em BitTorrent à rede LOP2P. Itajaí, 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í, 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

10 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

11 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 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

12 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

13 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

14 1.1. PROBLEMATIZAÇÃO 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 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

15 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 OBJETIVOS Objetivo Geral O Objetivo Geral deste trabalho é adaptar o comportamento BitTorrent à arquitetura LOP 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

16 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

17 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

18 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 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

19 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

20 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 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

21 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 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

22 Figura 3. Componentes de um LCMS Fonte: adaptado de Irlbeck e Mowat (2007) 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

23 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

24 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

25 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 LOP2P Conecta pessoas que desejam compartilhar OAs Conecta principalmente instituições de ensino para compartilhamento de OAs. Pode conectar repositórios Conecta os usuários através de uma rede peer-to-peer e publica os OAs compartilhados Conecta a instituição de ensino através dos sistemas de gerenciamento de aprendizado (LMS) Não 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

26 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

27 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

28 podendo ter como forma de distribuição o protocolo de 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 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

29 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

30 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 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 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

31 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. rede LOP2P. A iteração entre os componentes descritos fica clara na Figura 7, que representa um peer na 29

32 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

33 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 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

34 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

35 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

36 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) 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 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

37 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

38 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

39 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 Comparativo entre as aplicações P2P trabalho: Na Tabela 2, é elaborado um comparativo com as aplicações P2P que são abordadas neste Tabela 2. Comparativo entre as aplicações P2P Napster Gnutella Kazaa Skype BitTorrent Compartilhamento Músicas Arquivos em Voz, Texto, Arquivos em Músicas geral Bate-papo Geral Busca Estruturada Desestruturada Desestruturada Estruturada Parcialmente Estruturada Centralização Hibrida Puramente Parcialmente Puramente Descentralizada Centralizada Descentralizada Hibrida True P2P Não Sim Não Não Não Envio de pedaços) Arquivos por Blocos (ou Não Não Não Não Sim 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

40 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 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. eram: Os três principais objetivos a serem atingidos quando fora desenvolvido o framework JXTA 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

41 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

42 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

43 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

44 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 JxtaCast 42

45 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

46 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

47 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 Comportamento BitTorrent Conforme visto na Seção , 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 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

48 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 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

49 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 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 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

50 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; 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; 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

51 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; 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; 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

52 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

53 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 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

54 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

55 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

56 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 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 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

57 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 Alterações no código foram: As classes que abrigaram novo código para a implementação do comportamento BitTorrent 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

58 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

59 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

60 58

61 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

62 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 , é 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

63 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

64 Figura 23. Agrupamento do OA, de forma detalhada 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

65 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

66 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 hops 1, 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

67 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 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 LOP2Pb1 LOP2Pb2 LOP2Pb4 LOP2Pb5 UID Final 2203 Final DD03 Final B203 Final EB03 SO Fedora 14 Fedora 14 Windows XP - Windows XP - Professional Professional IP Blocos Bloco 3(1536) Blocos 1(512) e 4(2048) Nenhum Todos 3. No diagrama de redes exposto na Figura 25, pode-se visualizar a estrutura descrita na Tabela 65

68 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 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

69 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

70 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

71 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 LOP2Pb1 LOP2Pb4 LOP2Pb5 UID Final 9404 Final 7703 Final 7903 SO Fedora 14 Windows XP Windows XP - Professional Professional IP Blocos Nenhum Nenhum Todos 4. No diagrama de redes exposto na Figura 29, pode-se visualizar a estrutura descrita na Tabela 69

72 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 KB). 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

73 Figura 30. LOP2Pb1 realiza o download de todos os blocos a partir de LOP2Pb4 e LOP2Pb 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

74 Tabela 5. Dispositivos para o primeiro experimento em ambiente real Nome LOP2Pb1 LOP2Pb2 LOP2Pb5 LOP2Pb6 UID Final 4203 Final 3403 Final BD03 Final EE03 SO Fedora 14 Fedora 14 Windows XP - Professional Fedora 14 IP WAN: jorgelop2p.dyndns.org LAN: Blocos Nenhum Nenhum Todos Nenhum 5. No diagrama de redes exposto na Figura 31, pode-se visualizar a estrutura descrita na tabela 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 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

75 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 KB). 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 LOP2Pb1 LOP2Pb5 LOP2Pb6 UID Final 4203 Final 3403 Final EE03 SO Fedora 14 Windows XP - Professional Fedora 14 IP WAN: jorgelop2p.dyndns.org LAN: Blocos Nenhum Todos Nenhum 73

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar Redes Peer-to-Peer Redes Peer-to to-peer Arquitetura de Redes P2P Integridade e Proteção Redes Peer-to-Peer (P2P) São sistemas distribuídos nos quais os membros da rede são equivalentes em funcionalidade

Leia mais

JXTA. Alessandro Vasconcelos Ferreira de Lima. avfl@cin.ufpe.br

JXTA. Alessandro Vasconcelos Ferreira de Lima. avfl@cin.ufpe.br JXTA Alessandro Vasconcelos Ferreira de Lima Roteiro Motivação Introdução Arquitetura de JXTA Elementos de JXTA Os Protocolos Comparações e Desvantagens Conclusão Motivação Limitações do Modelo Cliente

Leia mais

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar Redes Peer- Redes Peer- (P2P) São sistemas distribuídos nos quais os membros da rede são equivalentes em funcionalidade Permitem que os pares compartilhem recursos diretamente, sem envolver intermediários

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 1 de agosto de 2009 Membership Grupos dinâmicos Membros entram e saem dos grupos Membros podem falhar (crash) Grupos são criados e destruídos em tempo

Leia mais

Arquitetura para Compartilhamento de Objetos de Aprendizagem entre Instituições de Ensino

Arquitetura para Compartilhamento de Objetos de Aprendizagem entre Instituições de Ensino Revista Brasileira de Informática na Educação, Volume 19, Número 1, 2011 Arquitetura para Compartilhamento de Objetos de Aprendizagem entre Rafael de Santiago Mestrado em Computação Aplicada Universidade

Leia mais

Aplicações P2P. André Lucio e Gabriel Argolo

Aplicações P2P. André Lucio e Gabriel Argolo Aplicações P2P André Lucio e Gabriel Argolo Tópicos Internet Peer-to-Peer (Introdução) Modelos (Classificação) Napster Gnutella DHT KaZaA Razões para o Sucesso da Internet Capacidade de interligar várias

Leia mais

RAFAEL DE SANTIAGO LOP2P ARQUITETURA PARA COMPARTILHAMENTO DE OBJETOS DE APRENDIZAGEM ENTRE INSTITUIÇÕES DE ENSINO

RAFAEL DE SANTIAGO LOP2P ARQUITETURA PARA COMPARTILHAMENTO DE OBJETOS DE APRENDIZAGEM ENTRE INSTITUIÇÕES DE ENSINO RAFAEL DE SANTIAGO LOP2P ARQUITETURA PARA COMPARTILHAMENTO DE OBJETOS DE APRENDIZAGEM ENTRE INSTITUIÇÕES DE ENSINO São José (SC), setembro de 2009 UNIVERSIDADE DO VALE DO ITAJAÍ CURSO DE MESTRADO ACADÊMICO

Leia mais

Arquitetura de uma Rede JXTA

Arquitetura de uma Rede JXTA Page 1 of 6 Redes de Proteção SP Produtos de Rede Confiança e credibilidade. fone Produtos TrendNet: qualidade, (011) 6197-0707 garantia e ótimo custo/benefício. www.tudoderedesdeprotecao.com.br http://www.trendware.com.br

Leia mais

DEFINIÇÃO DE METADADOS PARA O REPOSITÓRIO DE OBJETOS DE APRENDIZAGEM DA EAD - UFSC

DEFINIÇÃO DE METADADOS PARA O REPOSITÓRIO DE OBJETOS DE APRENDIZAGEM DA EAD - UFSC DEFINIÇÃO DE METADADOS PARA O REPOSITÓRIO DE OBJETOS DE APRENDIZAGEM DA EAD - UFSC Projeto desenvolvido junto ao Departamento de EAD/UFSC 2007-2008. Equipe: Profª. Edna Lucia da Silva e Profª. Ligia Café

Leia mais

Manual do sistema. My e-learning objects. Laboratório de Engenharia de Software e Tecnologias de Informação e Comunicação

Manual do sistema. My e-learning objects. Laboratório de Engenharia de Software e Tecnologias de Informação e Comunicação Manual do sistema My e-learning objects Laboratório de Engenharia de Software e Tecnologias de Informação e Comunicação Manual do sistema - Meelo Autor: Alexandre Yukio Yamashita Laboratório de Engenharia

Leia mais

Rede Peer-To-Peer. Conteúdo

Rede Peer-To-Peer. Conteúdo Rede Peer-To-Peer Universidade Federal do Maranhão Centro de Ciências Exatas e Tecnologia Pós-Graduação em Engenharia de Eletricidade Estágio Docente Prof. Dr. Mário Meireles Teixeira Mestrando: Flávio

Leia mais

Sistemas de gestão de conteúdo para objetos de aprendizagem: características desejáveis e soluções existentes. Liane Tarouco CINTED/UFRGS

Sistemas de gestão de conteúdo para objetos de aprendizagem: características desejáveis e soluções existentes. Liane Tarouco CINTED/UFRGS Sistemas de gestão de conteúdo para objetos de aprendizagem: características desejáveis e soluções existentes Liane Tarouco CINTED/UFRGS 1 Gestão de conteúdo Alternativas metodológicas e tecnológicas para

Leia mais

Peer to Peer. Sandro, Eluan. 8 de Novembro de 2013. Universidade Estácio de Sá

Peer to Peer. Sandro, Eluan. 8 de Novembro de 2013. Universidade Estácio de Sá Universidade Estácio de Sá 8 de Novembro de 2013 Sumario 1 Denição 2 3 4 5 6 Um tipo de rede de computadores onde cada estação possui capacidades e responsabilidades equivalentes. Isto difere da arquitetura

Leia mais

Autor(es) BRUNO TEODOSIO GONÇALVES. Orientador(es) CECÍLIA SOSA ARIAS PEIXOTO, FLÁVIA LINHALIS. Apoio Financeiro FAPIC/UNIMEP. 1.

Autor(es) BRUNO TEODOSIO GONÇALVES. Orientador(es) CECÍLIA SOSA ARIAS PEIXOTO, FLÁVIA LINHALIS. Apoio Financeiro FAPIC/UNIMEP. 1. 19 Congresso de Iniciação Científica ESTUDO EXPLORATÓRIO SOBRE PADRÕES DE OBJETOS DE APRENDIZAGEM PARA AMBIENTES COLABORATIVOS DE APRENDIZADO ELETRÔNICO Autor(es) BRUNO TEODOSIO GONÇALVES Orientador(es)

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

Integração ERP/WMS e vantagens com a adoção de software livre

Integração ERP/WMS e vantagens com a adoção de software livre Integração ERP/WMS e vantagens com a adoção de software livre Filipi Damasceno Vianna (PUCRS) filipi@em.pucrs.br Resumo Este trabalho visa mostrar a importância da integração entre sistemas de ERP 1 e

Leia mais

João Rocha Marco Antônio Domingues. Eduardo Souto Guthemberg Silvestre Carlos Kamienski Djamel Sadok

João Rocha Marco Antônio Domingues. Eduardo Souto Guthemberg Silvestre Carlos Kamienski Djamel Sadok GPRT/UFPE GPRT/UFPE Peer-to-Peer (P2P) Computação Colaborativa na Internet Minicurso SBRC - (alterado por Andrea Krob) Autores Originais (UFPE) João Rocha Marco Antônio Domingues Arthur Callado Eduardo

Leia mais

Gerenciamento de Rede Baseado em Políticas

Gerenciamento de Rede Baseado em Políticas Gerenciamento de Rede Baseado em Políticas (Policy-Based Networking) Ademir José de Carvalho Junior Recife, Fevereiro de 2007 Resumo: A complexidade das redes baseadas em IP atualmente segue crescendo

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Comunicação de Grupos Peer to Peer Comunicação de Grupos Modelos Anteriores - Comunicação envolvia somente duas partes. RPC não permite comunicação de um processo com vários outros

Leia mais

com Repositórios Abertos

com Repositórios Abertos Integração do Moodle com Repositórios Abertos Liane Tarouco Marcelo Schmitt PGIE/CINTED Univ. Federal Rio Grande do Sul Brasil LACLO 2010 Autoria de conteúdo educacional Crescimento de educação a distância

Leia mais

COMPARTILHAMENTO DE INFORMAÇÕES ENTRE COMPUTADORES ATRAVÉS DA TECNOLOGIA PEER-TO-PEER (P2P) USANDO A PLATAFORMA JXTA

COMPARTILHAMENTO DE INFORMAÇÕES ENTRE COMPUTADORES ATRAVÉS DA TECNOLOGIA PEER-TO-PEER (P2P) USANDO A PLATAFORMA JXTA COMPARTILHAMENTO DE INFORMAÇÕES ENTRE COMPUTADORES ATRAVÉS DA TECNOLOGIA PEER-TO-PEER (P2P) USANDO A PLATAFORMA JXTA José Voss Junior (FURB) juniorvs@inf.furb.br Francisco Adell Péricas (FURB) pericas@furb.br

Leia mais

Resumo. Introdução História Caracteristicas Exemplos Arquitetura Distribuição Vertical vs Distribuição Horizontal Segurança Conclusão

Resumo. Introdução História Caracteristicas Exemplos Arquitetura Distribuição Vertical vs Distribuição Horizontal Segurança Conclusão Peer 2 Peer (P2P) Resumo Introdução História Caracteristicas Exemplos Arquitetura Distribuição Vertical vs Distribuição Horizontal Segurança Conclusão O que é P2P? Introdução Tipo de arquitetura de rede

Leia mais

Desenvolvimento de uma Rede de Distribuição de Arquivos. Development of a File Distribution Network

Desenvolvimento de uma Rede de Distribuição de Arquivos. Development of a File Distribution Network Desenvolvimento de uma Rede de Distribuição de Arquivos Development of a File Distribution Network Desenvolvimento de uma Rede de Distribuição de Arquivos Development of a File Distribution Network Talles

Leia mais

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões FACSENAC ECOFROTA Documento de Projeto Lógico de Rede Versão:1.5 Data: 21/11/2013 Identificador do documento: Projeto Lógico de Redes Versão do Template Utilizada na Confecção: 1.0 Localização: FacSenac

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

LISTA DE EXERCÍCIOS. Mede a capacidade de comunicação de computadores e dispositivos. Operam em diferentes plataformas de hardware

LISTA DE EXERCÍCIOS. Mede a capacidade de comunicação de computadores e dispositivos. Operam em diferentes plataformas de hardware 1. A nova infra-estrutura de tecnologia de informação Conectividade Mede a capacidade de comunicação de computadores e dispositivos Sistemas abertos Sistemas de software Operam em diferentes plataformas

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Comunicação coletiva Modelo Peer-to-Peer Slide 6 Nielsen C. Damasceno Introdução Os modelos anteriores eram realizado entre duas partes: Cliente e Servidor. Com RPC e RMI não é possível

Leia mais

Projeto OBAA. Relatório Técnico RT-OBAA-07 Grupo Agentes e Ontologias. Proposta de Federação de Repositórios de Objetos Educacionais.

Projeto OBAA. Relatório Técnico RT-OBAA-07 Grupo Agentes e Ontologias. Proposta de Federação de Repositórios de Objetos Educacionais. Edital MCT/FINEP/MC/FUNTTEL Plataformas para Conteúdos Digitais 01/2007 Projeto OBAA Relatório Técnico RT-OBAA-07 Grupo Agentes e Ontologias Proposta de Federação de Repositórios de Objetos Educacionais

Leia mais

FRAMEWORK P2P PARA PESQUISA DE INFORMAÇÕES

FRAMEWORK P2P PARA PESQUISA DE INFORMAÇÕES UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FRAMEWORK P2P PARA PESQUISA DE INFORMAÇÕES Área de Sistemas Distribuídos por Rafael Souza

Leia mais

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Índice Como acessar o Moodle Editando seu PERFIL Editando o curso / disciplina no Moodle Incluindo Recursos

Leia mais

Cap 03 - Camada de Aplicação Internet (Kurose)

Cap 03 - Camada de Aplicação Internet (Kurose) Cap 03 - Camada de Aplicação Internet (Kurose) 1. Qual a diferença entre um Programa de computador e um Processo dentro do computador? R. Processo é um programa que está sendo executado em uma máquina/host,

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Redes de Computadores e a Internet

Redes de Computadores e a Internet Redes de Computadores e a Internet Magnos Martinello Universidade Federal do Espírito Santo - UFES Departamento de Informática - DI Laboratório de Pesquisas em Redes Multimidia - LPRM 2010 Camada de Aplicação

Leia mais

PEER DATA MANAGEMENT SYSTEM

PEER DATA MANAGEMENT SYSTEM PEER DATA MANAGEMENT SYSTEM INTRODUÇÃO, INFRA-ESTRUTURA E MAPEAMENTO DE ESQUEMAS AGENDA Data Management System Peer Data Management System P2P Infra-estrutura Funcionamento do PDMS Mapeamento de Esquemas

Leia mais

UMA ABORDAGEM SOBRE A INTERFACE DE PROGRAMAÇÃO DE APLICAÇÕES SOCKETS E A IMPLEMENTAÇÃO DE UM SERVIDOR HTTP

UMA ABORDAGEM SOBRE A INTERFACE DE PROGRAMAÇÃO DE APLICAÇÕES SOCKETS E A IMPLEMENTAÇÃO DE UM SERVIDOR HTTP UMA ABORDAGEM SOBRE A INTERFACE DE PROGRAMAÇÃO DE APLICAÇÕES SOCKETS E A IMPLEMENTAÇÃO DE UM SERVIDOR HTTP Alan Jelles Lopes Ibrahim, alan.jelles@hotmail.com Eduardo Machado Real, eduardomreal@uems.br

Leia mais

Integração ERP/WMS e vantagens com a adoção de software livre

Integração ERP/WMS e vantagens com a adoção de software livre Integração ERP/WMS e vantagens com a adoção de software livre Filipi Damasceno Vianna (PUCRS) filipi@pucrs.br Tiago Leonardo Broilo (PUCRS) broilo@pucrs.br Isaac Newton Lima da Silva (PUCRS) isaac@pucrs.br

Leia mais

GVGO Grupo 3. Perguntas & Respostas. Peer-to-Peer & Cloud Computing. Peer to Peer

GVGO Grupo 3. Perguntas & Respostas. Peer-to-Peer & Cloud Computing. Peer to Peer Perguntas & Respostas Peer to Peer GVGO Grupo 3 Peer-to-Peer & Cloud Computing 1. O BitTorrent (rede P2P desestruturada) utiliza um tracker centralizado para cada swarm. Cite três propriedades que as redes

Leia mais

Elaboração de videoaulas seguindo padrões de objetos de aprendizagem para disponibilização no serviço de educação a distância (EDAD) da RNP

Elaboração de videoaulas seguindo padrões de objetos de aprendizagem para disponibilização no serviço de educação a distância (EDAD) da RNP Elaboração de videoaulas seguindo padrões de objetos de aprendizagem para disponibilização no serviço de educação a distância (EDAD) da RNP Eduardo Barrére Liamara Scortegagna Atualizando o título: Elaboração

Leia mais

Capítulo 8 - Aplicações em Redes

Capítulo 8 - Aplicações em Redes Capítulo 8 - Aplicações em Redes Prof. Othon Marcelo Nunes Batista Mestre em Informática 1 de 31 Roteiro Sistemas Operacionais em Rede Modelo Cliente-Servidor Modelo P2P (Peer-To-Peer) Aplicações e Protocolos

Leia mais

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Material de apoio 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura

Leia mais

PRnet/2013. Linguagem de Programação Web

PRnet/2013. Linguagem de Programação Web Linguagem de Programação Web Linguagem de Programação Web Prnet/2013 Linguagem de Programação Web» Programas navegadores» Tipos de URL» Protocolos: HTTP, TCP/IP» Hipertextos (páginas WEB)» HTML, XHTML»

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

Norton Internet Security Guia do Usuário

Norton Internet Security Guia do Usuário Guia do Usuário Norton Internet Security Guia do Usuário O software descrito neste guia é fornecido sob um contrato de licença e pode ser usado somente conforme os termos do contrato. Documentação versão

Leia mais

Documento de Requisitos de Rede (DRP)

Documento de Requisitos de Rede (DRP) Documento de Requisitos de Rede (DRP) Versão 1.2 SysTrack - Grupo 1 1 Histórico de revisões do modelo Versão Data Autor Descrição 1.0 30/04/2011 João Ricardo Versão inicial 1.1 1/05/2011 André Ricardo

Leia mais

PROJETO E IMPLANTAÇÃO DE INTRANETS

PROJETO E IMPLANTAÇÃO DE INTRANETS PROJETO E IMPLANTAÇÃO DE INTRANETS Aulas : Terças e Quintas Horário: AB Noite [18:30 20:20hs] PROJETO E IMPLANTAÇÃO DE INTRANETS 1 Conteúdo O que Rede? Conceito; Como Surgiu? Objetivo; Evolução Tipos de

Leia mais

Instalando o IIS 7 no Windows Server 2008

Instalando o IIS 7 no Windows Server 2008 Goiânia, 16/09/2013 Aluno: Rafael Vitor Prof. Kelly Instalando o IIS 7 no Windows Server 2008 Objetivo Esse tutorial tem como objetivo demonstrar como instalar e configurar o IIS 7.0 no Windows Server

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Instalando o IIS 7 no Windows Server 2008

Instalando o IIS 7 no Windows Server 2008 Goiânia, 16/09/2013 Aluno: Rafael Vitor Prof. Kelly Instalando o IIS 7 no Windows Server 2008 Objetivo Esse tutorial tem como objetivo demonstrar como instalar e configurar o IIS 7.0 no Windows Server

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Redes de Computadores II

Redes de Computadores II Redes de Computadores II INTERNET Protocolos de Aplicação Intranet Prof: Ricardo Luís R. Peres As aplicações na arquitetura Internet, são implementadas de forma independente, ou seja, não existe um padrão

Leia mais

JULIANO AUGUSTO DE SOUZA OLIVEIRA

JULIANO AUGUSTO DE SOUZA OLIVEIRA UNIVERSIDADE DE RIBEIRÃO PRETO CENTRO DE CIÊNCIAS EXATAS, NATURAIS E TECNOLÓGICAS PÓS-GRADUAÇÃO LATO SENSU EM BANCO DE DADOS JULIANO AUGUSTO DE SOUZA OLIVEIRA IMPLEMENTAÇÃO DE UM SISTEMA DE CONTROLE DE

Leia mais

SISTEMAS DE INFORMAÇÕES GERENCIAIS. Aula 09

SISTEMAS DE INFORMAÇÕES GERENCIAIS. Aula 09 FACULDADE CAMÕES PORTARIA 4.059 PROGRAMA DE ADAPTAÇÃO DE DISCIPLINAS AO AMBIENTE ON-LINE SISTEMAS DE INFORMAÇÃO GERENCIAL DOCENTE: ANTONIO SIEMSEN MUNHOZ, MSC. ÚLTIMA ATUALIZAÇÃO: FEVEREIRO DE 2007. Internet,

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Camada de Aplicação Slide 1 Aplicação e Protocolo de Aplicação Aplicação: processos distribuídos em comunicação rodam nos computadores usuários da rede como programas de usuário trocam

Leia mais

GT Computação Colaborativa (P2P)

GT Computação Colaborativa (P2P) GT Computação Colaborativa (P2P) Djamel Sadok Julho de 2003 Este documento tem como objetivo descrever o projeto de estruturação do grupo de trabalho GT Computação Colaborativa (P2P), responsável pelo

Leia mais

Um pouco sobre Pacotes e sobre os protocolos de Transporte

Um pouco sobre Pacotes e sobre os protocolos de Transporte Um pouco sobre Pacotes e sobre os protocolos de Transporte O TCP/IP, na verdade, é formado por um grande conjunto de diferentes protocolos e serviços de rede. O nome TCP/IP deriva dos dois protocolos mais

Leia mais

OBJETOS DE APRENDIZAGEM

OBJETOS DE APRENDIZAGEM MEDs e METADADOS OBJETOS DE APRENDIZAGEM O que é um objeto de aprendizagem? Segundo Wiley, D.A.,2000 Qualquer entidade DIGITAL que pode ser usada, reusada ou referenciada durante um processo de aprendizagem

Leia mais

A INTERNET E A NOVA INFRA-ESTRUTURA DA TECNOLOGIA DE INFORMAÇÃO

A INTERNET E A NOVA INFRA-ESTRUTURA DA TECNOLOGIA DE INFORMAÇÃO A INTERNET E A NOVA INFRA-ESTRUTURA DA TECNOLOGIA DE INFORMAÇÃO 1 OBJETIVOS 1. O que é a nova infra-estrutura informação (TI) para empresas? Por que a conectividade é tão importante nessa infra-estrutura

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

FEB Federação de Repositórios Educa Brasil UFRGS/UNISINOS

FEB Federação de Repositórios Educa Brasil UFRGS/UNISINOS FEB Federação de Repositórios Educa Brasil UFRGS/UNISINOS Parcerias A UFRGS é a executora principal do projeto, através do Centro Interdisciplinar de Novas Tecnologias na Educação (CINTED), do Programa

Leia mais

Introdução ao Subsistema Multimídia IP (IMS) Conceitos básicos de IMS e terminologia

Introdução ao Subsistema Multimídia IP (IMS) Conceitos básicos de IMS e terminologia Introdução ao Subsistema Multimídia IP (IMS) Conceitos básicos de IMS e terminologia Introdução Formalmente, o IP Multimedia Subsystem (IMS) é definido como:... um novo 'domínio' principal da rede (ou

Leia mais

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo Introdução O que é Protocolo? - Para que os pacotes de dados trafeguem de uma origem até um destino, através de uma rede, é importante

Leia mais

TECNOLOGIA WEB INTERNET PROTOCOLOS

TECNOLOGIA WEB INTERNET PROTOCOLOS INTERNET PROTOCOLOS 1 INTERNET Rede mundial de computadores. Também conhecida por Nuvem ou Teia. Uma rede que permite a comunicação de redes distintas entre os computadores conectados. Rede WAN Sistema

Leia mais

Peer-to-Peer. Introdução. Motivação. Definição. Definição. Definição. Everton Flávio Rufino Seára Murilo R. de Lima

Peer-to-Peer. Introdução. Motivação. Definição. Definição. Definição. Everton Flávio Rufino Seára Murilo R. de Lima Introdução Peer-to-Peer Everton Flávio Rufino Seára Murilo R. de Lima Peer-to-Peer (P2P) é a base da operação de sistemas distribuídos como SETI@home e Kazaa; caracterizada por compartilhamento direto

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB

Curso de Aprendizado Industrial Desenvolvedor WEB Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos II Professor: Cheli dos S. Mendes da Costa Modelo Cliente- Servidor Modelo de Aplicação Cliente-servidor Os

Leia mais

Repositórios, Acesso Livre, Preservação Digital. Questões para hoje e amanhã

Repositórios, Acesso Livre, Preservação Digital. Questões para hoje e amanhã Repositórios, Acesso Livre, Preservação Digital Questões para hoje e amanhã Florianópolis 1.000.000 a.c - 2009 d.c Evolução da prática científica O compartilhamento dos dados das pesquisas mudou para práticas

Leia mais

MANUAL DE UTILIZAÇÃO DO MOODLE 2.6

MANUAL DE UTILIZAÇÃO DO MOODLE 2.6 NÚCLEO DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO NTIC MANUAL DE UTILIZAÇÃO DO MOODLE 2.6 PERFIL ALUNO Versão 1.0 2014 NÚCLEO DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO NTIC MANUAL DE UTILIZAÇÃO DO MOODLE

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I Prof. MSc. Hugo Souza Como já vimos, os sistemas distribuídos são apresentados considerando um planejamento bem mais complexo relacionado aos

Leia mais

Prof. Manuel A Rendón M

Prof. Manuel A Rendón M Prof. Manuel A Rendón M Kurose Redes de Computadores e a Internet Uma Abordagem Top-Down 5ª. Edição Pearson Cap.: 1 até 1.2.2 2.1.2 2.1.4 Como funciona uma rede? Existem princípios de orientação e estrutura?

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - Switch na Camada 2: Comutação www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Introdução A conexão entre duas portas de entrada e saída, bem como a transferência de

Leia mais

VELOCIDADE DE TRANSMISSÃO DE DADOS UTILIZANDO VPNs

VELOCIDADE DE TRANSMISSÃO DE DADOS UTILIZANDO VPNs VELOCIDADE DE TRANSMISSÃO DE DADOS UTILIZANDO VPNs Rogers Rodrigues Garcia 1, Júlio César Pereira¹ ¹Universidade Paranaense (Unipar) Paranavai PR Brasil rogersgarcia@live.com, juliocesarp@unipar.br Resumo:

Leia mais

ATIVIDADES PRÁTICAS SUPERVISIONADAS

ATIVIDADES PRÁTICAS SUPERVISIONADAS ATIVIDADES PRÁTICAS SUPERVISIONADAS Ciência da Computação 5ª série Sistemas Operacionais A atividade prática supervisionada (ATPS) é um método de ensinoaprendizagem desenvolvido por meio de um conjunto

Leia mais

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Phil Maynard UNIDADE DE SOLUÇÕES DE GERENCIAMENTO DE DADOS PARA O CLIENTE FEVEREIRO DE 2012 Introdução Em todos os lugares, o volume de

Leia mais

INTRODUÇÃO A REDES DE COMPUTADORES (DEFINIÇÕES) Prof. Msc. Hélio Esperidião

INTRODUÇÃO A REDES DE COMPUTADORES (DEFINIÇÕES) Prof. Msc. Hélio Esperidião INTRODUÇÃO A REDES DE COMPUTADORES (DEFINIÇÕES) Prof. Msc. Hélio Esperidião O QUE É? Uma Rede de Computadores é formada por um conjunto de equipamentos(módulos processadores - MPs) capazes de trocar informações

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

Questão em foco: Colaboração de produto 2.0. Uso de técnicas de computação social para criar redes sociais corporativas

Questão em foco: Colaboração de produto 2.0. Uso de técnicas de computação social para criar redes sociais corporativas Questão em foco: Colaboração de produto 2.0 Uso de técnicas de computação social para criar redes sociais corporativas Tech-Clarity, Inc. 2009 Sumário Sumário... 2 Introdução à questão... 3 O futuro da

Leia mais

UTILIZAÇÃO DE OBJETOS DE APRENDIZAGEM NO ENSINO DE QUÍMICA: EXPERIÊNCIA DO PIBID COMPUTAÇÃO/IFBA/CAMPUS PORTO SEGURO

UTILIZAÇÃO DE OBJETOS DE APRENDIZAGEM NO ENSINO DE QUÍMICA: EXPERIÊNCIA DO PIBID COMPUTAÇÃO/IFBA/CAMPUS PORTO SEGURO BRASIL & BAHIA (2013) UTILIZAÇÃO DE OBJETOS DE APRENDIZAGEM NO ENSINO DE QUÍMICA: EXPERIÊNCIA DO PIBID COMPUTAÇÃO/IFBA/CAMPUS PORTO SEGURO D.T. RODRIGUES 1, M. ROCHA 1, D.M. BRITO 1 e G.P. PINTO 1,2. 1

Leia mais

Arquitetura e Sistema de Monitoramento para

Arquitetura e Sistema de Monitoramento para Arquitetura e Sistema de Monitoramento para 1 Computação em Nuvem Privada Mestranda: Shirlei A. de Chaves Orientador: Prof. Dr. Carlos Becker Westphall Colaborador: Rafael B. Uriarte Introdução Computação

Leia mais

Camadas de Serviço de Hardware e Software em Sistemas Distribuídos. Introdução. Um Serviço Provido por Múltiplos Servidores

Camadas de Serviço de Hardware e Software em Sistemas Distribuídos. Introdução. Um Serviço Provido por Múltiplos Servidores Camadas de Serviço de Hardware e Software em Sistemas Distribuídos Arquiteutra de Sistemas Distribuídos Introdução Applications, services Adaptação do conjunto de slides do livro Distributed Systems, Tanembaum,

Leia mais

3 Propostas de Travessias de Firewalls/NAT

3 Propostas de Travessias de Firewalls/NAT 3 Propostas de Travessias de Firewalls/NAT Este capítulo irá apresentar as propostas deste trabalho para que aplicações que utilizem CORBA como plataforma de comunicação possam atravessar firewalls/nat.

Leia mais

Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados

Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados Maria das Dores Rosa Alves¹, Marcia Izabel Fugisawa Souza¹ ¹Embrapa Informática Agropecuária Caixa postal 6014 Campinas, SP

Leia mais

Redes de Computadores e a Internet

Redes de Computadores e a Internet Redes de Computadores e a Internet Magnos Martinello Universidade Federal do Espírito Santo - UFES Departamento de Informática - DI Laboratório de Pesquisas em Redes Multimidia - LPRM 2010 Camada de Aplicação

Leia mais

AVALIAÇÃO DE UM PROCESSO E SOFTWARE PARA A PRODUÇÃO DE CONTEÚDOS DE ENSINO

AVALIAÇÃO DE UM PROCESSO E SOFTWARE PARA A PRODUÇÃO DE CONTEÚDOS DE ENSINO 1 AVALIAÇÃO DE UM PROCESSO E SOFTWARE PARA A PRODUÇÃO DE CONTEÚDOS DE ENSINO Rio Branco AC 05/2010 Luciete Basto de Andrade Albuquerque Universidade Federal do Acre luciete@brturbo.com.br Luiz Augusto

Leia mais

Objetos de Aprendizagem para Educação a Distância Robson Santos da Silva

Objetos de Aprendizagem para Educação a Distância Robson Santos da Silva Objetos de Aprendizagem para Educação a Distância Robson Santos da Silva Novatec Copyright 2011 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida

Leia mais

Teste de Qualidade Web based para Banda Larga FAQs

Teste de Qualidade Web based para Banda Larga FAQs Teste de Qualidade Web based para Banda Larga FAQs Pergunta O que é o teste de velocidade? Quem é o público alvo? O que oferece? Como funciona? Por onde é o acesso? Resposta Um teste de qualidade de banda

Leia mais

Rotina de Discovery e Inventário

Rotina de Discovery e Inventário 16/08/2013 Rotina de Discovery e Inventário Fornece orientações necessárias para testar a rotina de Discovery e Inventário. Versão 1.0 01/12/2014 Visão Resumida Data Criação 01/12/2014 Versão Documento

Leia mais

Projeto e Instalação de Servidores Estrutura da Internet e do TCP/IP

Projeto e Instalação de Servidores Estrutura da Internet e do TCP/IP Projeto e Instalação de Servidores Estrutura da Internet e do TCP/IP Prof.: Roberto Franciscatto TCP/IP, endereçamento e portas TCP/IP? Dois protocolos TCP = Transfer Control Protocol IP = Internet Protocol

Leia mais

Protocolo Bittorrent

Protocolo Bittorrent Fundamentos Básicos Principais problemas Impacto na Rede Considerações Finais maxfaria@uniriote.br LETRA - UNIRIO 1 Fundamentos Básicos Bittorrent é um protocolo peer-to-peer para compartilhamento de arquivos

Leia mais

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2)

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2) Definição de um Sistema Distribuído (1) Introdução Um sistema distribuído é: Uma coleção de computadores independentes que aparecem para o usuário como um único sistema coerente. Definição de um Sistema

Leia mais

Curso de especialização em Teleinformática Disciplina Sistemas Distribuídos Prof. Tacla

Curso de especialização em Teleinformática Disciplina Sistemas Distribuídos Prof. Tacla - 1 - - 2 - COMUNICAÇÃO INTER PROCESSOS DISTRIBUÍDOS. - 3 - - 4 - Os sockets UDP e TCP são a interface provida pelos respectivos protocolos. Pode-se dizer que estamos no middleware de sistemas distribuídos

Leia mais

Unidade I SISTEMAS PARA INTERNET E. Prof. Emanuel Matos

Unidade I SISTEMAS PARA INTERNET E. Prof. Emanuel Matos Unidade I SISTEMAS PARA INTERNET E SOFTWARE LIVRE Prof. Emanuel Matos Sumário Unidade I Principais tecnologias da rede digital Computação cliente/servidor Comutação de pacotes TCP/IP Sistemas de informação

Leia mais

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido Arquitetura Roteiro Arquitetura Tipos de Arquitetura Centralizado Descentralizado Hibrido Questionário 2 Arquitetura Figura 1: Planta baixa de uma casa 3 Arquitetura Engenharia de Software A arquitetura

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br Camada de Redes (Continuação) 2 Camada de Rede 3 NAT: Network Address Translation restante da Internet 138.76.29.7 10.0.0.4 rede local (ex.: rede doméstica) 10.0.0/24

Leia mais

A INTERNET E A NOVA INFRA-ESTRUTURA DA TECNOLOGIA DE INFORMAÇÃO

A INTERNET E A NOVA INFRA-ESTRUTURA DA TECNOLOGIA DE INFORMAÇÃO Capítulo 9 A INTERNET E A NOVA INFRA-ESTRUTURA DA TECNOLOGIA DE INFORMAÇÃO 9.1 2003 by Prentice Hall OBJETIVOS O que é a nova infra-estrutura de tecnologia de informação (IT) para empresas? Por que a conectividade

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais