ZeroMQ

Shrugging It Off

The most common approach is to do no heartbeating at all and hope for the best. Many, if not most, ØMQ applications do this. ØMQ encourages this by hiding peers in many cases. What problems does this approach cause?

• When we use a ROUTER socket in an application that tracks peers, as peers disconnect and reconnect, the application will leak memory (resources that the application holds for each peer) and get slower and slower.

• When we use SUB- or DEALER-based data recipients, we can’t tell the difference between good silence (there’s no data) and bad silence (the other end has died). When a recipient knows the other side has died, it can for example switch over to a backup route.

• If we use a TCP connection that stays silent for a long while, it will, in some networks, just die. Sending something (technically, a “keep alive” more than a heartbeat) will keep the network alive.