Blog do Alone » jxta

MMOGs Sobre P2P – JXTA

nelsonsozinho — Sat, 27 Jun 2009 16:56:37 +0000

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

MMOGs sobre P2P -> Protocolos de Roteamento

nelsonsozinho — Sun, 31 May 2009 00:57:47 +0000

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.