Nothing in the path fires an event, and that is the whole difficulty. The post's account of the lift is that no clean TCP close handshake occurs and packets simply stop arriving [3], while the server goes on believing the client is connected [5]. A close handler needs a close frame to run. Absent one, liveness is something you have to go and measure [6]. The premise carried over from Part 1, that disconnection is normal and recovery is the feature, gets harder once you accept the disconnect may arrive as silence [1].
Sort the three keep-alive layers the post lists by who can observe them [8]. TCP keepalive is an operating system probe. Protocol PING and PONG are control frames the browser answers by itself, and browser JavaScript is never handed the conversation [12]. Of the three, one is visible to code running in a page [1]. That is why the application-level `{"type":"ping"}` exists: it is the only heartbeat a component in the page can time [14]. It costs a normal application frame per beat instead of a control frame [15], and it is the only route by which the client learns whether the server answered and how long it took, before deciding to show a disconnected state and reconnect [13].
The post's failure condition is that nothing comes back within the expected time [9]. Expected time is where all the engineering lives, and the post does not put a number on it. A heartbeat is answering two questions at once, per the author: is the peer still alive, and will an intermediate proxy stop treating this connection as idle [7]. Those questions have different owners. The idle timeout belongs to whatever load balancer or ingress sits in front of you, and you probably did not pick it. The tolerance for a zombie belongs to your product: how long a presence list is allowed to lie, and how many file descriptors you can afford pinned to users who are gone [4]. Copy an interval out of somebody else's write-up and you are importing their proxy configuration and their patience. Both would have to match yours for the number to transfer.
The Node snippet is honest about its own scope. `ws.ping()` sends the frame, and the pong handler sets `ws.isAlive = true` [11]. There is no timer in it. The code that decides how many missed pongs are fatal, clears the flag, and terminates the socket is left for you, and that is the part that either reclaims the descriptor or does not.
In my context both directions run, as separate mechanisms with separate jobs. Server to client, protocol pings, because they are built into the protocol rather than layered on top of application data [10], and their only job is reclaiming sockets and descriptors [4]. Client to server, application pings, because the interface needs an answer it can see [13]. Presence is the one feature that will report, with total confidence, a user who is standing in a lift.
