Un socket TCP vivo, unha parella WebSocket que responde e un progreso útil da aplicación son observacións distintas:

EvidenciaQue establece
Vitalidade no nivel TCPA ruta de transporte comprobada responde nese nivel
Un WebSocket Pong correspondenteA parella respondeu a esa trama de control
Un acuse da aplicaciónA aplicación confirmou unha operación segundo o seu propio protocolo

Un proxy directo adoita manter conexións separadas cara ao cliente e cara ao destino. A parella TCP do cliente é o proxy, mentres que un Ping dentro dun túnel establecido viaxa ata o punto final WebSocket.

Un Pong correspondente

O protocolo esixe que un Pong de resposta leve os datos de aplicación do Ping. Use esa correspondencia para identificar unha sonda pendente. Un Pong non solicitado está permitido, pero non pide acuse; enviar un tras cada mensaxe de datos achega unha evidencia distinta.

Preferide o mecanismo de latexo compatible coa biblioteca. O JavaScript do navegador necesita en cambio un contrato de latexo no nivel da aplicación. Escollede intervalos e limiares de fallo segundo a carga e a política de rede. As pausas de planificación ou un bucle de eventos sobrecargado poden incumprir un limiar agresivo sen demostrar que a rede falla.

Manteña o receptor en marcha

O cliente necesita entrada e saída continua para recibir e procesar tramas de control. Bloquear ese mecanismo pode facer que unha escaseza local pareza unha caída.

Ping xera tráfico de túnel, pero cada intermediario decide que satisfai a súa política de inactividade. Ningún latexo garante protección fronte a un límite absoluto de vida da conexión.

Unha parella pode responder a Ping mentres a súa aplicación deixa de producir actualizacións, e unha subscrición silenciosa pode ser saudable. Seguide por separado o último Pong válido e o evento de aplicación significativo cando ambos importan. Ante un fallo, conserve a ruta, os tempos transcorridos e a sonda pendente, e logo peche ou recupere mediante o ciclo de vida compatible.

Artigos relacionados