Saga Quake. Engine e seus protocolos multiplayer

October 24th, 2009 No comments

Quando joguei Quake I online pela primeira vez fiquei absolutamente fascinado pela possibilidade de jogar, no mesmo mapa, com uma série de jogadores conectados querendo destruir um a outro. A empolgação com essa novidade foi tanta que o excesso de LAG não era problema. Por conseqüência, as desagradáveis paradas no game eram constantes, seu player morria e você não se quer sabia quem matou você, porém, mesmo com esses problemas não deixava de continuar jogando. A verdade é que os desenvolvedores do título se preocuparam apenas com o movimento que era feito de um poto X para um Y e transmitir as coordenada via broadcast para outros players. Diga-se de passagem que esse foi o primeiro títulos (ou um dos primeiros) desenvolvidos com a possibilidade de travar batalhas pela Internet.

O idealizador disso tudo foi nada menos do que John Carmak, fundados da ID Sofware que anteriormente colocou no mercado títulos de sucesso como Wolfenstein e Doom (títulos que alavancaram o estilo de “jogos de primeira pessoa”). Carmak, como desenvolvedor talentoso, evoluiu a modalidade com o desenvolvimento da engine 3D para seus títulos e posteriormente o protocolo multiplayer que começou a vir a partir dos títulos posteriores.

carmack

Carmak foi um gênio ao desenvolver e evoluir a engine dos primeiros jogos de primeira pessoa para o cenário que conhecemos hoje. Méritos para também para o desenvolvimento e evolução do protocolo de jogo. Fazendo com que o mesmo ficasse cada vez mais limpo e refinado, tanto que, na maioria das vezes a animação era mantida quando havia muito lag. Os problemas surgiram quando havia muitos jogadores no mesmo mapa, nesse ponto tínhamos a latência da rede e do processador para processar os movimentos de tantos jogadores. Uma curiosidade foi o fato de ter desenvolvido seus primeiros títulos iniciais sobre um NeXT em um NeXTSTEP OS e posteriormente ter migrado para a plataforma Windows.

NeXTSTEP_desktop

Os títulos da ID ficaram famosos juntamente com o estilo de jogos muiltiplayer de primeira pessoa. Fabricantes desenvolveram seus títulos que também tinha o mesmo esquema de combate e, diga-se de passagem, utilizavam a mesma engine para seus jogos de primeria pessoa (a engine é um assunto para o próximo blog).

Ao desenvolver o título de maior sucesso, o Quake III, que foi, em minha opinião, o melhor título, engine e protocolo, possibilitou com que os combates fossem cada vez mais divertido e fáceis de jogar.  Essa “leveza” nos jogos muitiplayer tornou famoso, não só a engine, mas também o protocolo de comunicação que era bem mais evoluído. A forma de jogo é simples, mapas são abertos e ao mesmo tempo bem limitados, ou seja, não são tão extensos como os títulos anteriores já que a finalidade era apenas batalhas multiplayer.

quake3arenatz8

Escrevi esse post não apenas por gostar dos títulos da ID (mesmo sem lança nada após o Quake 4 e o Doom 3), mas especificamente pelo protocolo de comunicação muitiplayer da ID. O melhor de tudo é que a ID Software disponibilizou toda engine e protocolo do Quake III na área de download da ID Software como GPL. Portanto, o próximo passo é fazer compilar os fontes e estudar os fontes do protocolo.

visual_studio

A leitura dos fontes não é tão complexa, acredito que me ajude em melhorar meus protocolos desenvolvidos para P2P. No site a engine está configurada para abrir no Visual C++ da Microsoft e abriu perfeitamente no meu Visual Studio 2008 após pedir para remover os arquivos do Source Safe. Pra quem gosta essa é uma excelente oportunidade. Estarei postando futuramente sobre os trabalhos futuros.

Categories: P2P - Peer to Peer, games Tags: ,

Um dia o pilar quebra

October 7th, 2009 No comments

Quando uma empresa investe tempo e mão de obra para desenvolver algum framework para seu uso próprio, ou até mesmo minimizar a complexidade da utilização de outros, significa que o nível de maturidade em uma determinada tecnologia se elevou ao ponto tornar o processo de desenvolvimento, com o uso dessa tal tecnologia, mais ágil.

Estratégias utilizadas para obter essa flexibilidade variam dês de desenvolver templates, classes abstratas, soluções que utilizam padrões de projetos que visam a reutilização, desenvolver forks de frameworks open source para se adequarem ao modelo de desenvolvimento da empresa. Essas alternativas visam poupar tempo com situações de um cadastro simples, persistência auditada, autenticação, etc.

Estratégias como essas vieram a tona nos tempos do Struts e dos EJBs 2.*, já que era notável a necessidade de eliminar os detalhes de implementação do struts (forms, templates, actions customizadas, autenticação, acesso a recursos de serviços distribuídos, etc). Já os EJBs, mesmo em versões antigas, demonstram robustez, confiabilidade e segurança para as aplicações corporativas. Daí veio os patterns J2EE, XDoclets com a finalidade de integrá-los e diminuir, pelo menos um pouco, o grau de acoplamento entre os serviços.  Com isso, a estratégia de diminuir o tempo de desenvolvimento seria válido devido a complexidade dessas tecnologias e da grande quantidade de arquivos XML necessário para configurá-los.

Essas tecnologias sobreviveram até hoje e ainda recebem manutenção de empresas que as tem como base de seus serviços. É justificável, pois muitos recursos investidos para o aprimoramento dessas ferramentas geralmente são altos e algumas vezes são peças-chave em vários projetos. Na maioria das vezes, principalmente em projetos com particularidades específicas, as soluções desenvolvidas para o mesmo geralmente tornam-se parte do framework da empresa para, caso necessite, ser utilizada em projetos futuros, fazendo o framework “inchar”.

Vendo esses problemas agora vem uma pergunta no ar: Mas porque cargas d’água fizeram essa joça? Porque deixaram isso acontecer? Ninguém previu isso? Eu também queria a resposta para essas perguntas, porém, muitos fatores podem ter ajudado a formar essa bola de neve; falta de experiência da equipe, má vontade, individualismo, falta de visão. Quem já trabalhou ou trabalha em corporações que tem essa mentalidade sabe do que eu estou falando. É nesse ponto que a compreensão dos pilares que a empresa dispõe para o desenvolvimento de seus projetos.

Quando uma empresa estabelece um pilar sua base deve ser rígida. A rigidez significa aceitar a evolução constante do código e ao mesmo tempo das libs, frameworks e JVMs que serão utilizadas futuramente nos projetos da empresa. Caso isso não aconteça, a base do pilar não suportará a evolução do framework podendo até se quebrar. Com isso, os bugs nos projetos que utilizam uma infra-instrutora arcaica vêm a tona. Quem trabalha especificamente com Java deve ter experiência com essa abordagem.

Uma boa equipe, sendo bem gerenciada, desenvolveria um framework que fosse, no mínimo, flexível. De forma que suporta, no mínimo, atualizações de bibliotecas intermediárias assim como atualizações da JVM, já que está sempre em constante evolução e cada momento seu desempenho está sendo sempre incrementado. Acredito que medidas simples tornariam a infra-estrutural de uma empresa evoluindo corretamente e principalmente independente de framework.

Isso é possível de fazer? Sim! Existem provas? Sim e são bem claras. É possível encontrar isso constantemente em projetos open source. M uma simples lida nos changelogs é possível ver a constante atualização de bibliotecas do projeto, substituição de jars e suas adaptações conforme as mudanças. Isso é um pouco trabalhoso porem recompensável, pois a base do pilar fica cada vez mais forte.

A linguagem Java, juntamente com a JVM, está em constante evolução. Desenvolver projetos (ou frameworks) fadados a utilizar uma versão específica da JVM é desperdício de tempo. Projetos como esses dificilmente suportarão a evolução, a longo prazo, de seus elementos fundamentais (JVM e frameworks). As mudanças ficarão restritas apenas a uma versão específica de sua estrutura, portanto caso cresça muito o pilar irá se partir.

[]s

Categories: Java Tags: ,

Distribuir conteúdo de graça. Melhor maneira de vender um produto pela internet

September 4th, 2009 No comments

Quem diz isso é o editor chefe da Wired, Chris Anderson, uma das revistas mais prestigiadas de tecnologia. Faz circular idéias controversas sobre novos modelos de negócio online. Em uma breve entrevista com a ISTOÉ sobre seu novo livro, Free o futuro dos preços, afirma que “A internet funciona como força destruidora”.  Analisando a frase não deixa de ser verdade. É só olhar para trás e ver o que o formato MP3 fez com a indústria da música.

Segundo Anderson, a maneira de vender um produto pela web corresponderia a disponibilizar cerca de 90% do produto e cobrar pela utilização dos outros 10%. Seria uma atitude semelhante tomada pelas empresas de software, distribuir um produto e cobrar apenas o suporte. No caso de serviço a visão seria no nível macro, já que é possível mensurar e dividi-lo facilmente em elementos (serviços) free e vendáveis.

É complicado ter em mente esse conceito e olhar para o Second Life e o MySpace como exemplos que não deram certo, ou melhor, não levaram vantagem ao utilizar esse conceito. Não que discorde, mas acredito que as empresas disponibilizam um tipo de serviço e cobram por outro. Um exemplo disso é o Google; o negócio do Google são as buscas e ganham com propaganda.

[]s

Quem diz isso é o editor chefe da Wired, Chris Anderson, uma das revistas mais prestigiadas de tecnologia. Faz circular idéias controversas sobre novos modelos de negócio online. Em uma breve entrevista com a ISTOE sobre seu novo livro, Free o futuro dos preços, afirma que “A internet funciona como força destruidora”. Analisando a frase não deixa de ser verdade. É só olhar para trás e ver o que o formato MP3 fez com a indústria da música.

Segundo Anderson, a maneira de vender um produto pela web corresponderia a disponibilizar cerca de 90% do produto e cobrar pela utilização dos outros 10%. Seria uma atitude semelhante tomada pelas empresas de software, distribuir um produto e cobrar apenas o suporte. No caso de serviço a visão seria no nível macro, já que é possível mensurar e dividi-lo facilmente em elementos (serviços) free e vendáveis.

É complicado ter em mente esse conceito e olhar para o Second Life e o MySpace como exemplos que não deram certo, ou melhor, não levaram vantagem ao utilizar esse conceito. Não que discorde, mas acredito que as empresas disponibilizam um tipo de serviço e cobram por outro. Um exemplo disso é o Google; o negócio do Google são as buscas e ganham com propaganda.

[]s

Categories: Notícias Tags: , ,

Hibernate: Schema export através de tasks do ANT

August 27th, 2009 No comments

É inegável que o hibernate é um excelente framework de mapeamento objeto relacional. Seus recursos de mapeamento, persistência, transação simplificadas, suporte a queries SQL, HQL, criteria, entre outros, justificam a sua utilização em massa pela comunidade Java. Não foi por acaso sua utilização como modelo para a especificação JPA.

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

Versão Genial de Stand By Me

August 8th, 2009 No comments

Não costumo adicionar conteúdo off-toppic nesse blog mas, pra quem gosta de boa música, essa versão de Stand By Me (John Lennon) com artistas de rua é brilhante. Parabéns ao pessoal da SXSW.

[]s

xLDen>pt GoogleC
Parabens
Categories: Off-Toppic Tags:

Por onde anda o Prevayler ?

August 1st, 2009 1 comment

Lembro-me como fosse hoje quando, fuçando na net, encontrei um texto escrito por Klaus Wuestefeld. O texto iniciava com uma pergunta: Você ainda usa banco de dados? A primeira vista aparentava ser um texto provocativo e por isso decidi da uma lida. Ao ler o texto, o que me chamou mais atenção, foi o fato do framework ser 10.000 vezes mais rápido que bancos de dados relacionais.

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

HTML para formatar texto

June 29th, 2009 1 comment

Gosto muito dos editores web, como TINYMCE, YOU e FCKEditor pois conseguem incluir formatação de texto com HTML. Facilitam muito o trabalho dos desenvolvedores para incluir soluções complexas de edição de texto. Essas ferramentas são simples de integrar e fáceis de usar, já que é só incluir os arquivos no diretório do projeto e fazer uma chamada simples na página que queira incrementar um textbox. Porém, nem tudo são flores. O problema começa quando existe uma necessidade de exibir o texto, em HTML, salvo por esses editores em PDF.

Normalmente, para os desenvolvedores JAVA, a primeira opção está na utilização do IReport para desenhar relatórios. Portanto, normalmente é feita o desenho, adaptação do relatório com a engine (itext e ireport) na aplicação e pós isso passando a string (ou consultado diretamente) para ser “montada” com o PDF. Consequentemente, o texto será exibido com as tags de formatação HTML. Bom, como podemos fazer com que o texto, fruto dos editores que utilizam formatação HTML, possa ser exibido de forma adequada e com sua devida formatação?

Existem duas alternativas:

  • Caso você utilize uma versão 2.5, ou superior, do IReport, pode marcar a opção Marckup, conforme a figura abaixo. Com isso, todo texto passado será feito um parse para ser exibido apenas o texto com o mínimo de formatação. O problema é que o processador HTML é fraco e não aceita todas as tgs documentadas no W3C.
  • Outra solução seria a solução mais trabalhosa; fazer o parse manual com o JTidy.

ireport_marckup

JTidy é uma biblioteca utilitária para manipulação de arquivos HTML que permite checar sintaxe e a manipulação completa do conteúdo HTML. Com esse utilitário é possível fazer o parse do texto e extraindo o conteúdo passado para o relatório. Porém, caso for necessário utilizar formatação complexa será necessária outra abordagem, já que o conjunto de ferramentas IReport não suporta a formatação completa de documentos HTML. Tomara que os desenvolvedores aprimorem o processador HTML da ferramenta para que possa suportar formatação completa, inclusive o suporte a CSS.

T+

xLDen>pt GoogleC
COM
Categories: Java Tags: , , , , ,

MMOGs Sobre P2P – JXTA

June 27th, 2009 No comments

Olá pessoal,

Dando continuidade na série MMOGs Sobre P2P, apresentarei aqui mais um protocolo para redes P2P que, seguindo algumas premissas que, pode ser utilizado como protocolo de comunicação de peers participantes de games.

Os Games atuais estão exigindo cada vez mais recursos de hardware para apresentar gráficos com maiores detalhes, velocidade e melhor som. Em conjunto com essas características chave está também a conectividade para ter maior interação do game com outros personagens.

Hoje em dia, a camada de conectividade dos MMOGs é desenvolvida utilizando protocolos de baixo nível, devido ao grande úmero de informação que necessita ser transmitida entre os participantes do game. Esses protocolos são desenvolvidos para funcionar apenas na arquitetura Cliente-Servidor, dessa forma, a latência não vai depender apenas da rede, também dependerá do servidor.

Protocolos de alto nível resolvem muito dos problemas de conectividade, porém possuem limitações de latência na transmissão dos dados para o receptor. A explicação para isso é simples. Muitos desses protocolos utilizam XML como mensagens de comunicação. O JXTA é um desses protocolos.

Devido a essa característica existir também no JXTA o desempenho do protocolo perde desempenho, porém ganha em conectividade e flexibilidade. Isso não apenas por ser um protocolo que troca mensagens baseadas em XML mas, por ter uma estrutura completa, repleta de sub-divisões, interfaces e arquitetura bem definida, tudo isso faz do JXTA, não apenas um protocolo, mas um conjunto de protocolos que pode ser utilizado para solucionar problemas de conectividade entre diversos peers em um ambiente P2P.

O que é JXTA.

JXTA não é apenas um protocolo, e sim um conjunto de protocolos encapsulados e organizados com base em suas atividades de empacotamento de forma independente. Esses protocolos garantem a confiabilidade e o roteamento das mensagens que são direcionadas aos peers e grupos.

Protocolos

O JXTA disponibiliza seis protocolos que podem trabalhar em conjunto para prover descoberta, organização, monitoramento e comunicação entre os peers. Esses protocolos são:

  • Peers Resouver Protocol: Consiste de um mecanismo onde os peers podem enviar consultas a rede através de mensagens para obter o conhecimento de alguns recursos existentes na rede. Consistas são direcionadas a todos os grupos ou a um grupo espefífico.
  • Peer Discovery Protocol: Consiste de um recurso de publicação e descoberta de recurso utilizando Advertise. Cada recurso disponibilizado por um peer são enviadas advertise para toda a rede com o objetivo de disponibilizar o serviço. Os advertise são documentos XML que contem informações do peer e dos recursos disponibilizados por eles.
  • Peer Information Protocol: Mecanismo que os peers obtém status de outros peers.
  • Pipe Binding Protocol: Consiste no estabelecimento de um canal virtual de comunicação entre um ou mais peers.
  • Endpoint Routing Protocol: É um mecanismo que permite descobrir rotas para enviar mensagens para um determinado peer. É utilizado especificamente para a descoberta de rotas entre peers.
  • Rendezvous Protocol: Mecanismo na qual os peers podem (ou não) propagar serviços. Este protocolo permite o envio de informações dos peers ou serviço que estão sendo monitorados pelo peer em questão. É utilizado em conjunto com o Peer Resolver Protocol e o Pipe Binding Protocol para propagar mengagens.

protocolo

Cada protocolo citado é independente dos demais. Um peer não requer a implementação de todos os protocolos da arquitetura JXTA, apenas implementa os protocolos que são necessários para o seu uso. Para prover um funcionamento padrão de um peer em uma rede JXTA deve apenas implementar dois protocolos; o Peer Resolver Protocol e o Endpoint Routing Protocol. Esses dois protocolos contem as principais funcionalidades que um peer deve ter na rede, já que é exigida na documentação devido a interoperabilidade com o core do JXTA.

Utilização da Arquitetura nos Games

A arquitetura, juntamente com o modelo de implementação dos protocolos, são bem completos. Com isso, o JXTA é o conjunto de protocolos mais completo quando se trata de arquitetura P2P. Porém, para muitos ele é tido como um elefante branco do P2P.

O conjunto de protocolos disponibilizado pela arquitetura é realmente completo, possibilitando um conjunto de ferramentas para o desenvolvimento de soluções que funcionem sobre uma arquitetura de rede P2P. Porém, o conjunto de protocolos utilizado em larga escala com inúmeros peers demonstra algumas falhas imperceptíveis para algumas aplicações porém, cruciais para os games.

Através de alguns testes de performance com vários grupos, inclusive grupos fora de uma intranet, deixaram a desejar em performance a interoperabilidade. Em alguns casos os grupos que se encontravam fora da rede não conseguiam estabilizar a conexão. Em alguns casos, não era possível encontrar recursos em NATs distintas.

Essa afirmação é válida quando utilizamos alguns dos recursos da arquitetura. A implementação de alguns dos recursos são complexos, principalmente o fato de se estar em atrás de um Firewall com uma NAT. Dentro dessa situação, a comunicação nem sempre é boa, sendo necessário horas a mais para solucionar problemas desse cotidiano.

A descoberta de recursos (grupos, peers e serviços) é lenta, principalmente quando testado em uma rede grande como a Internert. Falo isso pensando nos MMOGs que implementarem sua camada de rede P2P utilizando essa arquitetura. De certa forma ficaria inviável a busca por jogadores na rede, podendo chegar ao ponto de ter grupos de jogadores espalhados e não interconectados.

Acredito que a flexibilidade e a grande quantidade de recursos disponibilizados pela ferramenta ainda não dão suporte completo a imensa troca de pacotes nos games. Não quero afirma com isso a total deficiência da arquitetura, pelo contrário, já que o conjunto de protocolos JXTA está na base do mecanismo de cluster do Glassfish. Por sinal, muito bem implementado e funcionando perfeitamente. Talvez um fork da arquitetura visando apenas na otimização da arquitetura para os Games solucionaria o problema.

A arquitetura JXTA encontra-se nesse momento na versão 2.5 e possui um completo conjunto de soluções voltadas para P2P, inclusive pacotes para c++, .Net e uma adaptação para Mobile JME. Com esse leque de opções tão variado, o JXTA é a melhor opção para desenvolver aplicações P2P escaláveis porem, o desenvolvimento de games como camada de comunicação ainda não é uma boa opção devido latência na transmissão de pacotes e pelo, ainda lento, mecanismo de descoberta de recursos.

Fontes: Especificação JXTA e Documentação

Categories: JXTA, Java, P2P - Peer to Peer Tags: , ,

MMOGs sobre P2P -> Protocolos de Roteamento

May 30th, 2009 No comments

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.

chord1

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.

patry1

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:

can1

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.

MIT Robocraft – Ensino divertido de programação de computadores

May 26th, 2009 No comments

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.

chp_robocraft

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.

robocraft1

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.