Artigo 1“State replication for multiplayer games”

Carsten GriwodzUniversity of Oslo - Department of Informatics

Artigo descreve um middleware para facilitar o desenvolvimento e execução de jogos massivos multijogador

Motivação

Jogos massivos multiplayer:Lidam com problemas de escalabilidade e

latência Latência deriva:

Das grandes distâncias geográficas entre jogadores Das restrições de banda dos usuários

Problemas surgem da necessidade de suportar tráfego de diferentes elementos de jogos concorrentemente

Urgência não é necessária para todos os dados

Objetivos

Mostrar maneira simples de separar tipos de tráfego Em uma arquitetura proxy Através de definição de níveis de urgência e

relevância para diferentes tipos de tráfego Separação permite preferência de tráfegos de

baixa latência sobre outros no mesmo jogo

Proposta Middleware para utilização desta infra-

estrutura Supõe que desenvolvedores de jogos

podem especificar requisitos estáticos para os objetos distribuídos:

Em tempo de projeto Em tempo de desenvolvimento

Combinação de geração de código e suporte em tempo de execução para o uso da arquitetura de rede

Infra-estrutura de Distribuição

Mapeamento de exigência Uma urgência maior indica uma necessidade

de uma latência menor Uma maior relevância indica uma

necessidade maior de confiabilidade

Infra-estrutura de Distribuição Protocolo

Multicast IP Poucos ISPs suportam IP Multicast Esforço considerável para proteger grupos

Multicast de eavesdropping (espionagem) Consumo de muitos endereços Multicast Group Membership não é fixo

Servidores proxy: UDP, TCP UDP entre proxies TCP é uma opção entre cliente e proxy

Infra-estrutura de Distribuição Reordenamento:

Um jogo distribuído deve ser capaz de tratar chegada não ordenada de eventos

Conexões congestionadas: Abordagem proposta não tem meios de

proteger o jogo de congestionamento entre um cliente e seu proxy associado

Se não é transiente, a abordagem irá ainda resultar em preferência de entrega de eventos urgentes

Infra-estrutura de Distribuição Empacotamento:

Combinam em um pacote eventos de prioridade baixa visando atingir um MTU

Maioria dos pacotes urgentes provoca uma transmissão imediata, mesmo se não atinge MTU

Operação: Fila de empacotamento é ordenada por:

Urgência Deadline de transmissão mais curto

Se eventos estão na mesma fila, são relevantes a todos os receptores

Infra-estrutura de Distribuição

Questões de desempenho:Em clientes e servidores, empacotamento

aumenta o desempenho: Reduz interrupções para recebimento de pacotes

Porém, escalabilidade dos proxies pode ser limitada:

Desmontagem de pacotes e nova montagem pode consumir muitos recursos computacionais

Topologia

Jogadores se comunicam com uma proxy em rede local (~3ms)

Proxies se sincronizam por link Internet (~300ms)

Topologia Tráfegos urgentes

e não urgentes são combinados (1a e b)

Nenhum mecanismo é aplicado (2)

Empacotamento é usado (3)

Middleware

o middleware: API, geração de código automático... “esconde” parcialmente a

rede do desenvolvedor do jogo, oferecendo uma visão de objetos (local ≈ remoto)

Middleware Contexto da aplicação: o

que a aplicação (desenvolvedor do jogo) manipula

Quando a variável é lida pela interface, “coisas” acontecem por trás, que escondem propriedades como: Cópia mestre: local ou

remota? É realmente necessário

avaliar a expressão agora? Qual versão? (mais ou

menos eventos aplicados)

• Contexto de transporte: trata questões de comunicação de objetos• Contexto de aplicação: cópia local do jogo é executada sobre ele, com consciência limitada da distribuição dos objetos

Middleware Eventos chegam e

talvez não execute diretamente o middleware

Para recuperar um valor válido: Mecanismo de

predição Avaliação

atrasada

Conclusão Nível de urgência maior :

Dá aos eventos precedência no encaminhamento Reduz o atraso médio fim-a-fim

Nível de relevância alto Proteção a perdas

Middleware proposto: Provê suporte em tempo de compilação e em tempo

de execução Separa o contexto de transporte e o contexto de

aplicação para reduzir visibilidade da rede

Modelo multi-servidor baseado na tecnologia de grade para supportar MNGs.

Um prototipo de jogo multi-jogador 3D foi implementado usando “gamelets” caracterizado por sua grande mobilidade porque suporta balanceamento de carga dinâmico.

Artigo 2“A Grid-enabled Multi-server Network Game Architecture”

Tianqi Wang, Cho-Li Wang, Francis C.M. LauDepartment of Computer Science and Information Systems

The University of Hong Kong

Motivação

Jogos de rede de multijugador(Multiplayer network games) Têm que ser escalavel Necessidade do desenho de uma arquitetura

que apóia a adaptabilidade Podem ocorrer facilmente desequilíbrios de

carga de trabalho, onde o compartilhamento de carga se torna crucial

Objetivo

Produzir um balanceamento de carga dinâmico através de modelo multi-servidor baseado na tecnologia de grade para suportar MNGs Dinâmico Escalavel Rentável

Proposta Arquitetura multi-servidor baseado na

tecnologia de grade para suportar MNGs“Gamelet", que representa uma lógica de

execução dentro de um mundo de jogo dividido em várias partes, e é caracterizado por sua grande mobilidade porque suporta balanceamento de carga dinâmico.

Um protótipo de jogo multi-jogador 3D foi implementado usando gamelets.

Modelo Multi-Servidor

CamadasMonitorGameletComunicador

Modelo Multi-Servidor Cliente contata o monitor

Monitor atribuirá um comunicador ao cliente

Cliente sempre enviará mensagens a este comunicador.

O comunicador expedirá as mensagens à correspondência gamelets

Depois de algum tratamento os estados são enviados diretamente aos clientes

Um monitor faz decisões sobre como ajustar a carga de trabalho entre os servidores e de quando aumentar ou diminuir o número deles.

Modelo Multi-Servidor Deveres de um

servidor: receber e processar

pacotes de comandos dos clientes, bufferizar os pacotes de comandos ordenadamente

executar os comandos de acordo com os requisitos de sincronização

controlar objetos dinâmicos e calcular os estados do mundo

Modelo Multi-Servidor Deveres do cliente:

encapsular comandos de usuário em pacotes de dados

enviar os pacotes ao comunicador

usar sua cache dos estados do jogo juntamente com quaiquer atualizações do servidor para interpretar o mundo virtual.

Detecção simples de colisão

Arquitetura Multi-servidor baseada em

“Gamelet”O Gamelet é um objeto que processa uma parte de um mundo virtual e dos jogadores. Pode ser executado em qualquer um dos servidores disponíveis e pode ser migrado a outros servidores

Estrutura Gamelet

Componente de dados

Componente de tratamento

Estrutura GameletCaracterística Loaw Awareness: prove

informações sobre a carga do servidor e a carga que esta usando o Gamelet

Remote control: permite que o processo de monitoramento migre o Gamelet e da a função da carga do servidor e da carga que esta usando o Gamelet.

Embedded Synchronization: permite sincronizar os Gamelet transparentemente.

Grid-enabled Multi-server Architecture

O Monitor de vez em quando supervisionará o funcionamento do gamelet

Quando um monitor encontra que um gamelet está na necessidade de uma migração, tratará de localizar uma nova referência a outro serviço Gamelet

O Comunicador armazena os pacotes entrantes temporariamente

O monitor dirigirá os velhos gamelet para transferir seu conteúdo ao novo gamelet

O monitor pedirá ao comunicador traçar um mapa da informação de maneira que todos os pacotes subseqüentes entrantes sejam transferidos consequentemente

Desenho do Protótipo e Implementação

Comunicação UDP: entre cliente, comunicador e

gamelets TCP: entre dois gamelets

Métrica de desempenho.

RT = RT*(1-LostRate) + (RT+TI)* LostRate

RT: tempo medio entre cada cliente que manda o pacote e a confirmação do servidor que a ordem foi executada

TI: intervalo de tempo entre dois pacotes consecutivos

LostRate: Taxa de perdida

CP: numero maximo de usuários que o sistema pode acomodar

Conclusão

O conceito de Gamelet, e um sistema escalavel de jogo multijogador com balanceamento de carga automático

Quando precisar de mais potencia e só adicionar um servidor ao sistema e não precisa reprogramar o jogo

Comparações O primeiro Artigo “State replication for multiplayer

games”foca em transparência para o programador O segundo Artigo “A Grid-enabled Multi-server

Network Game Architecture” foca em escalabilidade "automática" do lado-servidor

Um não excluí o outro, mas cada um aborda o problema com focos diferentes