Blog do Alone

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

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.

Java, Open Source Java, MIT, Programação, Robocode, Robocraft

No post anterior explanei um pouco sobre o mundo dos MMOGs e sobre a visão universal desse tipo de entretenimento  utilizando um  protocolo totalmente descentralizado. Não passei os detalhes, mas apenas analisando o título é perceptível que essa é uma tarefa que requer muita dedicação.

Atualmente os MMOGs, utilizando a arquitetura cliente-servidor, tornou-se um paradigma para a indústria (consumidores assíduos, desenvolvedores, empresas, etc). Praticamente todos os títulos que vão para as lojas tem como base a arquitetura cliente-servidor como mecanismo padrão de interação dos clientes. Como tinha afirmado, essa arquitetura é dispendiosa para as empresas que disponibilizam os acessos aos datacenters para jogadores.

Vendo por esse lado, não seria viável apenas distribuir o game? Bom, verificando o lado da empresa seria viável porém, a empresa perderia receita. Devido a isso, criar a infra-estrutura  de serviço é um passo fundamental, principalmente pelo pouco gasto que teria com infraestrutura.

A utilização do arquitetura P2P veio como um forma de amenizar os gastos com essa com datacenters. Porém, existe alguns obstáculos para a viabilidade dessa afirmação. Esses obstáculos variam de culturais e tecnológicos.

Obstáculos culturais

O elaboração de uma arquitetura descentralizada para a comunicação de hosts diretamente tem início nos primórdios da computação. Porém, houve uma evolução nesse conceito, fazendo que o termo “host” tornasse um elemento abstrato, flexível e virtual chamado peer.

Peer é a definição de um elemento dentro do contexto de uma rede P2P. Um peer pode ser qualquer coisa que se comunique com a rede como;  um pc, notebook, celular, ou seja qualquer dispositivo que tenha conectividade com a rede seja lá o que for. Dentro desse conceito, um pc, por exemplo, pode ter um ou diversos pares na rede P2P. Esse exemplo foi necessário para termos uma idéia de como é a conectividade entre os pares.

Agora, quais são os impactos culturais da sua utilização? A elaboração da arquitetura teve finalidade oposta a fama que teve com a s redes de compartilhamento de arquivos. O problema é que a arquitetura P2P caiu como uma luva para o desenvolvimento dos softwares de compartilhamento de arquivos existente. Gnutell, Kazzaa, Emule, Napster, entre outras, todas utilizam uma implementação (com particularidades) para a sua rede.

Essa, talvez seja a origem, dos problemas de violação dos direitos autorais que as gravadoras, editoras e produtoras de filmes tanto reclamam. As redes de compartilhamento tornaram fontes de troca de arquivos e com isso surgiu a forma mais eficaz da prática da pirataria.

Obstáculos tecnológicos.

A utilização da arquitetura P2P nos protocolos de compartilhamento de arquivos aumentou consideravelmente o tráfego na internet sendo que, hoje em dia, 40% do tráfego da inter vem das redes de compartilhamento de arquivos. Mas foram os poucos que viram as qualidades da arquitetura para os games. A conclusão foi simples; se existem uma enxurrada de bytes trafegando sobre essa arquitetura e cada vez mais tendo usuários adeptos, logo a arquitetura pode ser robusta.

Acredito que seja essa a iniciativa para modificar a camada cliente-servidor dos MMOGs para P2P. Mas para isso, existem atividades de adaptação da tecnologia e em alguns casos a adaptação do motor do game para a nova arquitetura.

Estudos e soluções

O MMOGs considerados mais divertidos são os que possuem mapas imensos e a possibilidade de personalizar o seu jogador. Fazer com que um peer consiga gerenciar elementos como esses, seria necessário possuir praticamente a mesma estrutura, inclusive datacenters, dos servidores para que ocorra a interação dos pares conectados na rede.

Esse é um problema clássico do que pode ocorrer em situações com grande quantidade de jogadores conectados, ou seja, um caos. Para resolver esse problema, ou pelomenos minimiza-lo, seria necessário desenvolver uma estrutura de mundos e submundos tornando o ambiente utilizável e com desempenho desejado. Para isso, seria necessário a construção de um mundo virtual 2D, ou mapa, dividido em células. As células existentes no game seria um peer da rede eleito seguindo critérios.

Esse conceito é bem parecido com o campo de visão de um jogador, ou sejam, se o jogador entrou no meu campo de visão então só a partir daí que o tráfego entre esses dois jogadores poderá surgir.

Bom, uma pergunta vem a tona: Como é feita a sincronização das informações que também não estão na minha área de visão? A necessidade de manter informações de outros jogadores que não estão dentro do “contexto” do jogador é necessário para manter o conjunto de informações do game como um todo. Records, ranck, mercados, guildas, etc. dependem desse tipo de informação. A pergunta em questão está sem resposta no momento mas, existem diversas soluções.

A solução que, a meu ver, mais se adéqua a necessidade seria a utilização de um servidor central para prover esse tipo de informação. Bom, nesse caso a estrutura de game não é mais 100% P2P? É isso aí. Em situações do cotidiano, no caso sem soluções, seria necessário manter a arquitetura cliente-servidor através de um servidor central para realizar a “contabilidade” do game, diminuindo a existência de shits.

O que acompanha as dúvidas da arquitetura nos games é principalmente a suposta facilidade de inclusão dos cheats no game, já que os arquivos de configuração seriam gravados no disco do cliente. Com isso, um desenvolvedor mais experiente poderia fazer engenharia reversa nos executáveis, verificar os arquivos que o game carrega e modifica-los conforme desejar. Porém, para que isso não aconteça, o game deve implementar inúmeras políticas de segurança como : criptografia, certificados digitais e principalmente implementar uma forma mais adequada a realidade atual, caso a empresa deseje faturar com o serviço do game.

O desafio para desenvolver a arquitetura nos MMOGs é grande. Tão grande também são as dúvidas referente ao aceite dos jogadores dessa tecnologia nos games, já que a arquitetura cliente-servidor é o padrão para esse tipo de game. Acredito que o principal desafio será encontrar a derivação do protocolo mais adequado para suportar o montante de informação referente a interação dos jogadores no game. Portanto, no próximo post detalharei alguns protocolos P2P e frameworks que mais se adequam a  essa finalidade.

T+ []s

games mmog, p2p