Blog do Alone

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.

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.

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.

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.

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.

P2P - Peer to Peer, games game, quake

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.

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

JXTA, Java, P2P - Peer to Peer Java, jxta, p2p

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.

Open Source, P2P - Peer to Peer can, chord, jxta, p2p, pastry, tapestry

O entretenimento eletrônico tornou-se um segmento econômico forte onde empresas de renome também querem se alojar nessa fatia de mercado que cada vez mais cresce. Empresas como Microsoft e Sony disputam a liderança do mercado através de seus consoles de ultima geração e com títulos cada vez mais empolgantes que enchem os olhos dos games maníacos que ficam vidrados com gráficos cada vez mais realistas e com som de primeira qualidade. Sem falar do banho da interatividade que a Nintendo disponibilizou no seu novo console que faz com que o “entretenimento familiar” fosse o ponto principal da estratégia de marketing da gigante dos games.

A iteratividade nos jogos eletrônicos pode ser considerada como elemento fundamental para o sucesso de um game, principalmente quando essa iteratividade também envolva inúmeros jogadores, coisa que torna possível com o a utilização da internet para essa finalidade. Títulos que utilizam a rede como alternativa para a interatividade de jogadores são considerados completos e divertidos pelos consumidores. Dês de 1998 temos os sucessos da ID Software como Quake (I,II,III,IV) em conjunto com a Epic Games com a séria Unreal e a modificação mais famosa do mundo, o Counter Strike, levou esse gênero a inúmeros PCs no mundo.

O enredo adventure, strategy e RPG não podia ter ficado de fora. Levando pelas características do estilo como a existência de mundos, raças, povos, mapas imensos e colaboração, houve a necessidade de criar um ambiente que também suportasse as características do estilo através da rede, uma coisa semelhante a um RPG Online. Tudo isso, de forma com que o universo que precede o jogo fosse livre para exploração, interação, organização, ou seja, o mais parecido com o mundo real. Acredito que dessa forma surgiu o termo “massivo” (o primeiro M de MMOG).

Pra quem não sabe, MMOG significa Massively Multiplayer Online Game, o termo não tem uma tradução, mas por alto significa Jogos Online para Múltiplos Jogadores.  A demanda pelo gênero cresceu de forma absurda, consequentemente foi necessário uma grande infraestrutura para suportar inúmeros jogadores online, o acesso aos servidores dos jogos começou a ser cobrado para cobrir as despesas, patchs e mais patchs de atualização foram necessários para evitar os hacks nos jogos (trapaças). Foi dessa forma que grandes investidores descobriram um modelo de negócio sustentável e que desse lucro rápido.

Grandes empresas investiram pesado nesse novo modelo para tentar vender não apenas títulos, mas também uma forma de mensalidade para acessar os servidores da fabricante. Coisa que aconteceu com World of Warcraft. Muitos conseguiram criar servidores de forma ilegal, mas os melhores serviços são sempre os disponibilizados pela fabricante ou autorizados, pois não tem muitos bugs e são mais seguros (livres de trapaças).

Como já tinha dito, esse tipo de entretenimento tem mercado e o retorno é de médio a pequeno e médio prazo, porém, o investimento em infraestrutura de servidores é imensa. Um exemplo disso foi a empresa brasileira, desenvolvedora de jogos,  Hoplon, cujo principal título é o Taikodom. O game está sendo distribuído de graça, até o momento, e devido essa estratégia foi necessário criar uma grande infraestrutura de servidores que suportasse a massa de jogadores interagindo ao mesmo instante. Essa necessidade resultou da parceria com a gigante IBM trazendo mainframes para que, até o momento, suportasse os primeiros jogadores do título.

A necessidade de imensas estruturas para manter jogadores interagindo é extremamente cara, ainda por cima, não é novidade as grandes empresas desenvolvedoras dessa modalidade de game cobrar mensalidades para usufruírem do acesso ao ambiente. Muitos concordam e outros discordam, mas seria bom se a banda larga brasileira fosse de qualidade e o mesmo fosse com o serviço, sendo assim poderíamos apenas opinar. Conheço pessoas que são adeptas ao World of Warcraft, jogam horas e horas, que reclamam um absurdo da qualidade do serviço prestada no acesso aos servidores da Blizzard.

Vendo o grande gasto com infraestrutura para manter MMOGS em funcionamento, pesquisadores e empresas do ramo viram uma alternativa nos protocolos P2P como uma forma de tentar minimizar, ou até mesmo tirar, o gasto em serviços, passando toda a responsabilidade para o cliente seguindo uma série de regras que envolvem desempenho como objetivo de minimizar ao máximo os recursos computacionais utilizados pelo cliente.

Vendo por outro lado, o protocolo P2P seria uma alternativa viável para tal. Podemos ver aplicações que rodam com sucesso sobre esse protocolo, não só sistemas de compartilhamento (na qual é mais conhecido devido as redes de compartilhamento) mas também software mensageiros como MSN e SKYPE. Aplicações como essas necessitam apenas da autenticação com um servidor do mesmo segmento e o resto é tudo feito pela aplicação cliente, ou seja, a transmissão de mensagens, compartilhamento de arquivos e até mesmo a transmissão de voz (se o software suportar) é feita apenas pelos atores que estão participando da troca de informações no momento.

Idéia como essa manteve acesa a necessidade das empresas do ramo investir em pesquisa na arquitetura P2P para que possa tornar vantajosa sendo segura, simples, robusta e que atenda ao máximo os usuários adeptos dos títulos. Com isso, toda a responsabilidade de interação, transmissão e desempenho ficaria sobre os recursos do cliente na qual o titulo está sendo jogado.

Bom, mas que vantagem o cliente teria se toda essa carga estaria sobre o cliente?Essa deve ser a pergunta que você deve estar fazendo. Até o momento a vantagem está praticamente TODA para a empresa desenvolvedora do título que não terá que investir em uma infraestrutura de servidores. A carga fica toda como cliente sim. Para isso, existem pesquisas feitas sobre o conjunto de protocolo que envolve a sigla P2P para que essa carga se torne a mínima possível e que seja irrelevante  para o cliente. Ao mesmo tempo, existem pesquisas feitas na utilização do esquema de mundos virtuais, onde cada usuário tem o seu mundo e o tráfego do serviço fica ativo apenas aos jogadores que participarem do seu mundo. Mas isso é assunto para o próximo post, onde darei mais detalhes sobre esse mundo empolgante dos MMOGs.

Isso é apenas uma pequena introdução sobre o que pode acontecer no mundo dos MMOGs, especificamente na camada de comunicação, e o que pode vir daqui pra frente nos games. Pesquisas financiadas por softwarehouse e renome para desenvolverem uma plataforma utilizável que funcione com alguma implementação P2P para que alguns títulos possam ser desenvolvidos para testar a plataforma. No próximo post falarei um pouco sobre os tipos de protocolos P2P.

P2P - Peer to Peer, games games, mmog, p2p, r&d

No fim da década de 90 nos deparamos com o formato de arquivos de áudio chamado mp3, que eliminava a maioria das freqüências não audíveis ao homem para comprimir o seu conteúdo, tornando a transmissão de faixas de CDs possíveis através desse formato extremamente compacto. A partir desse momento, iniciou-se uma grande revolução na comercialização musical e conseqüentemente a ira das gravadoras que não se adéquam, até hoje, ao novo modelo de negócio existente.

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.

Grid Computing, Open Source, P2P - Peer to Peer