Revisão do código-fonte de Quake 3: modelo de rede (2012)

Modelo de rede

• O modelo de rede de Quake 3 é a parte mais elegante do engine e enfatiza que, em ambientes rápidos, informações não recebidas na primeira transmissão não valem a pena ser retransmitidas.
• Usa UDP/IP, e não TCP/IP, porque a transmissão confiável do TCP/IP introduz latência.
• A pilha de rede é estendida com duas camadas mutuamente exclusivas: criptografia com chave pré-compartilhada e compressão com chave de Huffman pré-calculada.
• Destaca-se no lado do servidor um sistema que minimiza o tamanho dos datagramas UDP enquanto compensa a falta de confiabilidade do UDP.

Arquitetura

• O lado do cliente é simples: a cada frame, ele envia comandos ao servidor e recebe atualizações do estado do jogo.
• O servidor precisa propagar o estado mestre do jogo para cada cliente, levando em conta a perda de pacotes UDP.
• Há três elementos principais: o estado mestre do jogo, a transmissão dos comandos do cliente via Netchannel e snapshots armazenados em um buffer circular com os 32 estados de jogo mais recentes.

Sistema de snapshots

• Ao enviar atualizações para o cliente, o servidor sempre copia o estado mestre do jogo para o próximo slot de histórico do cliente e o compara com outros snapshots.
• Se não houver um snapshot válido, usa-se um "snapshot dummy" para gerar uma atualização completa.
• Quando o cliente confirma que recebeu a atualização anterior, apenas atualizações parciais são enviadas.
• Mesmo quando há perda de pacotes, o mesmo processo é seguido, enviando em uma única mensagem tanto as informações não recebidas anteriormente quanto as novas.

Resiliência de memória e C

• Quake 3 compara snapshots sem introspecção, e a posição de cada campo é pré-configurada por meio de arrays e diretivas do pré-processador.
• A estrutura netField_t é usada para definir a posição e o tamanho dos campos, permitindo transmitir as diferenças pela rede.

Pré-fragmentação

• O módulo NetChannel divide as mensagens em blocos de 1400 bytes antes do envio, evitando que os roteadores fragmentem os pacotes.
• A fragmentação por roteadores é custosa, pois bloqueia os pacotes na entrada da rede e, na saída, exige esperar por todos os fragmentos.

Mensagens confiáveis e não confiáveis

• O sistema de snapshots compensa datagramas UDP perdidos na rede, mas algumas mensagens e comandos precisam necessariamente ser entregues.
• Essa garantia é abstraída por meio do NetChannel.

[GN⁺]

Comentários no Hacker News

• Este artigo é muito interessante, assim como os anteriores. Mas o trabalho atual é entediante, então não sobra energia para projetos de hobby.
• Ouvi o termo "Isochronous" pela primeira vez quando o FireWire surgiu, e ele era citado para justificar o uso de UDP. Hoje é uma parte importante das especificações de USB/Thunderbolt.
• Link para o primeiro artigo da série: https://fabiensanglard.net/quake3/index.php
• A previsão e correção de latência são interessantes, e não usam transformação operacional (OT) complexa. Isso é mais simples, e o estado compartilhado precisa de uma fonte de verdade independente, não de um documento de edição colaborativa; o desenvolvimento é mais rápido e o desempenho é melhor.
• O código de rede do cliente original de Q3A funcionava bem em LAN, mas era sensível à latência em partidas remotas. Uma das mudanças interessantes do Quake Live foi o código de rede atualizado para jogo remoto. As conexões de internet também melhoraram no geral com o passar do tempo.
• Parece que o site está sofrendo o HN Hug of Death: <a conexão expirou>
• É um bom texto para ler numa manhã de sábado, tomando mate devagar. Um dos pequenos prazeres da vida.
• P: Existe algum recurso para aprender abordagens modernas para protocolos de jogos em tempo real?
• Provavelmente o número de ID do snapshot também é enviado ao cliente para confirmação?
• Ainda existe algum middleware open source à prova de bala?