да, авто-ответ понгом должен, а вот пинги - не должен (на усмотрение). АФАИК проще сделать - нету данных по tcp столько-то времени - закрываем. Кроме того обычно клиент "более заинтересован" в поддержании коннекшена, поэтому он и пингует. Хотя если вывернутая наизнанку схема, т.е. клиент "подписывается" на события от сервера и просто их получает, то и в таком случае клиент(!) должен пинговать сервер о том что он живой, а не сервер.

Как пример я делал как-то для камеры по GigE протоколу, и там фреймы по UDP от камеры приходили. И там да, клиент должен камеру пинговать. По смыслу такой подход и логично для сервера : чем ставить ещё N таймеров на N клиентов дешевле, обычно, каждому клиенту поставить у себя таймер.

Так что с цитатой с SO не согласен.

цитата на СО была от одного из авторов собственной имплементации вебсокет протокола... да, я сходу не вижу, почему бы серверу тоже не отвечать понгом на пинг, но практика вот такая, как я её помню и как помнит ещё один автор...

серверу на самом деле логично экономить ресурсы и дохлых клиентов отсекать быстрее

за каждым вебсокетом, обычно сессия с не всегда малыми выделенными под неё ресурсами

возможно там несколько draft'ов websocket'а  было, и возможно в одном из них так и писалось. А иммено из рфц это удалили, т.к. это не коммон кейс. Афаик пинги вообще не используются по-дефолту

ну если у тебя короткоживущие вебсокеты и тебе хватает 60 сек, то да, пинги можно не использовать...

ещё одна цитата:

“ping/pong frames” are used to check the connection, sent from the server, the browser responds to these automatically.

а для долгожителей - это я бы сказал protocol/application-specific :)

отсюда: https://javascript.info/websocket

конечно, тоже так себе источник...

А в браузере есть вообще возможность послать пинг программно?

короче, я не парился:

$ws->{_heartbeat} = AnyEvent->timer(
  interval => $config{heartbeat_interval},
  cb       => sub {
    if ($ws->{_handle} && !$ws->is_defunct) {
      $ws->{_handle}->push_write(
        Protocol::WebSocket::Frame->new(
          type    => 'ping',
          buffer  => 'ping',
          version => $ws->{_handshake}->version,
        )->to_bytes);
    }
  }
);

нету

тогда понятно почему они javascript.info так пишет )

$ws->{_heartbeat} = AnyEvent->timer(
  interval => $config{heartbeat_interval},
  cb       => sub {
    if ($ws->{_handle} && !$ws->is_defunct) {
      $ws->{_handle}->push_write(
        Protocol::WebSocket::Frame->new(
          type    => 'ping',
          buffer  => 'ping',
          version => $ws->{_handshake}->version,
        )->to_bytes);
    }
  }
);

> A Pong frame sent in response to a Ping frame must have identical
  "Application data" as found in the message body of the Ping frame
  being replied to.

а это у тебя где? (из рфц)

$ws->{_heartbeat} = AnyEvent->timer(
  interval => $config{heartbeat_interval},
  cb       => sub {
    if ($ws->{_handle} && !$ws->is_defunct) {
      $ws->{_handle}->push_write(
        Protocol::WebSocket::Frame->new(
          type    => 'ping',
          buffer  => 'ping',
          version => $ws->{_handshake}->version,
        )->to_bytes);
    }
  }
);

и там же на сервере on_read — телеграм глючит не даёт скопировать кусок кода где я проверял входищий фрейм на пинг, отправляя сразу на него понг, если вдруг браузер мне его слать будет.

buffer  => 'ping' — я сам формирую "Application data"

👍

Мы кстати наш Protocol::WebSocket::Fast не будем адаптировать под АПИ Protocol::WebSocket . Честно пытались, но оч. сильно потроха разнятся, и поэтому без потерь производительности на нашем дефолтном апи не получится, а это уже оказалось неприемлимой ценой. На сколько я помню, Protocol::WebSocket позволяет создавать "фреймы в вакууме", а потом их довешивать нужными свойствами, и когда фрейм заталкивается дальше, ещё недостающие куски добавляются к нему. Это "unsafe API", у нас же можно сказать оно "safe", т.е. всегда валидные объекты/данные получаются.

мнэээ, фреймы — они просто фреймы. что им ещё надо то?