Motivação

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. Topologia • Jogadores se comunicam com uma proxy em rede local (~3ms) • Proxies se sincronizam por link Internet (~300ms)

11. Topologia • Tráfegos urgentes e não urgentes são combinados (1a e b) • Nenhum mecanismo é aplicado (2) • Empacotamento é usado (3)

12. 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)

13. 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

14. Middleware • Eventos chegam e talvez não execute diretamente o middleware • Para recuperar um valor válido: • Mecanismo de predição • Avaliação atrasada

15. 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

16. Artigo 2“A Grid-enabled Multi-server Network Game Architecture”Tianqi Wang, Cho-Li Wang, Francis C.M. LauDepartment of Computer Science and Information SystemsThe University of Hong Kong • 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.

17. 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

18. 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

19. 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.

20. Modelo Multi-Servidor • Camadas • Monitor • Gamelet • Comunicador

21. 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.

22. 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

23. 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

24. 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

25. Estrutura Gamelet • Componente de dados • Componente de tratamento

26. 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.

27. 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

28. 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

29. 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

30. 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