Referências abaixo:

Artigo na Infoq: Link

Repositório no GitHub: Link

Wiki: Link

Recentemente, precisei de um repositório que fosse aberto para uso, mas, que fosse possível manter projetos fechados com possibilidade de abrir para uma determinada quantidade de usuários. Encontrei o Assembla. O Assembla permite trabalhar com SVN ou Git, possui trambém recursos para trackin de projetos, wiki e outras ferramentas de colaboração que podem ser utilizadas de forma integrada com o repositório. Muitas dessas ferramentas estão disponíveis também para o pacote free, porém, diminui consideravelmente os recursos de armazenamento.

A administração é feita inteiramente Através do site, tornando possível atribuir e remover acesso aos usuários ao projeto, inclusive gerenciar permissões.

Achei essa ferramenta muito boa. É ideal para quem tem um projeto com vários colaboradores e que tem necessidade de mante-lo fechado. Taí a dica: Assembla; monte seu plano, pague baratou ou utilize de graça.

[]s.

Instalei o discador que veio no modem e a conexão foi feita normalmente com velocidade média de 50 a 60 KBps, uma velocidade excepcional pra quem mora em Manaus, já que a internet por aqui é precária. Naveguei cerca de dez minutos e uma surpresa, minha máquina travou. Reiniciei, conectei novamente e depois de dois minutos torna a travar. Fiquei frustrado com isso, tentei várias vezes e aconteceu a mesma coisa.

Anotei o modelo do modem e fui ao Google pra tentar resolver o problema. Em um dos fóruns que pesquisei tinha um post que recomendava atualizar o firmware do modem e o discador, lá tinha o link para o site do fabricante onde tinha os pacotes para tal, baixei imediatamente e instalei em seguida tudo conforme tava no manual. Reinstalei o software discador e tornei a discar.

Na primeira tentativa veio a frustração, travou novamente. Muito decepcionado, cogitei  em voltar para o Ubuntu, mesmo ignorando os softwares que uso no Windows, o que importava era solucionar esse problema e voltar a trabalhar o mais rápido possível. Hoje, utilizo o Windows 7, sistema operacional onde o problema ocorria constantemente, e para minha surpresa, o problema acontecia também no Linux. Cogitei em ir para a operadora para trocar o modem, porém, tinha que fazer uma ultima tentativa, tinha que fazer a conexão com o discador nativo do Windows.

Quando o modem é utilizado pela primeira vez no PC é instalado os drivers de conexão para Windows automaticamente. Portanto, ao configurar no discador nativo, para Windows, o modem 3G aparece para ser lincado ao discador. Copiei as configurações do software discador que vem com o modem a adicionei no discador e efetuei a discagem. Funcionou perfeitamente e não travou mais.

Conclusão, o problema todo era software discador que veio com o modem. Quando havia uma quantidade muito grande de dados em transmissão, o travamento ocorria e não era registrado nos logs do sistema operacional.

Detalhes da solução:

Sistema Operacional: Windows 7

Modem: Huawey E1756 MODEM USB 3G

Discador: VIVO Internet 11.302.06.20.149, plugins 1.01

Operadora: VIVO

Alem das funcionalidades do contexto de persistência também podemos contar com as funcionalidades extras que foram desenvolvidas pelo time de desenvolvimento, hoje pertencente a JBoss. Estou falando do pacote hibernate-tools.jar, contido no plugin feito para o eclipse, com o intuito de auxiliar no processo de configuração, mapeamento, importação de schemas e mecanismo de interpretação e execução de HQL. O link para download do plugin encontra-se aqui.

Tive a necessidade de fazer com que todo o schema fosse exportado para o banco de dados ao executar uma simples task do Ant. Funcionalidade que facilitaria muito a vida da equipe ao modificar o mapeamento das entidades do projeto, sendo apenas necessário executar a task para exportar as modificações para o SGBD. Para isso, desenvolvi uma task personalizada para solucionar esse problema. A task funcionava bem, mas chegou um ponto que não nos atendia. Portanto, vi que uma boa alternativa seria utilizar as tasks do hibernate-tools.

O pacote hibernate-tools.jar contem um conjunto de tasks que permitem a execução de procedimentos básicos de persistência através de simples tasks do Ant. As tasks são variadas, portanto é possível utiliza-las para; exportar schemas, gerar os inserts do mapeamento em um arquivo .sql, gerar os hbm.xml (se não tiver utilizando anotações) entre outras coisas. Mais um detalhe: o pacote hibernate-tools.jar é completamente independente do plugin.

A configuração para utilizar as tasks a princípio é simples, porém levei um tempo para acertar, já que meu projeto estava mal configurado e gastei muito tempo para descobrir o problema. Vou levar em conta que o seu projeto está devidamente configurado e fazendo todas as operações básicas (insert, update e delete) no banco de dados.

Para uma simples exportação do schema para o banco de dados, a primeira coisa que você deve fazer é adicionar o pacote hibernate-tools.jar no classpath do projeto. Após isso é necessário incluir uma referencia a classe que representa a task. Nesse caso, assim como está abaixo:

<taskdef name="hibernatetool" classname="org.hibernate.tool.ant.HibernateToolTask" classpathref="path.lib" />

Após isso, é necessário incluir um target que fará todo o trabalho sujo. Nessa target deve conter, dentro do <hibernatetool>, no mínimo as tasks <annotationconfiguration/> e <hbm2ddl/> para fazer o processo de configuração e a exportação de todas as configurações de mapeamento incluídas nas classes. Vamos ver o detalhe abaixo:


<target name="generate" depends="compile">
<hibernatetool destdir="${dir.build}/generated">
<classpath>
<path location="${dir.out.classes}"></path>
</classpath>
<annotationconfiguration propertyfile="${dir.out.classes}/hibernate.properties"  configurationfile="${dir.out.classes}/hibernate.cfg.xml" />
<hbm2ddl drop="true" create="true" export="true" outputfilename="../schema.sql" delimiter=";" format="true" />
<hbm2dao />
</hibernatetool>
</target>

Reparem que é necessário ter os .class incluídos no <classpath/> como descrito acima, pois é daí que vem todo o mapeamento dos objetos. A propriedade <annotationconfiguration/> representa as configurações do seu SGBD (hibernate.properties) e das classes persistentes (hibernate.cfg.xml). Claro que o arquivo cfg.xml pode conter as configurações do SGBD mas eu achei melhor separá-los.

A task <hbm2dll/> é o elemento principal do processo de exportação do schema. Nela é possível definir se, ao exportar o schema, irá dropar as tabelas existentes e criar uma nova estrutura e além do mais irá criar um arquivo .sql contendo tudo o que foi feito no banco.

Adicionei a task <hbm2dao/> apenas para mostrar o DAO gerado conforme as entidades geradas. Acredito que isso seja útil para os projetos que não utilizam o suporte aos DAOs do Hibernate do Spring.

Bom pessoal, esse foi um processo que me atendeu perfeitamente nos projetos que desenvolvo, portanto, segue a dica para os leitores. Chega de ficar mexendo nas propriedades hibernate.hbm2ddl.auto create-drop e escrever tarks personalizadas para essa tarefa.

[]s

Com a curiosidade a tona decidi baixar o JAR, junto com os fontes do projeto, para ver do que se tratava e como era feito essa proeza. Notei que era um framework que fazia um processo de serialização da JVM de forma mais elaborada com logs, transações e integridade dos objetos persistidos. Ou seja, um mecanismo de persistência simples e que atendia a aplicações de pequeno porte. A empolgação foi tanta que até fiz minha monografia da faculdade sobre ele.

Ter disponível um framework que implemente um novo conceito de persistência chamou atenção não só de brasileiros, tanto que muitos desenvolvedores se juntaram no desenvolvimento do frameworks, plugins para Eclipse e uma implementação do SQL para consultar objetos “prevalecidos”. Ma o que aconteceu? Porque não vingou? Bom, a resposta dessas perguntas eu não tenho. As suposições são muitas. Uma delas seria a aceitação e a barreira da mudança de paradigmas. Muitos até tiveram boa intenção de utilizar em suas aplicações. Um exemplo disso é o ThinFeeder e portal JavaFree. Lembro que o JavaFree teve uma série de problemas de concorrência ao disponibilizar o portal com a camada de persistência com prevayler.

Deixei de acompanhar a evolução do framework já faz um tempo, acredito que tenham resolvido os velhos problemas de concorrência, portanto não tenho em detalhes das melhorias e de novas funcionalidades do framework. Porém, acredito que seria uma boa oportunidade de investir na evolução desse framework polêmico. Quem tiver curiosidade o site do projeto está aqui.

O projeto encontra-se maduro, porém, a quebra de paradigmas ainda é uma barreira para a adoção do framework em suas aplicações. Tentar aceitar que um framework de persistência de objetos possa dar conta de suas aplicações tendo uma série de SGDBs disponíveis realmente é uma coisa difícil.

[]s

Os protocolos de roteamento nas redes P2P são os principais elementos para manter a conectividade entre os nodos. Assim como nas redse TCP/IP, a tarefa dos protocolos consiste principalmente no recebimento e encaminhamento de pacotes e busca de nodos. Porém os protocolos P2P são mais complexos, pois são inúmeras vezes mais abstratos e dinâmicos. Como as redes P2P consistem, na maioria das vezes, de protocolos localizados na camada de aplicação, segundo o modelo de referência OSI, muito de suas características são no momento desconhecidas da maioria dos profissionais da área.

Nesse post, estarei falando sobre o básico do básico de alguns protocolos, que considero os mais interessantes, para que possam ser implementados nas redes P2P.

Chord

O protocolo Chord é baseado no mecanismo de DHT – Distributed Hash Table. Esse protocolo consiste na utilização de chaves para mapear, localizar e remover nodos em uma rede P2P.

Seu funcionamento consiste em mapear os peers conectados a rede através de um código hash que identifica cada elemento. Com esse código, cada peer pode localizar e identificar seus vizinhos através de um emaranhado de peers conectados. A maneira como isso é feita consiste de uma única operação (lookup) que mapeio o endereço IP com o hash gerado.

Os DHTs diferenciam das tabelas tradicionais tabelas hash nos seguintes aspectos;

• Devem suportar a inserção e remoção de nós, pois será necessário atualizar o novo mapeamento dos nós.
• Outra questão é a necessidade de um protocolo de roteamento para que o mapeamento possa ser feito constantemente.

No caso do Chord, o protocolo de roteamento seria descartado para dar lugar ao consistent hashing.

Esse mecanismo mantem o mapeamento das chaves e nodos responsáveis por essas chaves. Com isso, torna-se desnecessário o conhecimento de todos os nós da rede por cada peer. Com isso, a escalabilidade da rede aumenta consideravelmente.

Pastry

O protocolo pastry atribui um identificador de 128 bits, também gerado através de uma função hash, baseada no endereço IP ou em uma chave publica do peer. Esse identificador é utilizado para localizar um nodeIp no universo P2P que consiste no universo de chaves. Com isso, podemos rotear uma mensagem, em uma rede de N nós, em O(log2bN).

O protocolo tem uma característica interessante. Ele roteia mensagens de um nó cujo nodeId esteja mais próximo da chave autorizada. Isto é feito da seguinte forma: a cada etapa do roteamento, um nó normalmente encaminha as mensagens para outro nó cujo nodeId compartilhe com a chave pelo menos um digito (ou b bits) a mais do que é  compartilhado com o nó atual. Se nenhum nó é conhecido, a mensagem é encaminhada para um nó cujo nodeId compartilha um prefixo com a chave e está numericamente mais próximo da chave do que o presente nó. Para suportar este procedimento deroteamento, cada nó mantém uma tabela de roteamento, um conjunto de vizinhanças e um conjunto de folhas.

Tapestry

O tapestry tem uma certa semelhança com o pastry. Entre essas semelhanças estão a utilização do sufixo/prefixo no roteamento. Com isso, quando a tabela de roteamento de um nó não possui não possui uma referência para um nó que não compartilhe o sufixo com a chave a mensagem é encaminhada para um nó numericamente mais próximo da chave do nó em questão.

CAN (Content Addressable Network)

O CAN possui uma abstração maior, podendo ser melhor compreendida, pois é baseada em um plano cartesiano de N dimensões. Esse plano é dinamicamente dividido entre todos os nós de maneira que cada nó possua sua própria zona, como abaixo:

O espaço virtual é usado para armazenar todos os pares (chave, valor) entre os nós participantes da rede. As chaves são mapeadas para um determinado ponto no espaço utilizando a nossa função hash. O par(chave,valor) é então armazenado no nó responsável pela zona onde o ponto se encontra. Quando um nó deseja encontrar o valor correspondente de uma chave, ele deve aplicar a mesma função hash para encontrar o valor correspondente a chave e então encontrar o nó que está procurando. Caso a pesquisa não tenha êxito, a busca é passada a seus vizinhos para que seja feita a busca até encontrar o nó na zona da rede.

Em minha opinião, esse é um protocolo mais adequado para os MMOGs, já que existe a possibilidade de dividir o espaço em zonas, talvez possa ser aplicada a mesma idéia do conceito de mundos e campos de visão. Mas isso ainda é pesquisa.

Referências

Utilizei algumas referências na elaboração desse texto, pois esses protocolos fazem parte de pesquisas na área de redes e muita coisa está sendo desenvolvida no momento, principalmente sobre a adaptação dos protocolos nos MMOGs.

Utilizei o texto de Carlos Kamienski, Eduardo Souto, João Rocha, Marco Domingues, Arthur Callado, Djamel Sadok, cujo título é; Colaboração na Internet e a Tecnologia Peer-to-Peer, publicado no XXV Congresso da sociedade Brasileira da Computação, e o texto de Guan-Yu Huang1, Shun-Yun Hu2, Jehn-Ruey Jiang3 com o título; Scalable Reputation Management for P2P MMOGs de Department of Computer Science and Information Engineering National Central University, Taiwan.

Nos próximos post s estarei disponibilizando uma visão geral sobre o “elefante branco”, porém o mais completo, do P2P, o JXTA.

]]> http://www.nelsonalone.com.br/2009/05/30/mmogs-sobre-p2p-protocolos-de-roteamento/feed/ 0 http://www.nelsonalone.com.br/2009/05/26/mit-robocraft-ensino-divertido-de-programacao-de-computadores/ http://www.nelsonalone.com.br/2009/05/26/mit-robocraft-ensino-divertido-de-programacao-de-computadores/#comments Tue, 26 May 2009 03:45:09 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=288

(More)…]]>

Fiquei curioso ao ler uma reportagem de uma revista informando sobre a iniciativa do MIT de disponibilizar o conteúdo de seus cursos na Web. O nome do projeto é entitulado de OpenCourses que consiste também da publicação de vídeos e exames sem a necessidade registro ou autenticação.

Passeando pelo tópico de Electrical Engineering and Computer Science, vi uma disciplina um tanto quanto curiosa: 6.370 Robocraft Programming Competition, é um curso de extensão que tem o objetivo de ensinar programação, de forma divertida, através de uma engine de simulação de uma batalha de robôs que são programados pelos alunos. Esse é um dos brinquedos que o pessoal do MIT utiliza nos momentos de lazer.

Software bem parecido com o projeto Robocode, antes patrocinado pela IBM, que oferece um ambiente de desenvolvimento completo para desenvolver o seu tanque e incluir a lógica de batalha. Um projeto interessante tido como auxílio ao ensino de programação. É válido ressaltar que tudo isso é feito com Java.

Simples dica de diversão geek.

Pelo fato da plataforma ser complexa, foram criados inúmeros frameworks com o objetivo de minimizar os detalhes. Entre os mais populares e robustos está o Globus ToolKit , recomendado pela Globus Aliance . O Globus ToolKit é um conjunto de ferramentas que tenta cobrir todas as necessidades relacionadas a Grid Computing. Porém, é complexa e ao mesmo tempo pesada.

Uma alternativa para aplicações de pequeno e médio porte é o Grid Gain. Framework escrito em Java, mantido por Nikita Ivanov, que demonstra ser muito eficiente e simples de utilizar, já que não necessita de muitas das funcionalidades contidas no Globus Toolkit.

Agora, se você for construir uma aplicação que roda na infraestrutura do LHC, SETI@HOME ou similares, aconselho você usar o Globus ou implementar um do zero.

A transmissão de arquivos digitais veio à tona com a utilização de software que utilizavam uma espécie de protocolo simples, porém desconhecida, o P2P. O Pear to Pear (Par para Par) é um protocolo descentralizado que não necessita de nenhum elemento que gerencie conexões entre dois pontos, transferindo a responsabilidade para o usuário e não para o criador do software. Advento que tornou popular a distribuição de softwares como Napster, Kaaza, EDonkey, Emule e entre outros derivados.

A tecnologia foi completamente disseminada e ao mesmo tempo marginalizada. Já que, sempre que possível, artistas, gravadoras, ou seja, profissionais que viam suas criações protegidos pelas leis da propriedade intelectual ser disseminadas como propaganda, criticavam erroneamente a infra-estrutura que permitia o compartilhamento da obra. Logo, o problema se alastrou com a possibilidade de compartilhar livros, filmes e software. O pior de tudo são as leis não podiam agir para proibir esse ato, já que não existia uma entidade centralizadora que permitisse, ou até mesmo, contribuísse para o compartilhamento de conteúdo digital.

O que as pessoas não davam conta é que o protocolo de compartilhamento, o principal ator de todo o processo, era utilizado em massa e mostrando a robustez do mesmo em uma rede gigantesca e de funcionamento em larga escala. Muitos não se davam conta da tecnologia que estava utilizando e no que poderia ser aplicada no futuro próximo.

Aplicações:

A utilização do protocolo de comunicação P2P para a resolução de problemas computacionais e construção de aplicações que poderiam usufruir dessa infra-estrutura foi projetada em pequena escala. Um exemplo disso foram os comunicadores MSN e Skype .

Era impossível de encontrar software que utilizassem a tecnologia, de forma expressiva, através de aplicações comerciais. Porém, em virtude das qualidades exploradas apenas por cientistas, era sim visível dentro dos laboratórios em diversas universidades espalhadas pelo mundo.

Cientistas e engenheiros perceberam o potencial da tecnologia através da ausência do elemento centralizador. Normalmente, elementos centralizadores, como servidores e datacenters, tornam elevados os valores das soluções propostas. Portanto, explorar o fator custo seria a chave para o sucesso da tecnologia na utilização em larga escala que também demonstrava ser flexível, permitindo também a colaboração mútua de usuários no redor do mundo.

Recurso que foi utilizado para a colaboração em diversos projetos importantes. Entre os mais famosos estão o projeto de mapeamento dos genes humanos, o Projeto Genoma, o sistema de busca de vida alienígena no espaço, o SETI@HOME e o ultimo porém não mais importante está o HLC . Esses projetos utilizam uma tecnologia derivada do P2P, chamada de Grid Computing que será discutida mais tarde. Essa tecnologia utiliza um modelo de protocolo P2P e um conjunto extra de funcionalidades que serão discutidas posteriormente, já que é o assunto quente do momento.

GAMES

Aplicar os recursos da tecnologia para o desenvolvimento de jogos é o objetivo das principais softwarehouses da área, principalmente em games estilo MMOG. A razão principal para o investimento nessa área é de cortar custos com servidores. Ou seja, o desenvolvimento de games é uma tarefa árdua. Requer investimento em áreas como design, desenvolvimento de software, antropologia, cinema e música. Produzir um bom produto para o usuário final requer investimento maciço nessas áreas, olha que eu não citei o pós game como a publicidade e marqueting do produto.

Os MMOGS são jogos que representa um mundo no qual usuários de diversas partes do mundo interagem seguindo o objetivo do game. Normalmente encaixam-se nesses gêneros jogos de RPG, já que devido a longevidade, o estilo adapta-se muito bem para os MMOGs. Jogos como World of Warcraft levaram o estilo a tona com boa jogabilidade e muita diversão.

No entanto, fazer bons jogos não basta. Quando se trata de MMOGs a interatividade entre os participantes é a parte mais complicada, já que existem pessoas de todo o mundo conectado ao servidor central aprendendo a jogar, travando batalhas, conversando, negociando itens, se fortalecendo,fazendo campanhas, fazendo alianças, entre outras coisas que a plataforma nos permite fazer. Para que tudo isso possa ser feito torna-se necessário um grande investimento na infra-estrutura que irá suportar essa demanda.

Neste ponto, a tecnologia descentralizada P2P entra em ação fazendo com que o investimento na infra-estrutura de MMOGs seja o mínimo possível em comparação com o anterior. Portanto, com a utilização da infra-estrutura P2P, toda a interatividade ficaria sob responsabilidade apenas dos participantes do jogo.

Bom, se isso é tão bom e lucrativo para os desenvolvedores, porque não foi implementado? A resposta é simples. Nesse ponto, a tecnologia se mostra imatura. Fazer com que todo o controle de interatividade fique com o usuário é uma faca de dois gumes. Com um ambiente centralizado já é extremamente difícil controlar os cheets(trapaça), imagina com o controle de tudo isso feito no cliente. Além do mais, nesse tipo de jogo é necessário que o usuário salve o estado atual, ou seja, seus pontos de habilidade, itens armazenados, energia, pontuação, etc. Se isso tudo for salvo na máquina do usuário seria uma grande oportunidade de usuários alterarem seus atributos para trapacearem.

O que eu citei aqui foi uma das barreiras que tecnologia necessitará resolver quando for utilizada para efetuar a comunicação entre os pares. Além disso, existe outros inúmeros problemas que devem ser resolvidos como: mecanismos de tolerância a falhas, reconhecimento de jogadores, alocação de jogadores em mundos, roteamento de pacotes através de peears, etc. Isso é assunto para outros post. Não vamos ficar só em jogos não é…

VOIP

A tecnologia de voz sobre protocolo da internet está em constante evolução. A necessidade de conversar sobre tarifas mais baratas, e através da internet, fizeram com crescesse a demanda sobre essa tecnologia. Com isso, criaram os protocolos H323 e SIP que visam a qualidade no tráfego de voz através dos protocolos de internet.

Até ai tudo bem. Mas onde está a aplicabilidade do protocolo sobre essas tecnologias? Na verdade, a aplicabilidade é feita a partir da integração das tecnologias de transmissão de voz com o P2P. Essa é uma idéia que já está sendo desenvolvida pelas empresas de celulares a aplicações móveis.

A integração dos protocolos de voz com o P2P consiste em utilizar a mobilidade e o para integrar e a flexibilidade do protocolo para possibilitar a comunicação VOIP entre telefones celulares através da internet.

Futuro do Protocolo

No momento, aplicações que utilizam protocolos P2P de forma massiva são escassas, principalmente pelo fato de ser um protocolo que não é visto com bons olhos para o usuário final. Porém, pesquisas em aplicações que tentam resolver problemas científicos utilizam a tecnologia de forma massiva.

No momento, pesquisar P2P, ou desenvolver pesquisas que utilizam a tecnologia, poderá ter resultados em longo prazo, principalmente pelo fato das tarefas executadas pela centralização serão todas feitas nos peers. Isso significa que tecnologias derivadas, como Grid Computing e Cloud Computing, tornarão tecnologias populares e acessíveis a todos os usuários como técnologia doméstica ou prestação de serviço.