I'm experiencing different behaviors with my websocket ping/pong between my development environement and my real deployment.
When I started this project, I took some time to test the websocket ping/pong feature to delegate the keepalive/connection check to the websocket stack. My primary goal is to know if the remote client is disconnected ASAP. So I added a server side websocket keepalive (let's say 20sec).
On my dev machine, I had something like:
[device] <==> [switch] <==> [asp.net core app(kestrel)]
In that case everything is fine: when I disconnect the websocket client device, after the 20sec (ok, a bit more sometimes) I get a notification that the connection has been lost.
On my staging environment, it's a little bit more complicated:
[device] <==> [switch] <==> [internet] <==> [IIS reverse proxy] <==> [asp.net core app(kestrel)]
In that case it's just weird: when I disconnect the websocket client device, I still get PONGs from the IIS...
I did captures with wireshark to confirm that. So my question is/are: who is sending PONGs on the behalf of the client? Is it the reverse proxy (IIS in my case)? Is that normal? How can avoid that? Is it something in the IIS configuration?
Edit: I just tested it with nginx instead of IIS on a linux server, and I get the same behavior. So I must have missed something!!
It seems that the we can't rely on websocket ping/pong to garantee a correct line check, as they (ping) may not be sent down to client. Depending to the infrastructure, they may be intercepted by a proxy or other link(s) in the chain.
Ping/pong becomes unrelevant for connection checking in such a configuration.
It's just disapointing that the RFC is not more constraining about that!
Furthermore, there is some indication in asp.net core's websocket documentation about how to handle a proper connection check.