Lidando com Recursos Escassos e Heterogênos em um Sistema Geograficamente Distribuído Atuando como Servidor de MMOG

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO CARLOS EDUARDO BENEVIDES BEZERRA Lidando com Recursos Escassos e Heterogênos em um Sistema Geograficamente Distribuído Atuando como Servidor de MMOG Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação Prof. Dr. Cláudio Fernando Resin Geyer Orientador Porto Alegre, março de 2009

CIP CATALOGAÇÃO NA PUBLICAÇÃO Bezerra, Carlos Eduardo Benevides Lidando com Recursos Escassos e Heterogênos em um Sistema Geograficamente Distribuído Atuando como Servidor de MMOG / Carlos Eduardo Benevides Bezerra. Porto Alegre: PPGC da UFRGS, 2009. 80 f.: il. Dissertação (mestrado) Universidade Federal do Rio Grande do Sul. Programa de Pós-Graduação em Computação, Porto Alegre, BR RS, 2009. Orientador: Cláudio Fernando Resin Geyer. 1. Jogos online maciçamente multijogador. 2. MMOG.. Simulação interativa distribuída. I. Geyer, Cláudio Fernando Resin. II. Título. UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. Carlos Alexandre Netto Vice-Reitor: Prof. Rui Vicente Oppermann Pró-Reitor de Pós-Graduação: Prof. Aldo Bolten Lucion Diretor do Instituto de Informática: Prof. Flávio Rech Wagner Coordenador do PPGC: Prof. Álvaro Freitas Moreira Bibliotecária-chefe do Instituto de Informática: Beatriz Regina Bastos Haro

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. GEORGE BERNARD SHAW The sheer rebelliousness in giving ourselves permission to fail frees a childlike awareness and clarity (...) When we give ourselves permission to fail, we at the same time give ourselves permission to excel. ELOISE RISTAD

AGRADECIMENTOS Eu não teria chegado aqui se não fosse pelo empurrão de várias pessoas. O Fábio, que me convenceu que minhas viagens valiam pra alguma coisa, e que aquilo até dava paper, e quem sabe até mesmo dissertação de mestrado. Acho que se não fosse por ele eu ainda teria zero publicações... E tem o pessoal que ficava na 20 no final do projeto P2PSE, como o Felipe e o Marcos (undergrad) e as poucas, mas boas, seções de RPG nas noites de quarta-feira na casa do Felipe e do Rafael, tornadas possíveis graças ao Fábio, que se dispôs a deixar todos os não-mestres em suas respectivas casas (i.e. eu e o Marcos). Mas nem só de RPG vive o mestrado, então teve o incentivo e o enlightenment de professores que admiro muito, como a Taisy Weber, que foi a primeira pessoa a dizer isso foi logo no primeiro semestre do curso, em uma avaliação da cadeira de tolerância a falhas em sistemas distribuídos que pedia a definição de uma idéia de projeto, com direito a contexto, motivação, metodologia, resultados esperados etc. que eu tinha uma idéia interessante, semelhante à de um grid, mas alertou que jogos não são aplicações bag-of-tasks, pelo fato das tarefas a distribuir terem características muito dinâmicas. Teve também o Professeur Docteur Nicolas Maillard (que provavelmente está lendo por estar na banca da defesa, mas juro que não o estou bajulando...), que mesmo nas ocasiões em que estava sobrecarregado com n tarefas, sempre dava suas aulas de maneira magistral. Ele sabe como transmitir seu gosto por programação paralela e distribuída, e isso foi ainda outro incentivo para eu mergulhar fundo na pesquisa. Assim como com a Taisy, eu teria perdido muito se não tivesse assistido às suas aulas. Eu tenho que agradecer também ao prof. Alexandre Carissimi, que me deu a grande oportunidade de realizar atividade didática com ele, na cadeira de SisOp II, onde eu senti o gosto (que me agradou de verdade) de ensinar aos alunos de computação da UFRGS, que fazem jus ao lugar onde estudam. E não só ele me deu a oportunidade, como também me deu várias dicas do que eu devo melhorar, coisa que eu guardo com cuidado porque sei o quanto me vai ser útil quando eu vier a dar aula por profissão. Devo lembrar de Ângela, Rauster e cia., que além de me proverem um santuário em Salvador durante a minha graduação, me empurraram rumo ao desconhecido Sul e me mandaram virar hômi e deixar de ter medo da mudança. Preciso agradecer ao prof. Cláudio Geyer, que me abriu as portas da UFRGS e do PPGC do II, assim como me pôs no meio do grupo de pesquisa dele, e me deu a oportunidade de fazer mestrado em um dos três programas de pós em computação top do Brasil. E, para concluir, se não fosse pelas minhas 4 fuinhas (e mais uma fênix) minha namorada tem 44-upla personalidade me dando apoio desde que eu pus os pés no Rio Grande do Sul, eu não faço idéia de como teriam sido estes dois anos a mais de dois mil quilômetros de casa, da minha família e de toda a vida que eu tive antes de vir parar aqui. Te amo, Fua!

SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS.................... 7 LISTA DE FIGURAS............................... 8 LISTA DE TABELAS.............................. 9 LISTA DE ALGORITMOS............................ 10 RESUMO..................................... 11 ABSTRACT................................... 12 1 INTRODUÇÃO................................ 1 1.1 Jogos Multijogador.............................. 1 1.2 Jogos Online Maciçamente Multijogador (MMOGs)........... 14 1. Objetivos................................... 1 1.4 Organização do texto............................. 1 2 TRABALHOS RELACIONADOS..................... 16 2.1 Distribuição da infra-estrutura de suporte ao MMOG.......... 16 2.2 Gerenciamento de interesse......................... 19 2. Balanceamento de carga........................... 20 2..1 Microcélulas e macrocélulas........................ 20 2..2 Balanceamento com informações locais.................. 21 2.. Uso de grafos em distribuição de tarefas.................. 24 MODELO BASE............................... 29.1 Definições................................... 29.2 Modelo de distribuição............................ 0. Questões filosóficas.............................. 2 4 A : UM ALGORITMO DE OTIMIZAÇÃO POR ÁREA DE INTERESSE 4.1 Algoritmos de área de interesse....................... 4.1.1 Área circular................................. 4 4.1.2 Ângulo de visão............................... 4 4.2 Utilizando diferentes graus de interesse em uma ADI........... 4.2.1 Círculo com atenuação........................... 6 4.2.2 Algoritmo A................................ 6 4. Simulações.................................. 7 4.4 Resultados................................... 9

4. Considerações finais............................. 41 BALANCEAMENTO DE CARGA..................... 4.1 Introdução.................................. 4.2 Esquema proposto.............................. 46.2.1 Definições e mapeamento para grafo.................... 48.2.2 Algoritmos propostos............................. Implementação................................ 61..1 A classe Avatar.............................. 62..2 A classe Cell................................ 6.. A classe Region.............................. 64..4 A classe Server.............................. 6.. Uso de valores inteiros........................... 6.4 Simulações e resultados........................... 6. Considerações finais............................. 68 6 CONSIDERAÇÕES FINAIS........................ 70 6.1 Conclusões.................................. 70 6.2 Trabalhos futuros............................... 71 6.2.1 Distribuição da carga do jogo........................ 71 6.2.2 Formação da rede lógica do sistema servidor................ 71 6.2. Sincronização de estado........................... 72 6.2.4 Persistência distribuída........................... 7 6.2. Otimização do uso de largura de banda................... 7 REFERÊNCIAS................................. 7

LISTA DE ABREVIATURAS E SIGLAS ADI BPS DHT FPS MBPS MMOG MMOFPS MMORPG MMORTS P2P RPG RTS TCP UDP Área de Interesse Bits por Segundo Distributed Hash Table First-Person Shooter Megabits por Segundo Massively Multiplayer Online Game Massively Multiplayer Online First-Person Shooter Massively Multiplayer Online Role-Playing Game Massively Multiplayer Online Real-Time Strategy Peer-to-Peer Role-Playing Game Real-Time Strategy Transmission Control Protocol Unreliable Datagram Protocol

LISTA DE FIGURAS Figura 2.1: Diferentes tipos de divisão em células................. 21 Figura 2.2: Microcélulas agrupadas em quatro macrocélulas (R 1, R 2, R e R 4 ).. 22 Figura 2.: Seleção do grupo de servidores para balanceamento local....... 2 Figura 2.4: Divisão de tarefas utilizando particionamento de grafos........ 26 Figura 2.: Particionamento de grafo simplificado................. 28 Figura.1: Modelo de distribuição......................... 1 Figura 4.1: Área de interesse em círculo...................... 4 Figura 4.2: Área de interesse baseada em campo de visão............. Figura 4.: Área de interesse em círculo com atenuação da freqüência de atualização.................................. 7 Figura 4.4: Área de interesse do A......................... 8 Figura 4.: Resultados: uso máximo de banda................... 40 Figura 4.6: Resultados: uso médio de banda.................... 41 Figura.1: Crescimento linear do tráfego com avatares distantes......... 44 Figura.2: Crescimento quadrático do tráfego com avatares próximos...... 4 Figura.: Distribuição de avatares com e sem a presença de pontos de interesse 4 Figura.4: Overhead causado pela interação de jogadores em diferentes servidores 46 Figura.: Dependência transitiva entre os avatares................ 47 Figura.6: Interação próxima à fronteira entre regiões.............. 1 Figura.7: Mapeamento do ambiente virtual em um grafo............ Figura.8: Crescimento de uma partição (região) de acordo com o ProGReGA. 7 Figura.9: Formação de partição desconexa (região fragmentada)........ 8 Figura.10: Objetos do tipo Cell alocados em uma matriz............ 6 Figura.11: Cada avatar com interesse restrito a células vizinhas à sua...... 64 Figura.12: Comparação dos algoritmos de balanceamento de carga propostos.. 66 Figura.1: Overhead introduzido por cada algoritmo de balanceamento ao longo da sessão de jogo............................ 67 Figura.14: Migração de jogadores com avatares parados e com avatares em movimento.................................. 68 Figura.1: Desvio padrão do uso de recurso dos servidores............ 69

LISTA DE TABELAS Tabela 4.1: Largura de banda máxima utilizada.................. 40 Tabela 4.2: Largura de banda utilizada em média................. 40 Tabela 4.: Economia de largura de banda com o algoritmo A.......... 41

LISTA DE ALGORITMOS Algoritmo 4.1: Cálculo da relevância da entidade E para o avatar A........ 8 Algoritmo.1: Seleção local de regiões....................... Algoritmo.2: ProGReGA............................. Algoritmo.: ProGReGA-KH........................... 9 Algoritmo.4: ProGReGA-KF........................... 60 Algoritmo.: BFBCT............................... 61 Algoritmo.6: Uso do Kernighan-Lin........................ 62

RESUMO Tradicionalmente, utiliza-se um servidor central para prover suporte a MMOGs (massively multiplayer online games, ou jogos online maciçamente multijogador), nos quais o número de participantes é da ordem de dezenas de milhares. Muitos trabalhos foram realizados com o intuito de criar um modelo de suporte completamente descentralizado, par-a-par, para este tipo de aplicação, minimizando o custo de manutenção da sua infraestrutura, mas algumas questões críticas persistem. Exemplos de problemas do modelo de suporte par-a-par são: vulnerabilidade a trapaça, sobrecarga da banda de envio dos pares e dificuldade para manter a consistência da simulação entre os diferentes participantes. Neste trabalho, é proposta a utilização de nodos de baixo custo geograficamente distribuídos, operando como um servidor distribuído de jogo. O modelo de distribuição proposto e alguns trabalhos relacionados também são apresentados. Para tratar o custo de comunicação imposto aos servidores, foi projetado aqui um novo refinamento para a técnica de gerenciamento de interesse, reduzindo significativamente a largura de banda necessária ao jogo. Foram realizadas simulações utilizando o simulador ns-2, comparando diferentes algoritmos de área de interesse. Os resultados demonstram que a nossa proposta é a que tem a menor utilização de largura de banda, com uma redução em,10% do tráfego máximo, e em,8% do tráfego médio, quando comparada com outros algoritmos de gerenciamento de interesse. Além disso, em uma arquitetura de servidor distribuído para MMOGs, com recursos heterogêneos, os nodos servidores podem ser facilmente sobrecarregados pela alta demanda dos jogadores por atualizações de estado. Neste trabalho, é proposto também um esquema de balanceamento de carga que utiliza o tráfego de rede como a carga a balancear entre os servidores e tem como objetivos principais: alocar a carga nos servidores proporcionalmente à capacidade de cada um e reduzir tanto quanto possível o overhead introduzido pela própria distribuição. O esquema de balanceamento é dividido em três fases: seleção local de servidores para participarem, o balanceamento em si e o posterior refinamento da divisão de carga. Quatro algoritmos foram propostos: ProGReGA, ProGReGA-KH, ProGReGA-KF e BFBCT. Destes, o ProGReGA foi o que introduziu o menor overhead de todos e o ProGReGA-KF foi o que se mostrou mais eficiente para reduzir o número de migrações de jogadores entre servidores. Palavras-chave: Jogos online maciçamente multijogador, MMOG, simulação interativa distribuída.

Dealing with scarce and heterogeneous resources in a geographically distributed MMOG server system ABSTRACT Traditionally, a central server is used to provide support to MMOGs (massively multiplayer online games), where the number of participants is in the order of tens of thousands. Much work has been done trying to create a fully peer-to-peer model to support this kind of application, in order to minimize the maintenance cost of its infra-structure, but critical questions remain. Examples of the problems relative to peer-to-peer MMOG support systems are: vulnerability to cheating, overload of the upload links of the peers and difficulty to maintain consistency of the simulation among the participants. In this work, it is proposed the utilization of geographically distributed lower-cost nodes, working as a distributed server to the game. The distribution model and some related works are also presented. To address the communication cost imposed to the servers, we specify a novel refinement to the area of interest technique, significantly reducing the necessary bandwidth. Simulations have been made with ns-2, comparing different area of interest algorithms. The results show that our approach achieves the least bandwidth utilization, with a.10% maximum traffic reduction and.8% average traffic reduction, when compared to other area of interest algorithms. Besides, in a distributed MMOG server architecture, with heterogeneous resources, the server nodes may become easily overloaded by the high demand from the players for state updates. In this work, we also propose a load balancing scheme, which considers the network traffic as the load to balance between the servers, and it has the following main objectives: allocate load on the servers proportionally to the power of each one of them and reduce as much as possible the overhead introduced by the distribution itself. It is is divided in three phases: local selection of servers, balancing and refinement. Four algorithms were proposed: ProGReGA, ProGReGA-KH, ProGReGA-KF and BFBCT. From these, ProGReGA has proved to be the best for overhead reduction and ProGReGA-KF is the most suited for reducing player migrations between servers. Keywords: Massively multiplayer online games, MMOG, distributed interactive simulation.

1 1 INTRODUÇÃO Jogos online maciçamente multijogador ou MMOGs, massively multiplayer online games são o tema central desta dissertação. Geralmente, utiliza-se uma infra-estrutura com um servidor central para dar suporte a este tipo de jogo. No entanto, existem alternativas descentralizadas que visam a reduzir o custo necessário para a manutenção do jogo. Este trabalho é focado em um modelo de servidor distribuído, porém, diferente da maior parte dos trabalhos da área (RIECHE et al., 2007; ASSIOTIS; TZANOV, 2006; NG et al., 2002), utilizando nodos de baixo custo e recursos heterogênos distribuídos geograficamente. No entanto, para tornar viável a utilização de tal abordagem, é necessário otimizar o uso de largura de banda e lidar com a não-uniformidade dos recursos disponíveis para servir o jogo. Neste capítulo serão apresentados o tema e motivação da dissertação, que são os jogos multijogador e o alto custo dos jogos online maciçamente multijogador (seções 1.1 e 1.2), assim como os objetivos deste trabalho (seção 1.). Por fim, na seção 1.4, será dada uma visão geral da estrutura do texto. 1.1 Jogos Multijogador Nas últimas décadas, desde o surgimento do computador pessoal, jogos de computador têm se popularizado de maneira crescente. Mais ainda, após o surgimento da Internet, com conexões domésticas cada vez mais baratas e mais rápidas, jogos online multijogador têm merecido atenção especial. Estes jogos se caracterizam por haver vários participantes interagindo uns com os outros, utilizando uma conexão através da Internet entre seus dispositivos computacionais, que são geralmente computadores pessoais ou consoles (dispositivos computacionais específicos para jogos). Este tipo de jogo pode ser dividido em vários gêneros, como por exemplo: FPS: first-person shooting, ou jogos de tiro com visão em primeira-pessoa, em que cada jogador controla um personagem que dispõe de diferentes armas, com as quais enfrenta monstros ou personagens de outros jogadores. São caracterizados por ação rápida, incluindo atirar, mover-se, esquivar-se etc.; RTS: real-time strategy, ou jogos de estratégia em tempo-real, onde cada jogador controla um exército, mas suas ações são executadas simultaneamente às ações dos outros jogadores, ao invés de serem separadas em turnos. A ação é mais lenta que em jogos FPS; RPG: role-playing game, ou jogo de interpretação de papéis, no qual cada jogador tem um personagem que evolui com o tempo, adquirindo mais poder e acumulando

14 tesouros. Jogos deste tipo são caracterizados por não terem um início ou fim de partida definidos, constituindo um mundo virtual de estado persistente. Os jogadores então podem evoluir seus personagens, desconectarem-se e reconectarem-se mais tarde para continuarem jogando a partir do ponto onde pararam. Como exemplos de jogos multijogador online conhecidos, podem ser citados Quake (ID SOFTWARE, 1996), um jogo do gênero FPS lançado em meados da década de 90; Starcraft (BLIZZARD, 1998), da mesma época, porém consistindo de um jogo RTS; Counter-Strike (VALVE, 2000), FPS lançado em 2000 e Diablo II (BLIZZARD, 2000), RPG lançado no mesmo ano. 1.2 Jogos Online Maciçamente Multijogador (MMOGs) Da mesma forma que jogos de computador evoluíram para jogos multijogador on-line após a popularização da Internet, evoluiu-se em seguida para jogos online maciçamente multijogador (ou MMOG, massively multiplayer online games), graças ao barateamento das conexões à Internet e o aumento da sua velocidade. Jogos deste tipo têm se popularizado bastante nos últimos tempos. Além de poderem ser jogados on-line, permitem a interação simultânea de um grande número de participantes. Nos casos de maior sucesso, como World of Warcraft (BLIZZARD, 2004), Lineage II (NCSOFT, 200) e EVE Online (CCP, 200), por exemplo, é dado suporte a uma base de dezenas a centenas de milhares de jogadores simultâneos (CHEN; MUNTZ, 2006). Estes jogadores podem, então, interagir entre si e com o ambiente virtual do jogo. Uma das principais características destes jogos, presente em quase todos os MMOGs comerciais, são as partidas muito longas. Em alguns MMORTS (MMOGs de estratégia em tempo real), como Travian (TRAVIAN, 2004), as partidas chegam a durar de seis meses a um ano. Já nos MMORPGs (MMOGs no estilo de RPG), como é o caso do World of Warcraft, as partidas não têm um momento determinado para que acabem. Os mundos destes jogos são tão vastos e populosos no que diz respeito a número de jogadores, que eles passam a evoluir e modificar seu estado independentemente de parte dos jogadores estarem jogando ou não, pois sempre existe alguém conectado dando continuidade à partida. Por esta razão, espera-se que cada jogador possa desconectar-se e continuar jogando mais tarde, sem ter que recomeçar do zero. Além disso, espera-se que as alterações feitas sobre o próprio mundo do jogo persistam, não importando quantas vezes cada jogador entrou e saiu. Geralmente, cada jogador controla uma entidade chamada de avatar, que nada mais é que sua representação no ambiente virtual um personagem que executa as ações determinadas pelo jogador, que dessa forma passa a interferir na história e no encaminhamento do jogo. Para que a partida se mantenha consistente para os diferentes participantes, cada ação executada por cada avatar deve ser processada pelo servidor, que calculará o estado resultante dessa ação no jogo. Esse novo estado é então difundido para os outros jogadores. Outras alterações no mundo do jogo, como destruição ou criação de objetos no ambiente, e eventos, como ações de personagens controlados pelo servidor, devem também ser transmitidos aos jogadores envolvidos. É então através destes envios de comandos do jogador e recebimento do novo estado do servidor que os jogadores conseguem interagir entre si e com o mundo simulado no jogo. No entanto, percebe-se que tal mecanismo pode facilmente saturar a banda e sobrecarregar o(s) processador(es) do servidor. Geralmente o que se faz é montar uma infraestrutura que dispõe de um grande servidor central, geralmente um cluster com seus no-

1 dos ligados por uma rede local de alta velocidade e baixo atraso, com conexão à Internet de algumas centenas ou milhares de MBps (FENG, 2007). O maior custo advém da manutenção desta conexão, que visa a enviar para cada jogador o estado mais recente do jogo sempre que este mudar, dentro de um limite estabelecido de atraso, que irá depender do gênero do jogo. É aí que surge a idéia de utilizar abordagens descentralizadas, com o propósito de desonerar o servidor do jogo. Diversas abordagens foram propostas para prover um suporte distribuído e, portanto, mais barato para jogos MMOG (capítulo 2, seção 2.1). Para este trabalho, será proposto o uso de um modelo de servidor distribuído, composto por nodos geograficamente dispersos, conectados através da Internet. No entanto, para evitar que o custo do sistema como um todo seja semelhante ao custo de um servidor tradicional, é necessário fazer algumas otimizações, que é o objetivo deste trabalho. 1. Objetivos O objetivo deste trabalho é tornar mais viável o uso de um sistema de nodos de baixo custo geograficamente distribuídos como servidor para jogos MMOG. Isto é feito com a introdução de novas técnicas que visam a otimizar o uso dos recursos desse sistema e a gerenciá-los de maneira mais eficiente, reduzindo o overhead causado pela própria distribuição do servidor do jogo, além de buscar não sobrecarregar nodos que o componham. Mais especificamente, tem-se por objetivo: Criar um algoritmo que reduza o uso de largura de banda pelos nodos servidores; Criar um mecanismo de distribuição e de balanceamento dinâmico de carga que distribua a carga entre os nodos de maneira proporcional e justa, além de reduzir, tanto quanto possível e viável, o overhead causado pela própria distribuição. Através de simulações em software, como será mostrado ao longo do texto, demonstrou-se que tais objetivos foram alcançados para jogos em que existe informação de localização das entidades do jogo no ambiente virtual, validando as propostas apresentadas aqui. 1.4 Organização do texto Para cumprir o objetivo deste trabalho, que é lidar com recursos escassos e heterogêneos no sistema servidor, foram propostas duas abordagens. A primeira consiste em uma otimização do uso de largura de banda do servidor, através de um novo algoritmo de gerenciamento de interesse. A segunda consiste em um esquema de balanceamento de carga que aloca a cada nodo servidor uma carga proporcional à sua capacidade. No capítulo 2, serão apresentados trabalhos relacionados à distribuição do suporte de rede a jogos MMOG, assim como o porquê de se decidir por um sistema servidor, ao invés de outras abordagens existentes. Também serão apresentados trabalhos relacionados especificamente com as propostas desta dissertação, que são gerenciamento de interesse e balanceamento dinâmico de carga. No capítulo 4, será apresentado o algoritmo proposto para gerenciamento de interesse, assim como as simulações realizadas e os resultados obtidos. No capítulo, será apresentado em detalhes o esquema de balanceamento de carga e os algoritmos propostos que o compõem, além das simulações realizadas e seus resultados. Por fim, no capítulo 6, são apresentadas as conclusões deste trabalho e possibilidades para trabalhos futuros.

16 2 TRABALHOS RELACIONADOS Neste capítulo, serão apresentados alguns trabalhos relacionados ao tema de pesquisa desta dissertação. Serão apresentadas algumas abordagens propostas na literatura para a distribuição do suporte aos jogos MMOG e o que falta nas abordagens que já existem (seção 2.1). Além disso, serão apresentados trabalhos relacionados a gerenciamento de interesse (seção 2.2) e a balanceamento dinâmico da carga do jogo entre os nodos servidores (seção 2.). 2.1 Distribuição da infra-estrutura de suporte ao MMOG A arquitetura cliente-servidor supre diversos aspectos necessários para a execução satisfatória de jogos do tipo MMOG, o que inclui um alto nível de controle sobre o sistema como um todo, facilitando tarefas como autenticação, persistência e segurança. Porém isso custa caro, como já foi dito, além de ser um possível gargalo. Objetivando minimizar este problema, foram propostas algumas alternativas. Uma delas é a de usar computação agregada, onde um cluster, ao invés de um computador único, faz o papel de servidor. Tal abordagem tem um ganho expressivo de poder de processamento, mas não resolve todos os problemas dos jogos online maciçamente multijogador. Deve-se prover também a largura de banda necessária para dar suporte ao tráfego intenso entre o servidor e os jogadores. Uma maneira de se distribuir o suporte a MMOGs é utilizando a arquitetura para-par, onde se divide a simulação entre os computadores envolvidos. Pode-se ter um sistema sem qualquer servidor, onde os pares (antes clientes), que são as máquinas dos jogadores, entram em algum tipo de acordo para os diversos passos da simulação. No que se refere à escalabilidade, tal abordagem não é ótima, pois garantir esse "acordo" é custoso em termos de troca de mensagens (LAMPORT; SHOSTAK; PEASE, 1982). Ainda que seja eleito um dos pares para decidir o andamento da simulação, ainda haverá o problema de que todos os pares precisarão trocar mensagens com todos. Tendo-se n pares, há uma complexidade de O(n 2 ) trocas de mensagem para cada passo da simulação. É evidente que tal abordagem não é tão escalável quanto se possa querer para um sistema onde se pretende executar um jogo online maciçamente multijogador. Além disso, seria necessário distribuir o armazenamento e a recuperação dos estados do jogo. Alguns trabalhos já foram realizados no sentido de tornar jogos em redes par-a-par mais escaláveis, como (SCHIELE et al., 2007; RIECHE et al., 2007; HAMPEL; BOPP; HINN, 2006; EL RHALIBI; MERABTI, 200; IIMURA; HAZEYAMA; KADOBAYA- SHI, 2004; KNUTSSON et al., 2004). Por exemplo, para reduzir o tráfego entre os pares, cada par pode enviar atualizações de estado apenas àqueles que tiverem interesse nas mesmas. Para atingir este objetivo, (SCHIELE et al., 2007) sugere que o ambiente virtual seja

17 dividido em regiões. O objetivo disto é que cada região funcione como se fosse um jogo independente, de menor escala. Os jogadores cujos avatares estivessem em determinada região poderiam formar uma pequena rede par-a-par, e decidirem entre eles o andamento do jogo naquela área do ambiente virtual. Quando um avatar se movesse de uma região para outra, deixaria o grupo da primeira e se uniria ao grupo da sua nova região. Para que o ambiente seja contíguo, ou seja, para que avatares possam mover-se livremente entre regiões adjacentes, alguns dos pares mantêm conexões com pares das regiões vizinhas, e é através destes pares que se consegue as informações necessárias para que haja essa transferência de grupo. Ainda na proposta de (SCHIELE et al., 2007), cada região tem um coordenador. O coordenador é eleito entre os pares ali presentes e se encarrega, apenas, de decidir para quem cada atualização de estado interessa ele não intermedia as trocas de mensagens entre os pares, que se comunicam diretamente entre si. No entanto, tal abordagem se baseia no fato de que o coordenador é confiável, o que não pode ser garantido, já que o software utilizado pelo jogador pode ter sido alterado de forma a se comportar de maneira incorreta a fim de beneficiá-lo. Outra abordagem seria a de eleger múltiplos coordenadores por região, mas isso implicaria a implementação de algum mecanismo de votação, além de depender da disponibilidade de pares para gerenciarem. Por fim, não seria eliminada a necessidade de cada par enviar atualizações de estado a diversos outros pares. Existem também as propostas de arquiteturas híbridas (VILANOVA et al., 2008; CHEN; MUNTZ, 2006), que utilizam servidores ao mesmo tempo em que fazem uso de infra-estrutura par-a-par. Nestas propostas, pares e servidor dividem a simulação do jogo. Em (VILANOVA et al., 2008), o mundo do jogo é divido em espaço social e espaços de ação. O primeiro é voltado para interações sociais, como conversar, trocar objetos do mundo do jogo, formar grupos etc., que são ações que não impõem grande peso sobre o servidor. No entanto, se os jogadores quiserem, por exemplo, lutar que é o principal objetivo na maioria dos jogos MMOG, eles têm de requisitar ao servidor a criação de um espaço de ação, dentro do qual a interação é mais rápida e com pouca tolerância a atrasos de comunicação. Este espaço é uma instância do jogo, isolada do resto do mundo, dentro da qual um número limitado de jogadores formam uma pequena rede par-a-par, sendo eles próprios responsáveis por simular o jogo e atualizar seus companheiros daquele espaço de ação. Para resolver inconsistências da simulação devido à falta de ordenação das mensagens, um dos jogadores é eleito como super-peer, sendo responsável por ordenar eventos que sejam "fortemente acoplados", cuja ordem interfere de maneira significativa no andamento do jogo. Essa abordagem apresenta alguns problemas, como o fato de não poder haver interações de luta, por exemplo, entre um grande número de jogadores. Além disso, nada garante que o par escolhido para ser o super-peer seja confiável. Se pertencer a um jogador desonesto, ele pode ordenar os eventos de maneira a beneficiar aquele jogador. No mais, o problema de sobrecarregar a banda dos pares é contornado simplesmente estabelecendo um limite para o número de participantes em cada grupo de ação, quando na verdade é desejável que nos MMOGs haja um grande número de jogadores interagindo entre si, não apenas em situações sociais, mas também em situações mais dinâmicas. Já na proposta de (CHEN; MUNTZ, 2006), o ambiente virtual é dividido em regiões, cada uma gerenciada por um dos pares, que atua como um sub-servidor. É para ele que cada um dos outros participantes naquela região envia suas ações, que lá são processadas e seu resultado é encaminhado aos pares interessados naquela ação. Isto pode gerar problemas de segurança e disponibilidade, já que não há garantias de que aquele par é confiável para servir aquela região, ou que ele irá permanecer no sistema enquanto for necessário.

18 Para prover tolerância a falhas, os autores sugerem o uso dos agregados de pares que consistem no gerenciador de região, mais pares reserva. Esses nodos reserva recebem do gerenciador da região as ações recebidas de jogadores e as processam, mantendo uma réplica do estado do jogo contido no gerenciador daquela região. Além de prover robustez ao sistema, no caso do gerenciador sofrer colapso, estes nodos reserva podem detectar falhas na simulação supondo que o gerenciador da região não corrompeu as mensagens de ação dos jogadores antes de enviá-las e executar procedimentos de recuperação. Porém, tal abordagem não resolve o problema do par eleito para ser o gerenciador da região não ser confiável, pois não há qualquer tipo de acordo entre ele e seus reservas em relação ao andamento do jogo. Por fim, se um nodo gerenciador estiver sobrecarregado, ele simplesmente devolve ao servidor parte da carga que lhe foi atribuída, mantendo a dependência de uma infra-estrutura centralizada. Outra arquitetura híbrida é a do FreeMMG (CECIN et al., 2004). Nela, os pares se organizam de maneira par-a-par em cada região do ambiente virtual e o servidor intermedia a comunicação entre diferentes regiões. Novamente, tem-se o problema da segurança: os pares dentro de uma região controlam a simulação que ocorre ali, podendo subvertê-la. É feita uma abordagem probabilística, utilizando um par selecionado aleatoriamente de outro ponto do ambiente para verificar a simulação naquela região. Espera-se que, caso os pares naquela região desejem entrar em conluio para subverter o jogo, pelo menos o nodo que foi inserido ali detecte as ações inválidas e reporte ao servidor. No entanto, além de não garantir completamente a segurança, persiste o problema de poder haver muitos pares se comunicando com muitos, o que pode comprometer a qualidade do jogo. Já foram propostos alguns modelos que sugerem o uso de clientes conectados a um servidor distribuído. Em (ASSIOTIS; TZANOV, 2006), por exemplo, é proposta a divisão do mundo virtual em regiões menores, cada uma atribuída a um diferente nodo do sistema servidor. Os autores tratam a questão da consistência utilizando um mecanismo de travas a cada entidade presente no jogo é associada uma trava, que precisa ser obtida antes de algum dos servidores fazer quaisquer alterações. Além disso, tentou-se atacar o problema dos pontos de interesse (aglomerados de jogadores em uma área relativamente pequena do ambiente virtual) através do particionamento recursivo da área sobrecarregada, até que esta sobrecarga seja eliminada ou não houver mais servidores disponíveis. No entanto, há um limite para este reparticionamento, pois áreas muito pequenas implicam avatares migrando entre regiões com maior freqüência e, conseqüentemente, em um tráfego maior entre os servidores. Por fim, os autores desse trabalho, assim como em vários outros com propostas semelhantes (NG et al., 2002; CHERTOV; FAHMY, 2006; LEE; LEE, 200), consideram que os nodos servidores estão conectados através de uma rede de alta velocidade e pouco atraso, sendo que suas soluções são apenas parcialmente aplicáveis em um cenário com recursos altamente dinâmicos e voláteis, como são as redes par-a-par montadas com recursos de voluntários. Tais redes têm como problemas inerentes: nós com baixa disponibilidade e dependabilidade, largura de banda escassa e baixo poder de processamento, quando comparada com servidores dedicados mantidos por empresas fabricantes de MMOGs. O modelo que se pretende utilizar é o de servidor distribuído. Porém os trabalhos da área ignoram que possa haver atraso ou escassez de largura de banda entre eles, além de não resolverem a questão dos pontos de interesse por completo. Por estas razões, buscouse revisar na literatura propostas existentes para atacar estas duas questões, a partir das quais foram criadas as propostas deste trabalho. Dividiu-se a revisão em duas abordagens: gerenciamento de interesse (seção 2.2) e balanceamento de carga (seção 2.).

19 2.2 Gerenciamento de interesse O gerenciamento de interesse inclue técnicas que permitem aos participantes expressar seu interesse em apenas um subconjunto das informações disponíveis, selecionando o que lhes é relevante (SMED; KAUKORANTA; HAKONEN, 2002a; BENFORD et al., 2001; MORSE; BIC; DILLENCOURT, 2000). O objetivo disto é reduzir o número de mensagens transmitidas através da especificação dos destinatários potencialmente interessados. Uma expressão do interesse de um participante é chamada de área de interesse, ou ADI, que geralmente é definida de acordo com a capacidade do avatar daquele participante para perceber as entidades do mundo simulado. De maneira simples, uma ADI é um subespaço do ambiente virtual onde a interação ocorre. No que se refere a gerenciamento de interesse, trabalhos como (MORSE et al., 1996; RAK; VAN HOOK, 1996; ZOU; AMMAR; DIOT, 2001; MORGAN; LU; STOREY, 200) e (MINSON; THEODOROPOULOS, 200) podem ser citados. Em (RAK; VAN HOOK, 1996), é proposto um esquema de gerenciamento de interesse baseado em um ambiente virtual dividido em células de uma grade. A cada célula está associado um grupo de multicast. Cada participante da simulação se subscreve então no grupo de multicast da célula onde ele se encontra, assim como de células vizinhas se estiverem ao alcance de sua visão. Cada participante envia então suas atualizações de estado apenas ao grupo de multicast da região onde se encontra. Em (ZOU; AMMAR; DIOT, 2001), também são considerados esquemas de gerenciamento de interesse baseados em grupos de multicast. É feita uma comparação entre a formação de grupos baseada em célula, onde cada um está associado a uma célula de uma grade que compõe o ambiente virtual, e agrupamento baseado em objetos, onde para cada objeto existe um grupo multicast associado. Verificou-se que há uma compensação ou tradeoff entre o custo das mensagens de controle dos grupos de multicast e o custo das mensagens de atualização de estado propriamente ditas. Um esquema de gerenciamento de interesse que utiliza um middleware orientado a mensagens é apresentado em (MORGAN; LU; STOREY, 200). Dentre outros aspectos, este esquema faz uma predição do que será o interesse de determinado participante no futuro, baseado na posição e vetor velocidade do mesmo no ambiente virtual. Dessa forma, cada um começa a receber atualizações de estado de entidades que não estão ainda ao alcance de sua visão, mas que provavelmente estarão em um futuro próximo, tornando seus estados disponíveis assim que elas estiverem dentro do campo de visão. Em (MORSE et al., 1996), é feito um apanhado de sistemas que utilizam a técnica de gerenciamento de interesse, salientando quais critérios são utilizados por cada um. É apresentada então uma taxonomia de tais sistemas, classificando-os de acordo com: modelo de comunicação, foco da filtragem e domínio de responsabilidade. O modelo pode ser unicast, multicast ou broadcast. O foco da filtragem refere-se a que tipo de características são observadas de cada objeto para realizar esta filtragem: podem ser intrínsecas, como o valor de atributos do objeto (e.g. coordenadas exatas de sua localização), ou extrínsecas, como a qual grupo de multicast ele está associado. Por fim, o domínio de responsabilidade atribuída a um gerenciador de interesse, que verifica para quem cada estado é relevante, pode ser dinâmico ou estático. Por exemplo, se cada gerenciador é designado para controlar uma área fixa do ambiente virtual, seu domínio de responsabilidade é estático, mas se ele controla uma área que possa aumentar ou diminuir de tamanho, ou mover-se, seu domínio de responsabilidade é dinâmico. Levando em consideração que o modelo de comunicação multicast não é amplamente suportado na Internet (EL-SAYED, 2004), neste trabalho optou-se por seguir o modelo

20 unicast, considerando que cada broadcast consiste na verdade em um conjunto de sucessivas transmissões unicast, uma para cada destino. Além disso, utiliza-se filtragem intrínseca e domínios de responsabilidade dinâmicos, para que haja maior precisão e, conseqüentemente, uma maior redução no tráfego de atualizações de estado (MORSE et al., 1996). 2. Balanceamento de carga Nas próximas seções, serão apresentados os trabalhos e princípios utilizados nas abordagens de outros autores. Embora apontem direções que se podem tomar para resolver o problema de distribuição e balanceamento de carga dinâmico de MMOGs, não o resolvem por completo, por razões que serão melhor detalhadas ao longo do texto. Com base em alguns desses princípios a seguir, e em pesquisa e implementação realizadas, será definido o esquema de balanceamento de carga aqui proposto. 2..1 Microcélulas e macrocélulas A carga do jogo está fortemente ligada aos avatares dos jogadores. Os avatares, por possuírem uma localização em um ambiente virtual, apresentam a característica de localidade, que pode e deve ser explorada em um mecanismo de balanceamento de carga. Uma maneira de fazer uso da localidade dos avatares é agrupá-los de acordo com a posição ocupada por eles no ambiente virtual. A questão seria a de como formar estes grupos. Uma maneira de fazer isto seria dividindo o mundo do jogo em várias células conectadas entre si. Cada célula consistiria em uma área do mundo, com conteúdo e características próprios, que seria delegada a um nodo servidor. A forma mais simples de fazer isto é com uma grade de células de mesma área e formato. Porém, o formato e a disposição destas células irá influenciar no tráfego gerado pelas mesmas entre os servidores. Por exemplo, um ambiente bidimensional poderia ser dividido em uma grade de células quadradas (Figura 2.1(a)). Neste caso, cada uma destas células teria oito vizinhos, em média células nas bordas do mapa poderiam ter cinco ou três vizinhos apenas. Um servidor é considerado vizinho de outro quando administra uma célula que é vizinha a uma célula do outro servidor. Quanto mais servidores vizinhos, maior o tráfego entre servidores, e maior o overhead causado por esta comunicação. Uma boa distribuição, então, seria utilizando células hexagonais, cada uma com seis vizinhos (Figura 2.1(b)). Outra possibilidade seria utilizando fileiras alternadas de células quadradas, onde cada fileira seria deslocada o equivalente à metade do comprimento de uma célula (Figura 2.1(c)). Uma questão importante deste design é que o conceito de célula é transparente para os jogadores. Estes visualizam um mundo vasto, único e não fragmentado, mesmo que estejam cruzando repetidamente as fronteiras entre diferentes células. Assim, é possível para eles moverem-se livremente através do ambiente virtual, independente de como é feita a distribuição. Obviamente, isso exige que as células se comuniquem, de maneira a atualizarem-se mutuamente e notificarem-se a respeito de eventos que ocorram próximo à fronteira entre elas, assim como a respeito da migração de jogadores entre uma e outra. Embora essa abordagem com células distribua a carga entre diversos servidores, não há garantias de que essa distribuição será uniforme, devido à grande mobilidade dos jogadores e à existência de pontos de interesse. Uma das idéias propostas na literatura (DE VLEESCHAUWER et al., 200) também segue o princípio de dividir o ambiente virtual em células de tamanho e posição fixos, porém essas células são relativamente

21 C0,0 C0,1 C0,2 C0,0 C0,1 C0,2 (a) Divisão em grade: 8 vizinhos por célula C1,0 C1,1 C1,2 C2,0 C2,1 C2,2 C1,0 C1,1 C1,2 C2,0 C2,1 C2,2 (b) Divisão hexagonal: 6 vizinhos por célula C0,0 C0,1 C0,2 C1,0 C1,1 C1,2 C2,0 C2,1 C2,2 (c) Divisão com fileiras deslocadas: 6 vizinhos por célula Figura 2.1: Diferentes tipos de divisão em células pequenas ou microcélulas e podem ser agrupadas, formando um espaço contínuo chamado de macrocélula. Cada macrocélula é então designada a um diferente servidor, que passa a administrar não apenas uma grande célula de tamanho e posição fixos, mas um conjunto variável de pequenas células. Estas microcélulas podem então ser transferidas dinamicamente entre diferentes macrocélulas, de maneira a manter a carga em cada um dos diferentes servidores abaixo do limite por ele suportado. Obviamente, as microcélulas designadas ao mesmo nodo servidor não gerarão tráfego adicional para sincronizarem-se entre si, porém não se poderá conhecer previamente o overhead de sincronização entre diferentes macrocélulas, pois o número de vizinhos que cada macrocélula terá é imprevisível, assim como o seu formato. Contudo, demonstrouse (DE VLEESCHAUWER et al., 200) que esse overhead é compensado pela melhor distribuição da carga do jogo entre os servidores. A Figura 2.2 ilustra a divisão de um ambiente virtual bidimensional em microcélulas e o agrupamento destas em macrocélulas dinâmicas, que podem se adaptar à distribuição de avatares. 2..2 Balanceamento com informações locais No trabalho de (LEE; LEE, 200), também é proposto um esquema dinâmico de balanceamento de carga para os servidores de um sistema multi-servidor de ambiente virtual, levando em conta que os usuários podem estar distribuídos através deste mundo de maneira não uniforme. De acordo com o esquema proposto pelos autores, um servidor sobrecarregado inicia o processo selecionando um conjunto de outros servidores para fazerem parte da redistribuição de carga. O conjunto de servidores selecionados dependerá do nível de sobrecarga do servidor inicial, assim como da quantidade de recursos ociosos dos outros servidores. Após a formação desse conjunto, seus elementos repartirão as porções do ambiente virtual que lhes pertencem utilizando um algoritmo de particionamento de grafo, de forma que os servidores envolvidos tenham carga final de trabalho semelhante. O principal aspecto da solução proposta pelos autores foi a utilização de informações locais (do servidor que iniciou o processo de balanceamento e de seus vizinhos), ao invés de informações globais (todos os servidores do sistema se envolveriam no balanceamento). A primeira apresenta pouco overhead, mas pode não resolver o problema de maneira eficiente em poucos passos, já que servidores sobrecarregados tendem a estar ad-

22 R1 R2 R R4 Figura 2.2: Microcélulas agrupadas em quatro macrocélulas (R 1, R 2, R e R 4 ) jacentes. Já a abordagem global é capaz de dividir a carga de trabalho da forma mais equilibrada possível, mas sua complexidade cresce rapidamente com o aumento do número de servidores envolvidos. A solução apontada no trabalho então é de o balanceamento de carga envolver apenas um subconjunto de servidores, sendo que sua cardinalidade varia de acordo com a necessidade (se os vizinhos do servidor que disparou o balanceamento de carga estiverem também sobrecarregados, são selecionados mais servidores). Dessa forma, tem-se um pouco mais de informação do que a abordagem local com um número fixo de servidores envolvidos, mas sem o problema da complexidade inerente à abordagem global. Para atacar o problema, os autores também subdividem o ambiente virtual em células semelhantes às microcélulas retangulares, sendo que o número de servidores é muito menor que o número de células. As células são agrupadas em regiões ou macrocélulas e cada região é gerenciada por um servidor. Cada servidor mantém atualizadas as informações de estado dos usuários e lida com as interações entre avatares na região a ele dedicada. Cada usuário envia e recebe atualizações de estado através do servidor que gerencia a região na qual ele está jogando. Duas células são ditas adjacentes (ou vizinhas) se elas compartilharem uma fronteira. Analogamente, duas regiões, e seus respectivos servidores, são ditos adjacentes se existir um par de células adjacentes, cada uma das quais pertencendo a uma das duas regiões. Foi definida a carga de trabalho de uma célula como o número de avatares presentes naquela célula. Os autores assumiram que todos avatares atualizam seus estados na mesma frequência, de forma que a carga de processamento (computação e comunicação) que uma célula impõe a um servidor é proporcional ao número de usuários naquela célula. A carga de trabalho de uma região e seu servidor designado é definida como a soma das cargas de trabalho individuais das células que compõem aquela região. Cada servidor periodicamente avalia sua carga de trabalho e troca informações de carga com os servidores vizinhos. Assumiu-se, também, que estes servidores estão conectados através de uma

2 rede de alta velocidade. Dessa forma, o overhead de trocar informações de sobrecarga entre vizinhos é limitado e considerado negligenciável, se comparada com outros custos da distribuição de carga. Pelo mesmo motivo, também assumiu-se como negligenciável o overhead de comunicação entre servidores quando jogadores em diferentes regiões estão interagindo. 2..2.1 Seleção de grupo local para balancear a carga Um servidor dispara o balanceamento quando a carga atribuída a ele excede sua capacidade. Este servidor seleciona um conjunto de outros servidores para se envolverem com a distribuição. Primeiro, o servidor que iniciou escolhe o menos carregado dentre seus vizinhos e envia um pedido de que ele participe do balanceamento de carga. O vizinho escolhido rejeita o pedido se ele já está envolvido em outro grupo de balanceamento; caso contrário, ele responde ao servidor iniciador com a informação de carga de seus próprios vizinhos. Se o servidor vizinho que está participando não for capaz de absorver a carga de trabalho excedente do servidor iniciador, a seleção é executada novamente entre os servidores vizinhos de não apenas o servidor sobrecarregado, como também os vizinhos do vizinho escolhido na primeira fase. A seleção continua até que a carga de trabalho excedente do primeiro servidor possa ser absorvida isto é, a carga de trabalho de todos os servidores selecionados torna-se menor que um limite pré-definido. Os autores definiram este limite como sendo 90% da capacidade total do conjunto de servidores. O critério utilizado para esta escolha foi o de evitar o imediato reinício da balanceamento de carga se o limite fosse 100%, qualquer aumento da carga de algum servidor o tornaria sobrecarregando, disparando o balanceamento novamente. Sejam SELECIONADOS e CANDIDATOS dois conjuntos de servidores, ambos inicialmente vazios. Seja P a capacidade de cada servidor. O procedimento para determinar quais serão os servidores envolvidos é o seguinte: 1. O servidor que disparou o balanceamento, S i, é inserido em SELECIONADOS, que são os servidores envolvidos na distribuição de carga. Os servidores vizinhos do iniciador são adicionados em CANDIDATOS, que são os servidores que podem vir a participar da seleção. 2. De CANDIDATOS, é selecionado o servidor com menor carga de trabalho, S v ; então, S i envia um pedido a ele para participar na distribuição de carga (a) Se o servidor S v não está envolvido em outra distribuição de carga, ele responde ao servidor S i com a carga de trabalho de seus vizinhos. Quando S i recebe esta resposta, ele insere S v em SELECIONADOS e seus vizinhos são inseridos em CANDIDATOS, se eles já não estiverem dentro de SELE- CIONADOS ou de CANDIDATOS. (b) Se S v já está participando de outra distribuição de carga, ele rejeita o pedido e é removido do conjunto CANDIDATOS.. O passo 2 é repetido até que a carga de trabalho média dos servidores selecionados se torne menor que um limite: 0, 9 P. Para exemplificar o funcionamento do algoritmo, pode-se observar a Figura 2.. Todos os servidores têm a mesma capacidade, podendo cada um comportar 100 usuários. Primeiro, o servidor iniciador, S 6, é inserido em SELECIONADOS e seus vizinhos (S 2,