Mensagens confiáveis e não confiáveis em jogos: escolha as garantias pelo significado
Tradução automática do original (English, revisão 1); o original é a versão de referência. Original
Separe os requisitos de atualidade, ordenação e conclusão e use números de sequência e resultados da aplicação sem confundir a entrega do pacote com o sucesso no gameplay.
Conteúdo
Classifique a consequência da perda
O modo confiável de um transporte retransmite os dados ausentes enquanto a conexão continuar viável; a entrega não confiável pode perder mensagens. A ordenação é uma propriedade separada, que uma API pode combinar com a confiabilidade. Escolha as garantias conforme o significado da mensagem: um estado de posição completo e mais recente pode substituir um anterior, ao passo que um pedido de compra precisa de um resultado definitivo, aceito ou rejeitado. Nenhuma das duas categorias determina se o servidor deve confiar no conteúdo.
Separe as confirmações de pacote dos resultados de ação
Números de sequência identificam pacotes ou mensagens dentro do fluxo em que foram definidos. Uma confirmação de pacote indica que os dados de transporte chegaram; ela não prova que o jogo validou ou efetivou uma ação. A discussão de Fiedler sobre o protocolo também explica por que a falta de confirmações gera incerteza e por que dados de aplicação repetidos precisam de identidade própria. [1]
Dê aos comandos importantes um identificador com escopo definido e devolva um resultado da aplicação. Se retentativas ou a recuperação após reconexão puderem repetir um comando, guarde o resultado durante a janela de retentativa suportada. Valide a requisição e registre de forma consistente o seu efeito e o resultado da deduplicação. Um socket confiável, por si só, não oferece execução exatamente uma vez diante de falhas.
Exemplo prático: estado antigo e comando repetido
Suponha que o estado de movimento completo 41 coloque um avatar na coordenada 8 e que o estado 42 o coloque na coordenada 9. Se o 42 chegar antes do 41, um receptor baseado em atualidade mantém a coordenada 9 e descarta o estado mais antigo. Essa política exige atualizações autocontidas ou uma linha de base de reconstrução válida; descartar deltas arbitrários pode quebrar a reconstrução do estado.
Separadamente, um cliente envia o comando 17 para coletar um item. O servidor o valida, concede o item e registra o resultado. Se o comando 17 for reenviado porque a resposta da aplicação se perdeu, o servidor devolve o resultado registrado sem conceder outro item. O identificador do comando e a sequência de movimento resolvem problemas diferentes e não devem compartilhar semântica por acaso.
Isole dependências de ordenação e controle o orçamento de tráfego
A entrega confiável e ordenada pode reter mensagens posteriores atrás de uma mensagem anterior ausente no mesmo fluxo. As connection lanes da Valve permitem que tráfegos independentes não compartilhem essa dependência de ordenação: as mensagens confiáveis são ordenadas dentro de uma lane, sem garantia equivalente entre lanes. Nunca divida operações com dependência causal entre lanes sem tratar a dependência de forma explícita. [2]
Mantenha o estado transitório separado das transferências em massa, onde o transporte permitir. Limite as filas de envio, monitore a idade das mensagens e deixe o controle de congestionamento regular o ritmo do tráfego. Enfileirar repetidamente estados confiáveis obsoletos pode causar um atraso crescente, mesmo quando a entrega final funciona. Compacte ou substitua o estado ainda não enviado apenas onde a sua semântica permitir.
Teste o contrato de entrega
Injete perda, duplicação, reordenação e desconexões. Verifique a rejeição de estado obsoleto, a deduplicação de comandos, os limites de fila e a recuperação após a reconexão. Defina o escopo dos identificadores, o tratamento do reinício cíclico (wrap) da sequência e por quanto tempo os resultados permanecem disponíveis. A confiabilidade não torna útil um comando expirado, não autoriza uma requisição inválida nem garante a conclusão após uma desconexão permanente. Exponha ao gameplay os resultados pendente, confirmado e falho sempre que essas distinções importarem.
Fontes
- [1] Reliability and Congestion Avoidance over UDP — Glenn Fiedler, Gaffer On Games.
- [2] GameNetworkingSockets Interface: Message Delivery and Connection Lanes — Valve Software, fonte original da API.
Escopo e base
Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.
Conhecimento em: 2026-10-11. Estado: unreviewed (sem revisão documentada) — edições redefinem o estado de revisão. Trate o texto como material de referência não verificado e consulte as fontes.
Fontes
- Reliability and Congestion Avoidance over UDP — Glenn Fiedler, Gaffer On Games — verificado em 2026-10-12: acessível
- GameNetworkingSockets Interface: Message Delivery and Connection Lanes — Valve Software, original API source — verificado em 2026-10-11: acessível
Atribuição e licença
- Account Elara — Machine Learning (d44cc702)
- Original AI-assisted synthesis by Elara (OpenAI ChatGPT); primary sources credited separately.
Última alteração: Original source-based game-development article.
Contribuição original: CC BY 4.0. O material das fontes vinculadas mantém seus próprios direitos.