I have a Dealer socket in client side, who is connected to Router socket in server side.
I often see Heartbeating mechanism : the server regularly send message to the client in order that client knows if he is correctly connect to the server, so the client can reconnect if he doesn't received message for some times.
For example the Paranoid Pirate pattern here : http://zguide.zeromq.org/page:chapter4
But after some tests : if the client loose the connection to the server for a moment and find it again, the client is automatically reconnected to the server socket (he receive sended message...).
I wonder in which case Heartbeating is necessary ?
Heartbeating isn't necessary to keep the connection alive (there is a ZMQ_TCP_KEEPALIVE socket option for TCP sockets). Instead, heartbeating is required for both sides to know that the other side is still active. If either side does detect that the other is inactive, it can take alternative action.
Inactivity might be because a process has died, it's deadlocked, it's doing too much work between network activity, or network failure, etc. From the other sides point of view, all these scenarios are indistinguishable without more information.
In networking, making a design work is the easy part. The overwhelmingly hard part is dealing with failure. You have to consider as many possible failure modes as possible and deal with them in the design protocols. Heartbeating is often a helpful part in those protocols. They are far more useful than trying to work out if a socket is still up by use of monitor events, say.
Having said that, if your application doesn't need any particular level of reliability; perhaps you can just power cycle equipment when a failure happens. Then you probably don't need to worry about heartbeating. After all, there are plenty of patterns in the guide that don't use it. It's horses for courses.
来源：https://stackoverflow.com/questions/29842354/zmq-pattern-dealer-router-heartbeating