support set ping handler and pong handler

[qcha0]

first of all, thanks this good project, we are preparing a tool based on this project.

Sometimes i need do something while receive ping or pong message.
So I added this feature, is it alright

[nhooyr]

Thanks for implementing this @qcha0

Related issue is #246

What's your usecase out of curiosity for needing to instrument ping/pongs?

[qcha0]

just like i want to count the number of ping，or set close the connection if there is no ping message whithin two cycle.

[schmidtw]

@nhooyr I need pings/pongs at the application layer for an app we're building a replacement for. I know work is being done on the dev branch, but adding this one feature to a trusted, working code base prevents me from needing to fork the repo for just this one feature we're trying to ship in a week.

Could this PR be merged?

[nhooyr]

@schmidtw Sorry I won't get to this for a few weeks still. There's another change I wanted to make to let people handle close frames too. What feature are you trying to ship that relies on this?

[schmidtw]

I have a protocol that depends on sending & receiving websocket pings and pongs. Each side of the connection expect a ping/pong within an interval & if either doesn't get the ping or pong from the other side the connection is determined to be broken & application logic notes the reason, closes down immediately & the client side will reconnect. The pings and pongs are reported as metrics as well. This is the project: https://xmidt.io/

Since this is weeks out & behind other PRs and the dev branch, it makes sense for me to copy the code, apply this patch & use it locally in my project. When these features are available upstream I can delete the code from the project & move back to this code. I'm not interested in staying on a forked copy for any longer than is needed.

[nhooyr]

Makes sense. Yes, please fork the code for now.

[igolaizola]

We have a similar use case where we need to send a Ping if the device hasn’t sent one within a specified time frame before closing the connection for inactivity, and this PR looks like it could address our requirements perfectly. Could you please share the current status?

We’re planning to migrate from gorilla/websocket to this library, but this feature is the missing piece that’s currently blocking us from completing the migration. We truly appreciate all the effort that’s gone into this project and would prefer to avoid maintaining a fork, as it can be challenging and time-consuming to manage.

Thanks again for all the great work on this library! 🙌

[igolaizola]

Since @coder now maintains this project, I'm pinging @mafredri to see if they can take a look. Thanks!

[mafredri]

@igolaizola for status, I can share that nobody is currently working on this and this PR can't be merged as-is. We can look into getting this functionality merged, however, I see at least a few issues we'd want to address:

1. Assigning the handler is racy, ideally this would be done as an option when creating the websocket, or we need to protect the handlers via mutex.
2. It's not possible to control pongs, they are sent unconditionally and without delay
3. The custom ping handler can return an error, but it's unclear why or what should happen if it does

Questions that spring to mind are:

a. Do users need to modify handlers at runtime?
b. Do users need more control or are they satisfied with observability?

From discussion here and in #246, it seems like observability is the main key which answers 2 and b.

I don't see a use-case for 1 and a, though, and if it indeed is a use-case, perhaps they'd need the ability to assign multiple handlers (register/deregister style).

I'd be happy if people chimed in here as it'll help lock-down the feature set, cheers.

---

Edit: I could also see the ping handler be written so that the return signature allows the library to know whether or not the ping was handled. If it wasn't handled, the library sends pong, if it was, the library assumes you did, one way or another.

Also, more case(s):

• What should happen if we receive a pong but there's no active ping
  • Perhaps this could be useful to detect e.g. servers/clients that have malfunctioned or network connections that are unstable

[igolaizola]

@mafredri Thank you for your quick reply!
I agree that this PR has some issues in its current state.

a. Do users need to modify handlers at runtime?

I believe that setting handlers during creation is sufficiently flexible. Complex logic can always be encapsulated within a custom handler, and I can't think of a use case where this wouldn’t be adequate.

b. Do users need more control or are they satisfied with observability?

In our scenario, battery-powered devices act as clients, and our cloud serves as the server. This setup requires that pings are not sent automatically because the devices are responsible for initiating them. Since we’re dealing with battery-constrained devices, optimizing resource usage is critical.
Additionally, we need the ability to trigger a ping to the device at specific moments. If the server doesn’t receive a ping from the device within X seconds, it sends a ping to determine whether the connection is still active. This is necessary because packets can sometimes be lost, meaning a ping from the device might not reach the server.

Would you be open to reviewing a new PR that offers more flexible handling of Ping/Pong messages? The premise would be that these handlers are configured only during startup, and ideally the default functionality remains unchanged to avoid breaking existing implementations.

[mafredri]

That's an interesting use-case @igolaizola, thanks for sharing it.

Would you be open to reviewing a new PR that offers more flexible handling of Ping/Pong messages? The premise would be that these handlers are configured only during startup, and ideally the default functionality remains unchanged to avoid breaking existing implementations.

Sounds great, I'm happy to review!

[igolaizola]

@mafredri I have created a new PR here: #509