Um socket TCP vivo, um par WebSocket responsivo e progresso útil da aplicação são observações diferentes:

EvidênciaO que estabelece
Vitalidade ao nível do TCPO caminho de transporte verificado responde nesse nível
Um WebSocket Pong correspondenteO par respondeu a esse quadro de controle
Uma confirmação da aplicaçãoA aplicação confirmou uma operação sob seu próprio protocolo

Um proxy direto normalmente mantém conexões separadas para o cliente e para o destino. O par TCP do cliente é o proxy, enquanto um Ping dentro de um túnel estabelecido viaja até o endpoint WebSocket.

Um Pong correspondente

O protocolo exige que um Pong de resposta carregue os dados de aplicação do Ping. Use essa correspondência para identificar uma sondagem pendente. Um Pong não solicitado é permitido, mas não pede confirmação; enviá-lo após cada mensagem de dados fornece evidência diferente.

Prefira o mecanismo de heartbeat suportado pela biblioteca. O JavaScript do navegador precisa, em vez disso, de umcontrato de heartbeat da aplicação. Escolha intervalos e limites de falha conforme a carga de trabalho e a política de rede. Pausas no agendamento ou um event loop sobrecarregado podem perder um limite agressivo sem estabelecer que a rede falhou.

Mantenha o receptor em execução

O cliente precisa de I/O contínuo para receber e processar quadros de controle. Bloquear esse mecanismo pode fazer a escassez local de recursos parecer uma queda.

O Ping gera tráfego no túnel, mas cada intermediário decide o que satisfaz sua política de ociosidade. Nenhum heartbeat garante proteção contra um limite absoluto de vida da conexão.

Um par pode responder ao Ping enquanto sua aplicação deixa de produzir atualizações, e uma assinatura silenciosa pode estar saudável. Acompanhe o último Pong válido e o evento significativo da aplicação separadamente quando ambos importam. Em caso de falha, retenha a rota, os tempos decorridos e a sondagem pendente, e então feche ou recupere pelo ciclo de vida suportado.

Artigos relacionados