Artigo 1 “State replication for multiplayer games” Carsten Griwodz University of Oslo - Department of Informatics Artigo descreve um middleware para facilitar.

Apresentação em tema: "Artigo 1 “State replication for multiplayer games” Carsten Griwodz University of Oslo - Department of Informatics Artigo descreve um middleware para facilitar."— Transcrição da apresentação:

1 Artigo 1 “State replication for multiplayer games” Carsten Griwodz University 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 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. Lau Department of Computer Science and Information Systems The University of Hong Kong

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 Gamelet Caracterí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