2007.2TCC RoberioKielmann 09 25 final

U

E

F

S

U

M

M

IDDLEWARE

P2P

PARA

J

OGOS EM

R

EDE

A

:

R

K

A

F

M

C

C

E

C

Orientador: Daniel G. Costa

Co-orientador: João Batista da Rocha Junior

Feira de Santana, 06 de agosto de 2008.

R

OBÉRIO

K

IELMANN

A

LMEIDA

F

ILHO

U

M

M

IDDLEWARE

P2P

PARA

J

OGOS EM

R

EDE

Trabalho de conclusão de curso apresentado como parte das atividades para obtenção do título em Engenharia de Computação pela Universidade Estadual de Feira de Santana.

Orientador: Daniel G. Costa

Co-orientador: João Batista da Rocha Junior Feira de Santana, 2008

ERRATA

Autoria: Robério Kielmann Almeida Filho Título: Um Middleware para Jogos em Rede

Trabalho de conclusão de curso apresentado como parte das atividades para obtenção do título em Engenharia de Computação pela Universidade Estadual de Feira de Santana. Os componentes da banca de avaliação, abaixo listados,

consideram este trabalho aprovado.

Nome Titulação Assinatura Instituição

AGRADECIMENTOS

Agradeço a todos os que me ajudaram na elaboração deste trabalho, em particular aos coordenadores do Laboratório de Pesquisa que disponibilizaram o ambiente para o desenvolvimento e testes do middleware aqui apresentado.

As grandes coisas são muitas vezes mais fáceis do que aquilo que se pensa

RESUMO

A área de jogos computadorizados no Brasil vem crescendo consideravelmente nos últi-mos anos e o uso de motores de jogos e ferramentas RAD (Rapid Application Development) torna-se essencial para o desenvolvimento, permitindo adicionar recursos sofisticados aos jo-gos. Dentre as áreas crescentes, destacam-se os jogos em rede como uma forte tendência do mercado de entretenimento, uma vez que os jogadores querem interagir com outros jogadores. Atualmente, a maior parte dos jogos eletrônicos implementam o módulo de comunicação uti-lizando o paradigma cliente-servidor, necessitando de máquinas robustas para atuar como ser-vidora. O uso do paradigma P2P (peer-to-peer), apesar de ter sua implementação mais com-plexa, gera vantagens na distribuição de carga, dispensando o uso de servidores. As vantagens do uso do paradigma P2P em jogos multiplayer, bem como os desafios do desenvolvimento, servem como motivação para este trabalho, que apresentará um middleware de comunicação em rede para jogos utilizando este paradigma, analisando e apresentando soluções para os di-versos problemas que aumentam a complexidade de sua implementação.

ABSTRACT

The computer games area in Brazil is growing considerably since the latest years and the use of game engines and RAD (Rapid Application Development) tools become essential in the development process, allowing the addition of sophisticated resources to the games. Among the growing areas, stands out the network games as a strong tendency in the entertainment market, once gamers want to interact with other gamers. Nowadays, the biggest part of elec-tronic games implement the communication module using the client-server paradigm, needing robust machines for acting as servers. Although it has a more complex implementation the use of P2P (Peer to Peer) paradigm generates advantages in the charge distribution, dispensing the use of servers. The advantages of using P2P paradigm in multiplayer games, just like the chal-lenges in the development process, serves as a motivation to this work, which will introduce a network communication middleware for games using this paradigm, analyzing and presenting solutions to the several problems that grow the complexity of its implementation.

LISTA DE ILUSTRAÇÕES

Figura 1 - Distribuição Geográfica dos Desenvolvedores (ABRAGAMES). ... 6

Figura 2 - Faturamento por Estado (ABRAGAMES). ... 7

Figura 3 - Modelo arquitetural dos motores Forge V8 3D (a) e JFROG (b). ... 8

Figura 4 - Divisão de camadas do modelo OSI (a) e TCP/IP (b). ...16

Figura 5 – Modelos cliente-servidor (a) e P2P (b). ...17

Figura 6 - Diagrama de pacotes do middleware ...23

Figura 7 - Diagrama de classes do middleware ...26

Figura 8 - Diagrama de sequência - Busca por sessões ...27

Figura 9 - Diagrama de sequência - Abertura de conexão ...28

Figura 10 - Diagrama de sequência - Envio de mensagem ...30

Figura 11 - Diagrama de sequência - Inicio de criptografia ...31

Figura 12 - Diagrama de sequência - Recebimento de mensagem ...32

Figura 13 - Diagrama de sequência - Encerramento de sessão ...33

Figura 14 - Diagrama de integração entre o middleware e o jogo. ...34

Figura 15 - Modelo arquitetural do JFROG, com uso do middleware. ...35

Figura 16 - Exemplo do arquivo de configuração do middleware ...37

Figura 17 - Telas do Jogo da Velha no inicio da execução (a) e durante a partida (b) ...39

Figura 18 - Modelo arquitetural do Space Invaders, baseado no JFROG ...39

LISTA DE TABELAS

Tabela 1 - Características dos jogos em rede por categoria (ANIBOLETE, 2006). ...10

Tabela 2 - Características das camadas do modelo TCP/IP. ...15

Tabela 3 - Descrição do conteúdo dos pacotes contidos no mcgame ...24

Tabela 4 - Métodos da interface IMCGame ...35

SUMÁRIO

1.3.2 Principais Requisitos de Operação ... 10

1.3.2.1 Consistência de Estados ... 11

1.3.2.2 Segurança dos dados ... 12

1.3.2.3 Monitoramento de Fraudes ... 12 1.3.2.4 Latência ... 13 1.3.2.5 Largura de Banda ... 14 2 Comunicação em Rede ... 15 2.1 Comunicação fim-a-fim ... 16 2.2 Paradigmas de Comunicação ... 17

2.3 Comunicação de Jogos em Rede ... 18

3 Desenvolvendo o Middleware ... 22

3.1 Diagramas ... 23

3.1.1 Diagrama de Pacotes ... 23

3.1.2 Diagrama de Classes ... 24

3.2 Operação da Arquitetura ... 26

3.2.1 Inicialização da aplicação ... 26

3.2.2 Consistência de estados ... 29

3.2.3 Segurança dos dados ... 30

3.2.4 Monitoramento de fraudes... 31

3.2.5 Encerramento de sessão ... 33

3.3 Interfaces de Integração ... 34

4 Resultados ... 38

4.1 Casos de teste ... 38

4.2 Discussão de Resultados... 41

3

INTRODUÇÃO

A área de jogos computadorizados no Brasil vem crescendo consideravelmente nos últi-mos anos. Como evidências deste crescimento, podem-se destacar o apoio da Sociedade Bra-sileira de Computação (SBC) na realização de eventos da área, como o Workshop Brasileiro de Entretenimento Digital e Jogos Computadorizados (Wjogos), e do governo através de pro-jetos de incentivo, como a Rede de Excelência de Empresas de Jogos de Entretenimento (Ga-meNet) criada pelo Governo do Paraná e editais para projetos de inovação que contemplavam a área de entretenimento digital (BITTENCOURT; GIRAFFA, 2004).

Entretanto, observa-se que a indústria nacional está ainda em um ciclo inicial de amadu-recimento, resultando em uma grande distância entre os produtos nacionais e estrangeiros. Isto faz com que os Game Engines (Motores de Jogos) e as ferramentas RAD (Rapid Application

Development) tornem-se essenciais para o desenvolvimento de jogos, aumentando seu

realis-mo, jogabilidade e competitividade junto ao mercado (BITTENCOURT; OSÓRIO, 2006). Os jogos eletrônicos em rede destacam-se como uma forte tendência dentro do mercado de entretenimento, apesar de possuírem maior custo e complexidade de desenvolvimento. Isto ocorre devido à popularização da web, que tornou mais fácil a criação de jogos multiplayes sem que estes precisem estar reunidos presencialmente (BITTENCOURT; OSÓRIO, 2006).

Atualmente, a maior parte dos Motores de Jogos que fornecem suporte a jogos em rede utilizam o paradigma cliente-servidor para isto, devido à menor complexidade e custo de de-senvolvimento em relação ao paradigma P2P (Peer-to-Peer). Contudo, este tipo de paradigma torna necessária a utilização de máquinas robustas e com grande largura de banda para atuar como servidor devido à centralização de informações. Isto se torna um problema para

peque-4

nas empresas desenvolvedoras de jogos, devido ao investimento e manutenção desta estrutura, e jogadores, aos quais são repassados os custos de manutenção (JÁBALI, 2004).

O uso do paradigma P2P no desenvolvimento de jogos multiplayer, apesar de ter sua im-plementação mais complexa devido a problemas de consistência de estados e monitoramento de fraudes, gera vantagens na distribuição de carga, visto que todas as máquinas dividem as tarefas do servidor. Este paradigma, portanto, dispensa o uso de uma máquina “especial” cen-tralizando os dados (JÁBALI, 2004).

É desenvolvido aqui um middleware de comunicação para jogos utilizando este para-digma, tendo em vista simplificar e reduzir o tempo e custos de desenvolvimento de jogos por pequenas empresas e grupos de estudo na área. Para tanto, problemas específicos de comuni-cação são endereçados, como os de consistência de estados, segurança dos dados que trafegam na rede, busca por sessões de jogos a iniciar, entre outros.

Este trabalho está organizado da seguinte forma: Capítulo 1 apresenta os jogos eletrôni-cos, descrevendo seu mercado atual no Brasil, como as ferramentas de desenvolvimento auxi-liam e como se comportam os jogos em rede. No capítulo 2 serão tratadas as formas de comu-nicação em rede, seus paradigmas e como estas estão relacionadas com os jogos multiplayers. O capítulo 3 traz a solução desenvolvida, através da apresentação de sua arquitetura e deta-lhamento de pontos da implementação, destacando cada requisito coberto. No capítulo 4 serão apresentados os testes e resultados do middleware implementado, mostrando como foi feita sua integração com os protótipos de jogos desenvolvidos, além da discussão de resultados. Por ultimo tem-se as considerações finais, apresentando as dificuldades encontradas durante a modelagem e desenvolvimento e possíveis trabalhos futuros.

5

1 JOGOS ELETRÔNICOS

Um jogo é considerado um sistema formal, por possuir regras explícitas, e fechado, por ser completo e auto-suficiente quanto a sua estrutura (modelo do mundo criado), que repre-senta subjetivamente um subconjunto da realidade. Neste caso, o termo sistema é aplicado por ser uma coleção de partes, que interagem entre si, geralmente de maneiras complexas. (PIN-TO, 2003).

Todo jogo possui intrinsecamente quatro elementos, sendo eles: representação, interação, conflito e segurança. A representação está relacionada à característica dos desenvolvedores de buscar inspirações na realidade, tentando reproduzir um determinado subconjunto desta. A interação acontece devido ao reconhecimento e reação das ações do jogador, que alteram e apresentam uma nova estrutura do jogo (realidade virtual) ao jogador. O conflito pode aconte-cer entre jogadores, situação mais comum, ou entre os objetivos a serem alcançados e os obs-táculos que dificultam sua conquista, ou seja, pode ser apresentado de forma direta ou indire-ta, violento ou não. A segurança deve-se ao fato do jogador estar protegido fisicamente dos acontecimentos do jogo, sendo assim uma forma segura de experimentar a realidade. (CRAWFORD, 2004)

1.1 Mercado nacional

O primeiro jogo eletrônico, desenvolvido na década de 50 em um laboratório de pesquisa militar americano, foi projetado para funcionar em um osciloscópio. Com o passar do tempo, devido ao aumento do poder computacional dos computadores, foi possível tornar os jogos cada vez mais realistas e complexos. Além disso, com o aumento da produção e diminuição

6

dos custos, computadores ficaram acessíveis a grande parte da população, fazendo com que a popularidade dos jogos se expandisse (CERCHIARO; SANTOS, 2006).

No Brasil, as primeiras empresas de jogos eletrônicos foram fundadas em 1992. A partir de 1997 o movimento aumentou fortemente, chegando a ser responsável por 21% do total de fundação de empresas brasileiras em 1999 (CERCHIARO; SANTOS, 2006).

Os jogos nacionais estão conquistando o mercado tendo, segundo estimativas de 2005, crescido aproximadamente 5%, com faturando em torno de R$300 milhões. Este faturamento, apesar de ser alto para o padrão nacional, ainda é muito pequeno quando comparado com o da indústria norte-americana, próximo de US$10 bilhões ao ano. Contudo, isso demonstra que o crescimento da área de jogos está em ritmo acelerado, apesar de obstáculos como a pirataria, que prejudica a possibilidade de vendas, e os altos impostos (ABRAGAMES).

A distribuição geográfica dos desenvolvedores de jogos no Brasil é apresentada na Figura 1, onde se pode perceber que a maior parte está nos estados do Paraná, São Paulo e Rio de Ja-neiro, respectivamente. Além destes três estados, os estados do Rio Grande do Sul e Pernam-buco aparecem entre os principais destaques em relação ao faturamento, como apresentado no gráfico da Figura 2.

7

Figura 2 - Faturamento por Estado (ABRAGAMES).

1.2 Motores de Jogos

A utilização de Motores de Jogos, ou Game Engines, destaca-se como principal metodo-logia para acelerar e facilitar o desenvolvimento de jogos. Em sua definição, Motores de Jogos são conjuntos de módulos de simulação que não especificam diretamente o comportamento (lógica do jogo) ou o ambiente (nível de dados) do jogo, sendo incluídos entre estes módulos, principalmente, os de manipulação de entrada (teclado, rede) e saída (comunicação, gráfico, som), e dinâmica genérica (detecção de colisões) (ASSIS, 2006).

Dados do site 3D Engine Listl (ISAKOVIC, 2000) mostram que dentre os mais de 500 engines cadastrados, a grande maioria é distribuída gratuitamente sob a licença GPL (Licença Pública Geral) e são implementadas em C++. A plataforma com maior numero de engines é o Windows, principalmente devido a biblioteca gráfica DirectX, considerada um padrão para desenvolvimento de jogos, ser compatível somente com este plataforma, estando a plataforma Linux na segunda posição em número de engines (BITTENCOURT; GIRAFFA, 2003).

O projeto arquitetural de Motores de Jogos está relacionado ao quanto de generalização pretende-se atribuir, tendo em vista que quanto maior o nível de abstração, maior será o im-pacto no desempenho da aplicação. Sendo assim, existem muitas propostas de modelos arqui-teturais, não havendo um consenso sobre qual o padrão de arquitetura deve ser utilizado (BITTENCOURT; GIRAFFA, 2003). Esta falta de padrão pode ser exemplificada através da comparação entre os modelos arquiteturais dos motores de jogos Forge V8 3D, baseado no padrão MVC (Model-View-Controller), e JFROG, com ênfase na modularização, como apre-sentado na Figura 3.

8

Como mostrado na Figura 3(a), o modelo arquitetural do Forge V8 3D é formado por três componentes: Modelo, responsável pelo estado do jogo e modelos geométricos, provendo funcionalidades para detecção de colisão e outras operações gráficas; Visão, responsável pela geração de imagens; Controlador, responsável pela dinâmica do sistema, manipulando os da-dos de entrada, simulação física, rede e referentes à inteligência artificial (IA) (BITTEN-COURT; OSÓRIO, 2006).

A arquitetura do JFROG, apresentado na Figura 3(b), é composta por quatro componen-tes: Interação, responsável por tratar eventos gerados pela interação do usuário, através de pe-riféricos de entrada como teclado, mouse ou joystick; Comunicação, responsável por tratar comunicação entre maquinas da rede; Visualizador, responsável pela geração de imagens; Controle, responsável pelo estado e dinâmica do jogo, podendo haver diversos controladores, cada um responsável por uma operação lógica, como simulações físicas ou de IA (BITTEN-COURT; GIRAFFA, 2003).

(a) (b)

Figura 3 - Modelo arquitetural dos motores Forge V8 3D (a) e JFROG (b).

A partir destas duas arquiteturas apresentadas observa-se que algumas funcionalidades são tratadas de maneira comum, como a geração de imagens pelos componentes de Visão do Forge V8 3D e o Visualizador do JFROG, e outras de maneira diferente, como persistência do estado e dinâmica do jogo, separadas pelos componentes Modelo e Controlador no Forge V8 3D e encapsuladas no componente Controle no JFROG.

9

Além do problema de falta de padrão arquitetural, outro problema encontrado nos moto-res de jogos é a falta de consenso sobre quais funcionalidades devem ser desenvolvidas, o que torna difícil portar um jogo entre motores. Como principal exemplo tem-se o Ogre 3D que se limita a trabalhar com gráficos, enquanto que os mais completos como o Quake III Engine possuem módulos capazes de lidar com inteligência artificial, física, renderização, efeitos es-peciais, som e rede (RIBEIRO, 2004).

1.3 Jogos em rede

Há algumas décadas os jogos que possibilitavam a comunicação em rede destacavam-se dos demais, visto que tinham esta opção como um diferencial. Atualmente, oferecer a possibi-lidade de diversos jogadores participarem de uma mesma partida sem que estejam reunidos presencialmente ou interconectados no mesmo dispositivo, ou seja, possibilitar a interação em rede, é um requisito comum para os jogos atuais (BITTENCOURT; OSÓRIO, 2006).

Este ambiente de crescimento dos jogos em rede pode ser confirmado através de números apresentados pelo instituto de pesquisas IDC (International Data Corporation), que destacou um aumento de 76% deste mercado entre 2005 e 2006 (IDCBRASIL).

1.3.1 Classificação

Dentro da grande quantidade de jogos em rede disponíveis no mercado, destacam-se qua-tro grandes grupos. São eles: First Person Shooters (FPS), Real Time Strategy (RTS),

Mas-sively Multiplayer Online Game (MMOG) e Non Real Time (NRT) (ANIBOLETE, 2006).

Os FPSs, ou jogos de tiro em primeira pessoa, têm como sua principal característica apre-sentar a cada jogador sua visão do jogo, exibindo cenas que representam a visão do persona-gem controlado. Outra característica está na forma de desenvolvimento destes jogos, direcio-nada para criação de jogos multiplayer, sendo posteriormente adaptados, através do uso de

bots (adversários controlados pelo computador), para serem singleplayers (KUBO, 2006).

Os MMOGs, ou jogos em rede multiplayer massivos, têm como característica principal a criação de mundos virtuais, cuja persistência e dinâmica são realizadas em um servidor, com-partilhados por milhares de jogadores. Dentre os principais tipos de MMOG é possível

desta-10

car o Massively Multiplayer Online Role Playing Game (MMORPG), onde os jogadores as-sumem papeis de personagens virtuais (KUBO, 2006).

Os RTSs, ou jogos de estratégia em tempo real, apresentam objetivos a serem alcançados pelo jogador, sendo necessário realizar a exploração, desenvolvimento e criação de recursos, nos quais os jogadores atuam ao mesmo tempo, sendo suas ações percebidas imediatamente pelos demais jogadores (ANIBOLETE, 2006).

Os NRTs, ou jogos de tempo não real, são baseados em turnos, não havendo maiores pre-ocupações com atrasos da rede. Dentro desta categoria estão incluídos os jogos de estratégia baseados em turnos (RBS – Round-Based Strategy) (ANIBOLETE, 2006).

Na Tabela 1, são apresentadas exemplos de cada uma das categorias de jogos em rede a-presentadas e características, quanto ao paradigma de comunicação, número de jogadores en-volvidos em uma partida, quantidades de servidores disponibilizados e tempo de persistência do mundo virtual criado para cada partida.

FPS RTS MMOG NRT

Paradigma Cliente/Servidor Ambos Cliente/Servidor P2P

Jogadores Poucos Poucos Muitos Ambos

Servidores Muitos Poucos Poucos Nenhum

Persistência Curta Curta Longa Ambos

Exemplos Quake Warcraft Ultima Xadrez

Tabela 1 - Características dos jogos em rede por categoria (ANIBOLETE, 2006).

1.3.2 Principais Requisitos de Operação

Alguns problemas são comuns a todos os jogos em rede, devendo haver uma maior preo-cupação para tentar resolve-los ou minimizá-los durante o desenvolvimento de jogos deste tipo. Desta forma, estes problemas tornam-se as principais funcionalidades a serem atendidas por jogos deste tipo, sendo discutidas a seguir.

11

1.3.2.1 Consistência de Estados

Manter a consistência de estados de um jogo significa garantir que todos os jogadores possuem o mesmo estado do jogo e que concordam com cada acontecimento do jogo. Esta funcionalidade é considerada a mais complexa, visto que se torna difícil de garantir a consis-tência de estado sem causar perdas de desempenho da aplicação.

Para a sincronização do estado entre todos os computadores envolvidos na partida, diver-sos algoritmos distribuídos otimistas e pessimistas são propostos. Os algoritmos distribuídos pessimistas são projetados para evitar a ocorrência de inconsistências, não estando preparados para corrigi-las, enquanto que os otimistas permitem a ocorrência de inconsistências, realizan-do a correção assim que identificadas (ANIBOLETE, 2006).

Os principais algoritmos distribuídos são o Stop-and-Wait, Bucket Synchronization e

Trailing State Synchronization (TTS), sendo o primeiro pessimista e os demais otimistas.

O Stop-and-Wait é considerado o mais simples para garantir consistência, propondo um esquema de turnos, no qual o jogador só pode seguir quando todos os demais chegarem ao turno atual. Este tipo de abordagem pode prejudicar o desempenho do jogo, visto que se um dos usuários tiver uma conexão lenta, todos os demais serão afetados (ANIBOLETE, 2006).

O Bucket Synchronization propõe algo parecido com o Stop-and-Wait, tendo como dife-rença a definição de um tempo limite para cada turno e o uso da técnica dead-reckoning, que será explicada na Seção 1.3.2.5 , para prever movimentos de um usuário que não chegou den-tro do período determinado. Sendo assim eventos que chegam atrasados são perdidos, pois já foi feita uma previsão dele (ANIBOLETE, 2006).

O TTS propõe a utilização de rollbacks quando inconsistências são detectadas, para isto salva cópia dos estados com um pequeno atraso juntamente com os eventos que devem ocor-rer dentro do período do atraso. Assim que uma inconsistência é detectada ele substitui o esta-do atual pela cópia com menor atraso e executa toesta-dos os eventos guardaesta-dos para esta cópia, caso persista a inconsistência outra copia é adquirida, ate que se obtenha uma sem a inconsis-tência (ANIBOLETE, 2006).

12

1.3.2.2 Segurança dos dados

Para dificultar a ação de jogadores mal intencionados é necessária a utilização de meca-nismos de criptografia dos pacotes transmitidos na rede, isto porque capturar pacotes para aná-lise e geração de outros, que possam dar vantagens ao jogador, é considerada uma prática co-mum (KOZOVITS, 2003).

Os algoritmos simétricos, que utilizam a mesma chave para criptografar e decifrar, são considerados a melhor opção de criptografia de pacotes, pois possuem uma menor complexi-dade temporal quando comparados aos assimétricos, sendo ambos de qualicomplexi-dade. Algoritmos assimétricos têm sua complexidade aumentada por utilizarem um par de chaves, uma pública e outra privada, usadas na criptografia e decifração, respectivamente (HINZ, 2000).

Neste contexto, os algoritmos assimétricos podem ser usados para garantir o comparti-lhamento da chave simétrica de forma segura. Para isto, a chave simétrica tem de ser enviada criptografada a partir de uma chave pública possibilitando somente ao receptor, que possui a chave privada, sua decifração. Desta forma, uma máquina pode distribuir chaves públicas e aguardar pelas chaves simétricas, que somente ela poderá decifrar (HINZ, 2003) (KOZO-VITS, 2003).

Contudo, o esquema de criptografia apesar de tornar a troca de mensagens muito mais se-gura, ainda deixa brechas. Isto acontece porque pacotes válidos podem ser capturados e repro-duzidos para gerar vantagens, sendo necessário um mecanismo de troca das chaves de cripto-grafia ao inicio de cada sessão ou durante a sessão, sendo a segunda opção mais complexa (KOZOVITS, 2003).

1.3.2.3 Monitoramento de Fraudes

Dentro de jogos com o número elevado de jogadores, não se pode assumir que todos este-jam agindo corretamente, visto que uma grande quantidade de jogadores tenta obter vantagens durante o jogo. Sendo assim, torna-se necessário o monitoramento e combate às fraudes que ocorrem durante o jogo, visando minimizar o número de vitórias fraudulentas e restringir ou desestimular a quantidade de tentativas de violação (BAUGHMAN, 2007).

13

Uma das alternativas é guardar um log contendo data e hora de inicio e fim da seção, bem como ocorrências suspeitas. A partir da análise estatística destes dados é possível identificar o nível de confiabilidade de algum jogador, que caso seja baixo pode ter suas atividades restrin-gidas ou bloqueadas. Em alguns casos de ocorrências de atividades suspeitas, são enviadas mensagens de notificação ao jogador de forma não determinística para que seja despertada a dúvida se esta ou não sendo monitorado (BAUGHMAN, 2007).

Em jogos onde os jogadores possuem independência do servidor para decisões sobre a di-nâmica do jogo, há ainda a possibilidade de tornar-los “policiais”, vigiando as atividades dos demais participantes e alimentando o log citado anteriormente (KOZOVITS, 2003).

1.3.2.4 Latência

A latência pode ser definida como o tempo que um pacote leva para ir da origem ao des-tino. Com o aumento desta variável o jogo torna-se mais propenso a atrasos e/ou inconsistên-cias, devido ao cálculo do novo estado do jogo depender da notificação de ações realizadas pelos jogadores, tendo que passar pela rede para isso (JÁBALI, 2004).

Em alguns tipos de jogos on-line, muitas vezes é necessário que a latência seja baixa o su-ficiente para que o jogador não perceba atrasos, os quais podem influenciar negativamente nas decisões tomadas. Como exemplos têm-se os jogos FPSs, onde a posição mirada deve corres-ponder exatamente a posição real (JÁBALI, 2004).

Em outros tipos de jogos a latência não influencia na jogabilidade por não possuírem de-pendência em relação ao tempo, como ocorre com os NRTs, onde estes são baseados em tur-nos e não há uma modificação tão constante do estado do jogo.

Para minimizar atrasos os jogos em rede têm como boa prática não acumular buffer, ou seja, não armazenam mudanças de estado, fazendo com que os atrasos gerados estejam liga-dos unicamente aos geraliga-dos pela rede, sobre os quais não possuem controle (KOZOVITS, 2003).

14

1.3.2.5 Largura de Banda

Largura de banda é a quantidade de dados que a rede pode transferir em um determinado período de tempo. A partir disso, é possível afirmar que quanto maior a quantidade de dados trafegando na rede, maior deverá ser a largura de banda para evitar atrasos. Isto torna necessá-ria a utilização de estratégias que diminuam a quantidade de dados trafegando na rede (JÁ-BALI, 2004).

Algumas das alternativas para lidar com estas limitações de largura de banda mais co-muns são diminuir o tamanho do pacote ou reduzir a taxa de envio destes pacotes, sendo a se-gunda alternativa mais frequentemente escolhida. Outra opção, mais complexa, é o uso de técnicas para prever movimentos como dead-reckoning, o que ajuda a reduzir a taxa de atuali-zação (KUBO, 2006).

A técnica de dead-reckoning, originada a partir de uma técnica de navegação antiga, con-siste em guardar os eventos anteriores para tentar prever movimentos. Sendo assim, pode-se prever ação de outros nós e modificar o estado do jogo baseados nestas previsões, e ainda po-de-se simular o que os demais nós estão prevendo para si e enviar mensagens para correção (GOSSWEILER, 1994).

Há ainda uma extensão do dead-reckoning usado normalmente, que é baseado em metas utilizando o conceito de piloto e clones, que são representações do jogador local e demais jo-gadores remotos, respectivamente. Neste tipo são passadas somente mensagens com metas, por exemplo, sair do ponto A ao ponto B, e todas as tarefas intermediarias, como desviar de obstáculos, são processadas em todas as estações (SZWARCMAN, 2001).

15

2 COMUNICAÇÃO EM REDE

Uma rede de computadores é formada por um conjunto de máquinas capazes de trocar in-formações e compartilhar recursos através de enlaces físicos (meios de transmissão) e de um conjunto de regras com o fim de organizar a comunicação (protocolos). Um protocolo é um conjunto de regras padronizado, que especificam formalmente o formato de mensagens e cedimentos usados na troca de mensagens entre máquinas, definidas para minimizar os pro-blemas de compatibilidade e interoperabilidade (ALBUQUERQUE, 2003).

O modelo OSI (Open Systems Interconnection), definido pela organização ISO

(Interna-tional Standards Organization), foi a primeira definição formal de uma arquitetura de

comu-nicação entre computadores. Este modelo é dividido em sete camadas, como apresentado na Figura 4 (a), englobando desde o nível físico até o nível da aplicação utilizada pelo usuário, nas quais os protocolos estão distribuídos de acordo com suas tarefas especificas (TANEN-BAUM, 2003).

O modelo Internet é o mais difundido, sendo conhecido também como pilha TCP/IP de-vido à grande parte da comunicação ser baseada no par de protocolos TCP (Transmission

Control Protocol) e IP (Internet Protocol) (TANENBAUM, 2003). Este modelo possui quatro

camadas, como apresentado na Figura 4 (b), e as características gerais de cada uma destas são descritas na Tabela 2.

Camada Finalidade

Aplicação Disponibiliza o serviço de comunicação utilizado pelo usuário

Transporte Controlar a comunicação fim-a-fim, opcionalmente erros e fluxo de comunicação Rede Oferecer identidade lógica, global e independente de hardware

Enlace Compatibilizar a camada de rede com o hardware

16

Na Figura 4 é apresentada a comparação entre a divisão de camadas TCP/IP e OSI. Como mostrado, a camada de aplicação do modelo TCP/IP engloba as três primeiras camadas do modelo OSI, assim como a camada de enlace engloba as duas ultimas do modelo OSI.

Figura 4 - Divisão de camadas do modelo OSI (a) e TCP/IP (b).

2.1 Comunicação fim-a-fim

Dentre os protocolos de comunicação, podem-se destacar os que fazem parte da camada de transporte por possuírem a função de controlar a comunicação fim-a-fim, garantindo que uma entidade desta camada se comunique com a entidade par da máquina remota. Além disso, esta camada pode controlar opcionalmente erros e o fluxo da comunicação (COMER, 2007).

Os dois principais protocolos usados nesta camada são o TCP (Transmission Control

Protocol) e o UDP (User Datagram Protocol), ambos baseados em portas para troca de

in-formações. Cada porta identifica o ponto terminal (aplicação) da comunicação, sendo atribuí-da uma porta à aplicação de origem e uma ao destino (COMER, 2007).

O protocolo TCP tem por característica criar uma conexão confiável entre os dispositivos envolvidos na comunicação (emissor e receptor), garantindo a entrega de todos os pacotes sem perda de dados e na mesma seqüencia de envio. Para isto, são utilizados diversos mecanismos como: a confirmação de recebimento, através do qual é identificada a perda de um pacote para que seja retransmitido; a numeração de pacotes, para garantir a entrega em ordem e elimina-ção de duplicatas; e a utilizaelimina-ção de checksum, para identificaelimina-ção de pacotes danificados (TA-NENBAUM, 2003).

O protocolo UDP é um protocolo que se caracteriza por ser mais simples que o TCP, pois não existe a preocupação com a confiabilidade da comunicação. Neste tipo de protocolo não é

17

feita qualquer verificação em relação ao recebimento, danificação ou ordem dos pacotes envi-ados, possibilitando a perda, duplicação ou agrupamento incorreto dos pacotes (TANEN-BAUM, 2003).

Esta simplicidade pode gerar perdas de dados, contudo resulta também na diminuição da quantidade de pacotes de controle trafegando na rede devido à eliminação dos mecanismos de segurança, o que gera um ganho na velocidade de transmissão e recepção. Isto se torna uma vantagem para aplicações ou protocolos que priorizam a velocidade frente a confiabilidade, como o DHCP (Dynamic Host Control Protocol) e DNS (Domain Name Service) (ALBU-QUERQUE, 2003).

2.2 Paradigmas de Comunicação

Os dois principais paradigmas de comunicação em rede são o cliente-servidor (Figura 5-a) e P2P (Figura 5-b), caracterizados pela centralização da informação e processamento, e au-tonomia dos dispositivos envolvidos na comunicação, respectivamente. Existem ainda para-digmas resultantes da união destes dois modelos, que são conhecidos como híbridos (RO-CHA, 2004).

Figura 5 – Modelos cliente-servidor (a) e P2P (b).

No paradigma cliente-servidor as máquinas envolvidas na comunicação são classificadas em dois tipos bem definidos: o cliente, que realiza solicitações a um servidor e aguarda por sua resposta; e o servidor, responsável por processar e responder a solicitação.

Sistemas baseados neste paradigma foram muito utilizados no passado pelo fato de que computadores com maior poder de processamento e mais memória eram muito caros, o que tornava mais barato a centralização em um único servidor. Desta forma, mainframes gigantes

18

centralizavam todos os serviços e armazenavam os dados dos clientes, realizando assim toda a operação de forma remota (AZAMBUJA, 2006).

O principal problema relacionado a esta abordagem nas aplicações modernas está relacio-nado ao servidor tornar-se um ponto de contenção, uma vez que este possui um limite de esca-labilidade. Para aumentar este limite são utilizadas técnicas para distribuição de carga entre servidores. Na replicação, por exemplo, servidores idênticos são capazes de responder a uma mesma requisição. Já no particionamento, a requisição pode ser redirecionada como um todo, ou parte dela pode ser obtida de outra máquina (AZAMBUJA, 2006).

Aplicações baseadas no paradigma P2P permitem que dispositivos de uma rede se conec-tem, podendo prover e receber recursos, sejam arquivos, capacidade de armazenamento ou capacidade de processamento. Este paradigma é resultado da tendência de descentralização, que tem como características a comunicação direta entre peers, a autonomia de cada peer e a escalabilidade, que se caracteriza pela possibilidade de aumento de recursos com o crescimen-to da rede (ROCHA, 2004).

A origem do P2P confunde-se com a própria Internet, uma vez que a ARPANET já pos-suía alguns hosts que não eram tratados como clientes ou servidores, mas como pares de mesma importância. Contudo, a primeira implementação real deste paradigma foram os servi-dores de DNS, na década de 80, e somente no final da década de 90 este tipo de rede tornou-se mais popularizada com o surgimento de aplicações como Napster, Gnutella, Freenet e Kazaa, que a colocaram ao alcance de milhares de usuários (AZAMBUJA, 2006).

A partir de detalhes da sua arquitetura este paradigma pode ainda ser subdividido em re-des “puras”, quando qualquer peer pode ser removido individualmente da rede sem que a mesma sofra perdas no nível de serviço, ou “hibridas”, na qual há necessidade de um peer central para prover parte dos serviços da rede, sendo exemplificadas pelo Freenet e Napster, respectivamente (ROCHA, 2004).

2.3 Comunicação de Jogos em Rede

No desenvolvimento de jogos em redes os protocolos de transporte e paradigmas de co-municação são dois elementos importantes que precisam ser destacados, pois estão fortemente

19

relacionados à estrutura e desempenho do módulo de comunicação. Isto ocorre devido aos protocolos e, principalmente, ao paradigma escolhidos trazerem vantagens e desvantagens, além de diferentes formas de abordagem para o desenvolvimento dos jogos.

Como já visto, o protocolo TCP tem por característica criar uma conexão entre os dispo-sitivos envolvidos na comunicação através de alguns mecanismos de segurança. Contudo, isto apesar de ser desejável traz problemas na dinâmica do jogo, visto que estes mecanismos aca-bam adicionando um overhead indesejado aos jogos digitais.

Nos jogos onde se deseja garantir a velocidade de transmissão dos pacotes, mesmo com a possibilidade de perda de dados, em geral adota-se o protocolo UDP, não orientado à conexão. Neste caso devem ser usadas técnicas para detecção e correção de inconsistências no estado do jogo, pois os dados são enviados em pacotes sem nenhuma garantia de recebimento ou se-qüência adequada.

Os jogos em geral combinam estes protocolos para atender suas necessidades, definindo qual será utilizado a partir das suas particularidades da funcionalidade. Por exemplo, pode-se utilizar TCP para autenticação de usuários e UDP para troca de mensagens de chat. Outra forma de combinação utilizada acontece na própria lógica do jogo, onde os protocolos são es-colhidos a partir da necessidade de garantia ou velocidade de entrega dos pacotes. Por exem-plo, num RTS (Real Time Strategy) pode ser utilizado TCP no momento das criações das construções/unidades e o UDP para enviar informações referentes à movimentação das unida-des.

Em aplicações que utilizam o paradigma cliente-servidor o processamento do estado do jogo é centralizado no servidor, sendo este responsável por receber do cliente mensagens de atualização, processá-las e retornar um novo estado a todos os jogadores. Isto possibilita ao servidor ter uma visão completa e permanentemente atualizada sobre o estado do jogo, além de monopolizar toda a lógica deste (JÁBALI, 2004).

Este tipo de abordagem, com processamento centralizado e monopólio da lógica, facilita tanto o desenvolvimento quanto a administração do jogo. No desenvolvimento a principal vantagem está relacionada ao controle da consistência de estados, devido a ser alterado so-mente pelo servidor. Na administração são simplificadas tarefas como a manutenção e

lança-20

mento de novas versões do jogo, devido à dinâmica estar definida somente no servidor, e o registro e autenticação de usuários.

Em alguns casos, o cliente torna-se tão dependente do servidor que mesmo suas ações não são consideradas válidas enquanto não for recebido o novo estado, pois a lógica do jogo esta no servidor. Isto, além de simplificar a implementação do cliente pela redução de seu proces-samento, permite ao servidor realizar um processamento adicional sobre as ações antes de re-transmiti-las, como sua validação e análise buscando por fraudes (JÁBALI, 2004).

Contudo, esta centralização de responsabilidades faz com que todo o jogo dependa da disponibilidade do servidor, e sua falha representa a parada de todo o sistema. Além disso, a centralização faz com que as máquinas servidoras necessitem ter uma capacidade de proces-samento e largura de banda muito altas, para evitar a limitação do procesproces-samento e problemas como o aumento de atrasos na transmissão pela quantidade de dados transmitidos (KOZO-VITS, 2003).

Para diminuir o número de pacotes a serem transmitidos pelo servidor aos clientes, alguns utilizam algoritmos de visibilidade para filtrar atualizações de estado entre clientes invisíveis um para o outro, ou seja, a atualização só é enviada aos clientes que serão afetados ou que perceberão esta alteração, gerando economia de tráfego (KOZOVITS, 2003).

A utilização do paradigma P2P tem como característica a não existência de um servidor central, sendo os papeis de cliente e servidor comum a todos os jogadores da rede. Esta des-centralização destaca-se como a principal vantagem, visto que o processamento passa a ser distribuído entre os jogadores e a falha de uma máquina afeta apenas as que estiverem ligadas a esta. Contudo a distribuição do processamento faz com que o estado do jogo esteja replicado nos hosts, o que torna mais complexo o desenvolvimento, devido à necessidade de sincroniza-ção do estado entre todos os usuários, elevando seu custo (JÁBALI, 2004).

A implementação desta abordagem pode ser feita utilizando unicast, onde cada mudança de estado tem que ser comunicada a N-1 máquinas em uma rede com N usuários, ou

broad-cast, onde somente uma mensagem broadcast é enviada a cada atualização. Implementações

utilizando broadcast tem como problemas a perda de pacotes, o que dificulta ainda mais a consistência de estados e a impossibilidade de utilização na Internet (JÁBALI, 2004).

21

Aplicações que utilizam unicast têm como problema sua baixa escalabilidade, sendo o número máximo de jogadores por sessão próximo a 32, devido o alto número de mensagens enviadas. Este problema pode ser reduzido com a utilização de filtros de visibilidade, nos quais as mensagens são enviadas somente aos jogadores que serão afetados pela ação (KO-ZOVITS, 2003).

Além da complexidade da consistência de estados, a maior parte dos problemas deste pa-radigma está relacionada à administração do jogo, sendo eles: o gerenciamento de usuários, visto que o armazenamento de registros é necessário e a rede não consegue garantir a persis-tência dos dados; a manutenção e o controle de versões, devido à definição da dinâmica do jogo estar em cada jogador; e o monitoramento de fraudes, por não haver uma máquina consi-derada confiável.

22

3 DESENVOLVENDO O MIDDLEWARE

Middleware é um ou mais softwares de conectividade que consiste em um conjunto de

serviços para interação, através da rede, de múltiplos processos executando em uma ou mais máquinas. Esses softwares de conectividade oferecem serviços de propósitos gerais que se situam entre a aplicação e a plataforma utilizada (sistema operacional e hardware) (COSTA, 2000).

O middleware aqui apresentado, denominado MCommP2P, oferece serviços relacionados à comunicação de jogos em rede, endereçando problemas como consistência de estados, con-trole de sessão, criptografia de pacotes e monitoramento de fraudes. Desta forma, estes servi-ços podem ser abstraídos pelo usuário, que poderá escolher quais funcionalidades oferecidas serão utilizadas, tornando o desenvolvimento de jogos em rede mais simples.

Outra característica do software desenvolvido está relacionada ao paradigma de comuni-cação P2P, utilizado durante a dinâmica do jogo. Este paradigma foi escolhido para que os jogos desenvolvidos pudessem ser os mais independentes possíveis de um controlador central, reduzindo assim os custos. Algumas das funcionalidades oferecidas ainda possuem dependên-cia com um servidor, como a autenticação de usuários, devido à dificuldade de persistêndependên-cia de dados em redes P2P. Contudo, características como estas podem ser desabilitadas pelo desen-volvedor.

A seguir será apresentado o projeto do middleware, através da linguagem de modelagem UML (Unified Modeling Language), que possibilita especificar, visualizar, construir e docu-mentar um sistema a partir de diagramas. Com o uso destes diagramas serão descritos a distri-buição e organização do midlleware, seu funcionamento e detalhes da integração com o jogo.

23

3.1 Diagramas

Para a apresentação da estrutura do middleware são utilizados os diagramas de pacotes e classes da linguagem de modelagem UML, que apresentam de forma visual a distribuição e dependências das classes do projeto.

3.1.1 Diagrama de Pacotes

O diagrama de pacotes da UML é útil para apresentar os itens estruturais de uma aplica-ção e a forma como eles foram organizados em grupos. Através dele é possível visualizar a dependência entre os pacotes e como eles são compostos, para construir uma visão concisa e lógica do sistema (FOWLER, 2004).

A Figura 6 apresenta o diagrama de pacotes da aplicação desenvolvida. O pacote br.uefs.roka contém dois pacotes: util, que contém classes genéricas, como serializa-ção de objetos, e mcgame, que contém os arquivos referentes a implementaserializa-ção das funciona-lidades do componente, distribuídas em outros seis pacotes. O conteúdo de cada um destes seis pacotes é apresentado na Tabela 3.

24

Pacote Conteúdo

comm Classes referentes à abertura de conexões e comunicação entre os hosts config Classe que contém os parâmetros de configuração

core Interface e classes que implementam as funcionalidades específicas monitoring Classe para notificação de fraudes ao servidor e jogadores

security Classes de criptografia de dados transmitidos sync Classes para sincronização do estado do jogo

Tabela 3 - Descrição do conteúdo dos pacotes contidos no mcgame

3.1.2 Diagrama de Classes

O diagrama de classes descreve os tipos de objetos de um sistema, seus métodos e atribu-tos, e as várias formas de relações estáticas entre eles. Através dele é possível visualizar a de-pendência entre as classes e como elas são compostas, em diagramas que apresentam métodos e atributos, para construir uma visão do sistema (FOWLER, 2004).

O diagrama de classes da Figura 7 apresenta a disposição e dependências das principais classes do software desenvolvido, sendo elas:

● _{MCGame – Esta é a principal classe do sistema, sendo responsável por implementar a}

in-terface IMCGame, apresentada na Seção 0, e pelo gerenciamento do módulo, sendo refe-renciada na maior parte das demais classes para obtenção de dados referentes ao estado do middleware. Esta classe também é responsável pela inicialização dos servidores de co-nexão e referência;

● _{Server – Esta classe possui a função de servidora de conexões, visto que monitora uma}

determinada porta aguardando por conexões iniciadas por outras máquinas. Ao receber o pedido por conexão um socket é criado e encaminhado ao MCGame, que irá criar um A-gent;

● _{ServerMulticast – Funciona como um servidor de referências, visto que aguarda}

requisições de busca por sessões, usuários e máquinas conhecidas. Sua principal diferen-ça em relação a Server é que sua comunicação é realizada através de datagramas

multi-cast;

● _{Agent – Responsável por encapsular a conexão direta entre o host local e o remoto,}

25

remoto, existe um Agent responsável por gerenciá-la, realizando além da troca de men-sagens, sua criptografia e checagem;

● _{SelectedSession – Realiza o gerenciamento da sessão selecionada, contendo o}

con-junto de Agent relacionados a esta. Através desta classe são realizadas as operações de abertura e encerramento de uma sessão, e envio de mensagens a todos os hosts de uma sessão;

● _{CryptoSymmetric – Encapsula a API de criptografia simétrica de Java, sendo}

possí-vel utilizar diversos algoritmos deste tipo para realizar operações de criptografia e des-criptografia. Por padrão utiliza o algoritmo AES;

● _{CryptoAsymmetric – Encapsula a API de criptografia assimétrica de Java, sendo}

possível utilizar diversos algoritmos deste tipo para realizar operações de criptografia e descriptografia. Por padrão utiliza o algoritmo RSA;

● Monitoring – Classe responsável por processar uma suspeita de fraude, realizando o envio de mensagens de notificação ao servidor, quando assim configurada, e ao jogador suspeito, de forma aleatória.

Além das classes apresentadas no diagrama o sistema possui outras classes que foram o-mitidas e serão relacionadas na descrição da implementação, como as relacionadas à sincroni-zação do estado e encapsulamento de dados.

26

Figura 7 - Diagrama de classes do middleware

3.2 Operação da Arquitetura

Nesta seção é apresentada a descrição da operação do middleware a partir de cada uma das suas funcionalidades. Estas funcionalidades são especificadas através dos diagramas de seqüência da UML, que apresentam de forma visual as comunicações necessárias entre obje-tos para a realização de uma ação (FOWLER, 2004).

3.2.1 Inicialização da aplicação

A inicialização da aplicação esta relacionada principalmente aos servidores de conexão e de referência, através dos quais será possível iniciar conexões entre os hosts e buscar

informa-27

ções da rede, respectivamente. Estes dois servidores possuem uma referência para o MCGame, possibilitando encaminhar requisições ou obter informações para resposta, e dados como a porta que irá rodar e o grupo multicast que faz parte o servidor de referências.

A Figura 8 mostra o diagrama de sequência da busca por sessões, no lado do host que ori-ginou a busca. A operação inicia com a chamada ao método listSession da classe MC-Game, que utiliza o objeto estático SearchSessionAgent para realizar a busca. O objeto

SearchSessionAgent cria um pacote contendo um identificador da operação de busca por sessão (objeto SearchSession), envia este ao grupo multicast do qual faz parte, a-guarda por respostas durante dois segundos e ao final deste tempo retorna a lista de sessões encontradas. As sessões não iniciadas encontradas são retornadas através de datagramas envi-ados pelos hosts remotos ao solicitante, e são recebidas pelo servidor de referências que en-caminha ao SearchSessionAgent.

Figura 8 - Diagrama de sequência - Busca por sessões

De forma similar é feita a busca por usuários na rede para impedir o registro de usuários com o mesmo nickname (apelido), sendo para isto alterado o objeto responsável pela busca e o identificador, pelos objetos SearchUserAgent e SearchUser, respectivamente.

A Figura 9 apresenta a abertura de conexão entre dois hosts. Como toda a troca de men-sagens do jogo é realizada a partir de conexões TCP, torna-se necessário a abertura de

cone-28

xões com todas as máquinas de uma seção no momento de registro. Isto faz com que este tipo de operação seja realizado com freqüência.

Figura 9 - Diagrama de sequência - Abertura de conexão

A abertura de conexão inicia com a chamada ao objeto AgentFactory, responsável por instanciar agentes de comunicação, que podem ser criados a partir do endereço e porta in-dicados, ou de um socket previamente criado. A forma de instanciar o objeto Agent define como ele vai se comportar até a completa abertura da conexão, pois como mostrado na Figura 9, ao ser criado a partir de um socket o Agent informa imediatamente seu usuário e ao rece-ber a informação do usuário remoto nada faz, enquanto que no outro caso o Agent aguarda um usuário e depois informa o seu.

A atuação do objeto Server neste processo apesar de simples é essencial, pois ele é o responsável por aceitar a conexão e gerar o socket que será passado à classe de gerenciamento de sessão, realizando assim o registro do jogador.

29

3.2.2 Consistência de estados

Na Seção 1.3.2.1 (Consistência de Estados) a necessidade de consistência do estado do jogo foi apresentada, assim como alguns dos algoritmos distribuídos para realização desta ta-refa. Dentre os algoritmos apresentados o Stop-and-Wait foi o escolhido para ser implementa-do neste middleware, apesar de suas limitações e possibilidade de aumento implementa-dos atrasos.

O algoritmo Stop-and-Wait foi escolhido, pois dentre os apresentados foi o único que não necessitava de informações sobre como manipular o estado do jogo, encontrando erros e reali-zando as devidas correções neste. Este algoritmo limita-se a bloquear o envio de mensagens até que todos tenham enviado no turno anterior, funcionando como uma barreira cíclica. A implementação desta barreira é realizada pelo objeto BarrierMessage, e o número de jo-gadores, ou seja, a quantidade de mensagens que deve ser recebida para que o envio esteja li-berado é definido após a inicialização da sessão.

Para evitar que esta forma de sincronização possa atrapalhar a integração com algum jo-go, e permitir aos desenvolvedores a opção de realizar sua própria sincronização através de outros algoritmos, é oferecida a opção de desativação da barreira no arquivo de configuração do middleware. Com a barreira desativada as mensagens são enviadas imediatamente, deven-do ser a consistência deven-do estadeven-do garantida pelo desenvolvedeven-dor deven-do jogo.

A Figura 10 apresenta o diagrama de sequência do envio de mensagem aos jogadores de uma sessão. A mensagem é encaminhada ao SelectedSession, responsável pelo gerenci-amento dos agentes de uma sessão, e antes de realizar o envio aos jogadores através de cada Agent, o método await do objeto BarrierMessage é executado. Caso a barreira esteja ativa, esta chamada ao await causa uma pausa no fluxo de envio das mensagens, pois este método só retorna o controle do fluxo quando o número de mensagens recebidas é igual à quantidade de jogadores na sessão.

30

Figura 10 - Diagrama de sequência - Envio de mensagem

Após passar pela barreira a mensagem é enviada a cada um dos hosts de uma sessão, sen-do para isto serializada, criptografada, quansen-do a criptografia esta ativa, e enviada através sen-do canal de comunicação entre os hosts.

Este mesmo mecanismo de barreira é usado de forma similar para a inicialização de ses-sões, sendo utilizada a classe BarrierStart. Contudo, devido à possibilidade de entrada de usuários numa sessão enquanto esta não for iniciada, não é possível definir o número de mensagens que irão chegar. Para isto antes de ativar a barreira, uma mensagem de inicializa-ção da sessão é enviada, pelo primeiro jogador que requisitar o início, a todos registrados no momento, notificando o bloqueio da entrada de novos jogadores. Após o envio desta notifica-ção o número de mensagens já é conhecido e a barreira pode ser ativada.

3.2.3 Segurança dos dados

A segurança dos dados foi apresentada como um dos requisitos operacionais dos jogos em rede (Seção 1.3.2.2 ), devido ao alto número de tentativas de fraudes em partidas. Por isso a aplicação desenvolvida disponibiliza mecanismos de criptografia dos dados, tendo os algo-ritmos RSA e AES como padrão para criptografia assimétrica e simétrica, respectivamente. Estes algoritmos foram selecionados por serem considerados os mais eficientes por institutos como o NIST (Instituto Nacional de Padrões e Tecnologia dos EUA).

31

Contudo, nem todos os jogos precisam deste tipo de mecanismo, e os que necessitam po-dem optar pela utilização de outros algoritmos de criptografia. Por isso é possível através do arquivo de configuração desabilitar a criptografia e/ou optar por algoritmos como: Simétricos – Blowfish, DESede, ARCFOUR, AES ou DES; Assimétricos – DAS ou RSA.

A Figura 11 mostra a inicialização da criptografia, onde é feita a definição das chaves de criptografia usadas durante a sessão do jogo. Ao habilitar a criptografia um objeto Crypto-Assymmetric é criado e sua chave pública é enviada ao host remoto. O host remoto instan-cia um objeto CryptoSymmetric, que gera uma chave de criptografia simétrica aleatoria-mente, criptografa a chave gerada usando a chave pública recebida, encapsula no pacote Se-cretKeyPacket e envia. Ao receber a chave simétrica o host local decifra usando sua cha-ve assimétrica privada e cria um objeto para criptografia simétrico passando esta chacha-ve rece-bida.

Figura 11 - Diagrama de sequência - Inicio de criptografia

3.2.4 Monitoramento de fraudes

Como apresentado na Seção 1.3.2.3 (Monitoramento de Fraudes), é grande o número de usuários não confiáveis, ou seja, que tentam obter vantagens durante o jogo. Para minimizar e/ou monitorar este tipo de prática o middleware confere a validade dos pacotes recebidos,

32

através da captura de erros durante a deserialização dos objetos transmitidos. A ocorrência de erros neste processo indica a alteração de conteúdo do pacote transmitido, sendo a suspeita encaminhada à classe Monitor.

Ao receber uma notificação, a classe Monitor pode realizar dois procedimentos: notifi-car o jogador suspeito, sendo isto feito de forma não determinística para despertar a dúvida sobre seu monitoramento; notificar o servidor informado, no arquivo de configuração, para que este possa analisar estatisticamente as ocorrências. No caso de notificação ao servidor, a análise estatística é fundamental, pois suspeitas podem ser notificadas incorretamente.

A Figura 12 apresenta o diagrama de sequência do recebimento de uma mensagem por um host. O pacote recebido é decifrado, caso a criptografia esteja ativa, e posteriormente é deserializado. Ao fim deste processo é feita a checagem do objeto obtido e dois caminhos po-dem ser seguidos: o encaminhamento da notificação de fraude, caso o objeto seja inválido; ou o caminho normal, no qual a mensagem é enviada ao MCGame, que libera a barreira de sin-cronização e encaminha o evento ao jogo.

33

3.2.5 Encerramento da aplicação

O encerramento da aplicação é realizado através do fechamento das conexões com os

hosts de uma sessão, sendo para isto feita a finalização de todos os Agents desta sessão. O

encerramento pode ser iniciado em duas ocasiões, devido à solicitação do usuário ou a pro-blemas de comunicação.

A finalização devido a problemas de comunicação ocorre quando, por um motivo qual-quer, acontece a saída de um host da rede de forma inesperada. Neste caso, o host local só percebe que a conexão foi encerrada quando tenta realizar o envio de mensagens e uma exce-ção (notificaexce-ção de erro) é lançada, informando o fechamento da conexão. Esta exceexce-ção é cap-turada, evitando que seja repassada a outros objetos, e o host que saiu da rede é excluído do objeto SelectSession.

A Figura 13 apresenta o encerramento da sessão devido à solicitação do usuário ou do

middleware, em casos como limite mínimo de hosts ou logout do usuário. Neste caso, uma

mensagem notificando o fim da conexão é enviada a cada host da sessão, identificados no SelectSession. Após o envio da mensagem o host local encerra a conexão com o remoto, que por sua vez exclui-o da lista de máquinas na sua sessão.

34

Em ambos os casos após realizar a retirada de um Agent da sessão é feita a conferên-cia do limite mínimo de conexões. Caso este limite seja alcançado a sessão é fechada através da solicitação de encerramento da aplicação pelo middleware e o jogo é notificado através de um objeto SessionClose, que contém o motivo do encerramento.

3.3 Interfaces de Integração

Como visto anteriormente, é necessária a definição da forma de comunicação/integração entre o jogo e o middleware desenvolvido. Para isto, duas interfaces foram especificadas: Ob-server, implementada pelo jogo, e IMCGame, que apresenta os serviços . A Figura 14 apre-senta esta integração através de um diagrama de componentes UML.

Figura 14 - Diagrama de integração entre o middleware e o jogo.

A interface Observer, padrão na linguagem de programação usada para implementa-ção, define o método update(Observable o, Object arg). Através deste método as mensagens recebidas pelo middleware (MCommP2P) serão encaminhadas ao jogo (Game), que poderá tratar a mensagem de forma particular, visto que possui as informações sobre quem enviou e qual o conteúdo de cada pacote.

A interface IMCGame, implementada pelo middleware, define os métodos que poderão ser utilizados pelo jogo para acesso aos serviços oferecidos, estando a lista destes métodos e de suas finalidades disponíveis na Tabela 4.

O middleware foi idealizado para utilização em jogos com o padrão arquitetural seme-lhante ao do motor de jogos JFROG, apresentado na Seção 1.2 , cujo modelo dá ênfase a mo-dularização do jogo. Nestes tipos de jogos a parte de comunicação é separada do restante do jogo, fazendo com que o middleware possa ser integrado com este através dos serviços dispo-nibilizados e de uma interface para notificação de eventos ao módulo de controle do jogo.

35

Método Finalidade

createSession( String nameSession ) Cria uma nova sessão a partir do nome informado getLoggedUser() Retorna o usuário registrado

getSession() Retorna a sessão registrada

join(String name, String password) Cria um usuário

leave() Finaliza a sessão em andamento

listSession( ) Lista todas as sessões disponíveis não iniciadas register(String name, String password) Registra um usuário

registerSession( Session session ) Registra o jogador na sessão informada

send(Object message) Envia uma mensagem aos jogadores de uma sessão setObserver(Observer observer) Indica a classe responsável por receber as mensagens startSession( ) Inicia a sessão selecionada

Tabela 4 - Métodos da interface IMCGame

A Figura 15 apresenta uma proposta de utilização do middleware, denominado MCommP2P, pelo motor de jogos JFROG, no qual o módulo de comunicação existente esta-ria sendo substituído pelo middleware de comunicação para jogos.

36

3.4 Detalhes da implementação

Java foi utilizada para a implementação do middleware devido a trabalhos anteriores te-rem sido desenvolvidos através desta linguagem (ROCHA, 2006). Além disso, Java oferece portabilidade e uma rica API (Application Programming Interface), aumentando sobremanei-ra a aplicabilidade desta linguagem.

Para facilitar o uso do middleware desenvolvido algumas opções de configuração são ofe-recidas ao usuário, sendo estas realizadas através do arquivo XML, properties.xml, localizado na raiz do projeto. A partir deste arquivo diversas funcionalidades podem ser ativadas, desati-vadas ou definidas de acordo com a necessidade do usuário.

Algumas das possibilidades de configuração são: ativação da criptografia de pacotes e de-finição dos algoritmos usados, limites de usuários por sessão, ativação de mecanismos de con-sistência de estado e monitoramento de fraudes, entre outras. A Tabela 5 apresenta os parâme-tros de configuração, sua descrição e padrão, em seguida, a Figura 16 mostra um exemplo do arquivo de configuração.

Chave Descrição Padrão

bind_port Porta em que o servidor de conexão irá rodar 1000 masterserver Servidor que irá prover recursos --

multicast_group Grupo de multicast da intranet 225.4.5.6:5000 crypto_assymmetric Definição do algoritmo assimétrico a ser usado RSA

crypto_symmetric Definição do algoritmo simétrico a ser usado AES

crypto_on Ativa ou desativa a criptografia true

max_user_session Número máximo de usuários numa seção 8 min_user_session Número mínimo de usuários numa seção 2

monitor_state Define a ativação da barreira true

monitoring Monitora a ocorrência de fraudes true

authentication Ativa a exigência de autenticação false Tabela 5 - Tabela de parâmetros de configuração do middleware

37

38

4 RESULTADOS

4.1 Casos de teste

Para verificar a usabilidade do middleware apresentado no desenvolvimento de jogos em rede, foram desenvolvidos dois protótipos de jogos que ilustram as possibilidades da aplica-ção: Jogo da Velha e Space Invaders. É importante destacar que os protótipos não foram im-plementados priorizando características como realismo e jogabilidade, visto que sua finalidade é verificar a integração com o middleware. Por isso, a lógica e regras do jogo, como tratamen-to de colisões e pontuações, foram deixadas em segundo plano.

Para o desenvolvimento do Jogo da Velha, foi criada uma única classe contendo tanto a lógica do jogo quanto sua interface. Este jogo teve como objetivo principal realizar os primei-ros testes e ajustes do middleware, não sendo analisadas características relacionadas a perfor-mance. Ao final dos ajustes, diversas funcionalidades já estavam validadas, como inicializa-ção do jogo (gerência de usuários e sessões) e troca de mensagens.

Algumas telas típicas do Jogo da Velha são apresentadas na Figura 17 (a) e Figura 17 (b). A Figura 17 (a) apresenta a tela de inicio do jogo, quando o usuário ainda não está registrado, sendo por isso habilitada somente a opção de login. Na Figura 17 (b) a partida já está em an-damento e as fases de criação, seleção e inicio da sessão já foram ultrapassadas, por isso as únicas opções possíveis são continuar jogando ou sair.

39

(a) (b)

Figura 17 - Telas do Jogo da Velha no inicio da execução (a) e durante a partida (b)

O desenvolvimento do Space Invaders necessitou de mais planejamento, visto que sua fi-nalidade foi testar não somente o funcionamento, mas também o desempenho do middleware desenvolvido, além de requisitos mais complexos como a sincronização de estados do jogo.

O modelo do JFROG foi utilizado como base para a definição arquitetural do Space Inva-ders, como apresentado na Figura 18. Neste jogo foram definidas três classes principais, além das classes de entidade, sendo elas: CaptureKeyboard, responsável pela captura de entra-das do teclado, Canvas, responsável pela renderização gráfica do jogo, e Game, que realiza a consistência e dinâmica do estado do jogo.

40

Para realização dos testes de desempenho, o middleware foi configurado com as opções de sincronização de estados e criptografia ativas, e o jogo teve sua taxa de atualização fixada em 30 vezes por segundo. Esta taxa indica que o estado do jogo é atualizado 30 vezes a cada segundo, implicando na sua alteração a partir da captura de eventos do teclado e mensagens da rede, e renderização para apresentação ao jogador.

Com a configuração apresentada o jogo manteve-se estável durante os testes, sem ocor-rência de erros, a uma taxa de atualização de quadros em 30 frames por segundo (fps), o que garante uma qualidade de imagem semelhante à televisão (25-30 fps), e um consumo de banda médio de 24 Kb, abaixo do limite de um modem telefônico de 56Kb. Os computadores usados foram um Celeron 2,4 GHz com 512Mb de memória e um Pentium Dual 2,0 GHz com 1Gb de memória, ligados por uma rede FastEthernet.

A Figura 19 apresenta a imagem de um dos testes realizados com o jogo Space Invaders. Através dela é possível observar a consistência do estado nos dois hosts envolvidos na partida.