Essa história de "Ping Pong" no contexto de OCPP (Open Charge Point Protocol) e WebSockets é, na verdade, uma das soluções mais importantes para evitar que os carregadores de veículos elétricos (Ponto de Carga) "parem de funcionar" do nada no seu sistema central (CSMS).

Em termos técnicos, isso se chama WebSocket Ping/Pong ou Keep-Alive.

Aqui está a explicação simples de por que isso existe e como funciona:

O Problema: A "Morte Silenciosa" da Conexão

Quando um carregador se conecta ao seu servidor via WebSocket (padrão do OCPP 1.6J e 2.0.1), ele abre uma porta de comunicação que deve ficar aberta o tempo todo. No meio do caminho entre o carregador e o seu servidor, existem roteadores, operadoras de internet (4G/5G) e firewalls.

Esses equipamentos de rede são gananciosos: eles não gostam de manter portas abertas se ninguém está falando nada. Se o carregador ficar muito tempo sem enviar nem receber nenhuma mensagem (por exemplo, à noite quando ninguém está carregando), o roteador da operadora pensa: "Ninguém usa essa conexão, vou fechar ela para liberar memória".

O pior de tudo: O roteador fecha a conexão sem avisar o carregador e sem avisar o seu servidor.

  • Do lado do seu servidor, a conexão parece estar "Verde/Online".
  • Do lado do carregador, a conexão também parece estar "Online".
  • Quando um usuário chega de madrugada, tenta iniciar uma carga, o servidor manda o comando via WebSocket... mas a mensagem bate no roteador da operadora e morre. O carro não carrega.

A Solução: O Jogo de Ping Pong

Para evitar que a conexão morra de velhice, você implementa o Ping Pong do WebSocket. Funciona assim:

  1. O seu servidor (ou o carregador) manda um pacote minúsculo chamado PING a cada "X" segundos (geralmente a cada 20 ou 30 segundos).
  2. Quem recebe o PING é obrigado pelo protocolo WebSocket a responder imediatamente com um PONG.
  3. Isso faz com que trafeguem bits na rede o tempo todo. Os roteadores e firewalls veem esse movimento e pensam: "Ah, estão usando essa conexão, vou mantê-la aberta".

O Segundo Benefício: Detecção de Falhas Reais

Além de manter a porta aberta, o Ping Pong serve como um "detector de batimento cardíaco". Se o seu servidor mandar um PING e não receber o PONG de volta em, digamos, 5 segundos, seu servidor sabe imediatamente: "A conexão caiu de verdade!". Aí o seu sistema pode marcar o carregador como "Offline" na hora e tentar reconectar, em vez de ficar esperando um comando de carga que nunca vai chegar.

?? Cuidado: Não confunda WebSocket Ping/Pong com OCPP Heartbeat!

Essa é a confusão mais comum no mercado de recarga:

  • WebSocket Ping/Pong: É um mecanismo de infraestrutura de rede. Serve para manter o "tubo" (a conexão TCP) aberto. Não carrega nenhuma informação útil sobre o carregador.
  • OCPP Heartbeat (Mensagem Heartbeat.conf): É uma mensagem de aplicação. É um texto em JSON que o carregador manda dizendo: "Olha, meu relógio interno marca 14:05:00". Serve apenas para o servidor saber se o relógio do carregador está des sincronizado.

Por que o Heartbeat do OCPP não resolve o problema da rede? Porque o Heartbeat do OCPP é uma mensagem de texto pesada. Se o "tubo" da rede já foi fechado pelo roteador, a mensagem do Heartbeat não consegue passar de jeito nenhum. O Ping do WebSocket é um pacote de controle ultra leve que funciona em um nível mais baixo da rede.

Como configurar na prática?

Normalmente, isso é configurado no servidor (CSMS). Você define um intervalo (ex: Idle Timeout = 30 segundos). Se o servidor ficar 30 segundos sem receber nenhuma mensagem OCPP real (como StatusNotification, MeterValues, etc.), ele dispara um Ping WebSocket.

Resumo: O Ping Pong é como se o servidor e o carregador ficassem se dizendo "Psui, tô aqui" a cada poucos segundos, só para a operadora de internet não derrubar a ligação deles.

 

 

Outra dica

 

O que o ping/pong faz

WebSockets podem parecer "sempre abertos", mas na prática existem firewalls, roteadores NAT, balanceadores de carga e proxies (como Nginx, Cloudflare, AWS ALB) que matam conexões inativas após um certo tempo — geralmente entre 30 segundos e alguns minutos. Quando isso acontece, nem o servidor nem o cliente percebem imediatamente, porque o TCP subjacente não sinaliza a queda de forma rápida.

O heartbeat (ping/pong) resolve isso enviando pequenas mensagens periódicas para manter a conexão "viva" e detectar desconexões rapidamente.

Duas formas de fazer

Planilhas

Abordagem Como funciona Quando usar
Frames nativos de ping/pong O protocolo WebSocket (RFC 6455) define frames específicos de ping e pong. A maioria das bibliotecas (Socket.IO, ws, SocketCluster, etc.) os usa internamente. Sempre que possível — é eficiente, leve e não polui sua lógica de mensagens.
Mensagens de aplicação Você define um tipo de mensagem customizado (ex: {"type":"ping"}) e responde com {"type":"pong"}. Quando você não tem controle sobre o servidor/cliente, ou quando está atrás de proxies que não repassam frames nativos corretamente.

O que cuidar na prática

  • Intervalo: geralmente entre 15–30 segundos é suficiente. Menos que isso gera tráfego desnecessário; mais que isso pode não segurar contra timeouts de proxies.

  • Timeout de resposta: não basta enviar ping — você precisa de um timeout. Se não receber pong em X segundos, considere a conexão morta e reconecte.

  • Não confie só no ping/pong: combine com um mecanismo de reconexão automática (exponential backoff) no cliente. Redes móveis, troca de Wi-Fi e modo avião são realidades.

  • Nginx/Cloudflare: lembre-se de que proxies intermediários também têm seus próprios timeouts. Configure proxy_read_timeout no Nginx, por exemplo, para ser maior que seu intervalo de ping.

Resumo

Sim, faça. Não é overengineering — é uma camada essencial de robustez. Use frames nativos quando possível, com intervalo de ~30s e timeout de resposta, e sempre tenha reconexão automática do lado do cliente.