How to drop inactive/disconnected peers in ZMQ

Question

I have a client/server setup in which clients send a single request message to the server and gets a bunch of data messages back. The server is implemented using a ROUTER socket and the clients using a DEALER. The communication is asynchronous. The clients are typically iPads/iPhones and they connect over wifi so the connection is not 100% reliable.

The issue I’m concern about is if the client connects to the server and sends a request for data but before the response messages are delivered back the communication goes down (e.g. out of wifi coverage).

In this case the messages will be queued up on the server side waiting for the client to reconnect. That is fine for a short time but eventually I would like to drop the messages and the connection to release resources.

By checking activity/timeouts it would be possible in the server and the client applications to identify that the connection is gone. The client can shutdown the socket and in this way free resources but how can it be done in the server?

Answer 1

Per the ZMQ FAQ:

How can I flush all messages that are in the ZeroMQ socket queue?

There is no explicit command for flushing a specific message or all messages from the message queue. You may set ZMQ_LINGER to 0 and close the socket to discard any unsent messages.

Per this mailing list discussion from 2013:

There is no option to drop old messages [from an outgoing message queue].

Your best bet is to implement heartbeating and, when one client stops responding without explicitly disconnecting, restart your ROUTER socket. Messy, I know, this is really something that should have a companion option to HWM. Pieter Hintjens is clearly on board (he created ZMQ) - but that was from 2011, so it looks like nothing ever came of it.

Answer 2

This is a bit late but setting tcp keepalive to a reasonable value will cause dead sockets to close after the timeouts have expired. Heartbeating is necessary for either side to determine the other side is still responding. The only thing I'm not sure about is how to go about heartbeating many thousands of clients without spending all available cpu just on dealing with the heartbeats.