How to avoid many connected DEALER-s to crash a ZeroMQ ROUTER?

Question

I have a ROUTER-socket in an application that multiple DEALER-sockets, in different applications, connect to. I'd like the ROUTER to be as robust as possible.

Here is a specific scenario I'd like to handle well on the ROUTER :

1. 1000-s of DEALER-s connect to the ROUTER
2. Each DEALER sends a request to the ROUTER than will make the ROUTER send a large response back to the DEALER
3. Instead of reading the response, DEALER-s immediately repeat step two

A behavior I see on the ROUTER : it creates a ton of very large ZeroMQ messages for the responses, then does a zmq send back to the DEALER. ZeroMQ becomes responsible for deallocating the messages when they are actually sent. Since the DEALER-s never call recv(), ZeroMQ holds the message forever and the memory is slowly 'leaked' until the O/S kills the process when it runs out of memory.

Some options I've used that help :

ZMQ_SNDHWM : limits us to only holding N-messages in our outgoing queue to each DEALER, though not ideal because a ROUTER will drop outgoing messages when the queue is full

ZMQ_SNDTIMEO : ZeroMQ will discard message after N-milliseconds, without a successful send

With these options specified it's still possible to crash the ROUTER if 1000s of DEALER connections are opened, as the High Water Mark is applied on a per client basis.

Are there any other options I could use to protect against client requests crashing me?

Answer 1

Q : "Are there any other options I could use to protect against client requests crashing me?"

While the setup goes beyond my imagination, why to move zillions of bytes not to ever .recv() them, let me propose you one trick to throttle the memory-allocations to a working minimum :

We may use the .setsockopt( zmq.CONFLATE )-trick (using a Python dialect), not to buffer anything else more but a one, the most recent, incoming message.