View
213
Download
1
Embed Size (px)
Citation preview
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