40

Socket.io allows you to use heartbeats to "check the health of Socket.IO connections." What exactly are heartbeats and why should or shouldn't I use them?

jhchen
  • 14,355
  • 14
  • 63
  • 91

1 Answers1

59

A heartbeat is a small message sent from a client to a server (or from a server to a client and back to the server) at periodic intervals to confirm that the client is still around and active.

For example, if you have a Node.js app serving a chat room, and a user doesn't say anything for many minutes, there's no way to tell if they're really still connected. By sending a hearbeat at a predetermined interval (say, every 15 seconds), the client informs the server that it's still there. If it's been e.g. 20 seconds since the server's gotten a heartbeat from a client, it's likely been disconnected.

This is necessary because you cannot be guaranteed a clean connection termination over TCP--if a client crashes, or something else happens, you won't receive the termination packets from the client, and the server won't know that the client has disconnected. Furthermore, Socket.IO supports various other mechanisms (other than TCP sockets) to transfer data, and in these cases the client won't (or can't) send a termination message to the server.

By default, a Socket.IO client will send a heartbeat to the server every 15 seconds (heartbeat interval), and if the server hasn't heard from the client in 20 seconds (heartbeat timeout) it will consider the client disconnected.

I can't think of many average use cases where you probably wouldn't want to use heartbeats.

sheac
  • 592
  • 5
  • 12
Michelle Tilley
  • 157,729
  • 40
  • 374
  • 311
  • 1
    Might be worth clarifying why they are needed? Why would a server not detect a client disconnecting via an `onclose` event/callback? – leggetter Aug 16 '11 at 12:06
  • 2
    It is worth noting a disadvantage is of a small delta between the interval and the heartbeat is that under load, the server may not respond to the heartbeat packet in time and assume the connection has died. – jhchen Aug 26 '11 at 07:58
  • 1
    @jhchen what is the probability of this happening? is there a way to extend the test time after the heartbeat? when you put it that way, 5s doesn't seem like a lot of time on a laggy connection. – tester Oct 26 '12 at 02:25
  • 1
    @tester sure the two variables to control this are 'heartbeat timeout' and 'heartbeat interval' so either lower the interval or raise the timeout – jhchen Oct 26 '12 at 22:07
  • Can you clarify that a "<2: :" heartbeat is client-server and ">2: :" is server-client? – SleepNot Feb 04 '14 at 06:14
  • +1 nicely portrayed. What do you think the best value for `heartbeat interval and timeout`? By default it is 60 seconds in latest version and what is your views on it by reducing? – Praveen Mar 06 '14 at 13:03
  • @Praveen It depends pretty heavily on your application. E.g. a chat application might be fine with timing out after a minute, but an online game might need a much smaller heartbeat. – Michelle Tilley Mar 07 '14 at 00:34
  • 7
    In mobile apps using a wireless network connection the heartbeat interval shouldn't be too short otherwise your battery will be drained fast (e.g. the Node.js default server-to-client heartbeat interval of ~25 seconds is not very good). See [here](http://developer.android.com/training/efficient-downloads/efficient-network-access.html#RadioStateMachine) for more details. – Piovezan May 16 '14 at 18:49