[zeromq-dev] Handling high socket or connection counts

Olaf Mandel o.mandel at menlosystems.com
Thu Feb 6 13:38:48 CET 2014


I was wondering if there is any pattern to handle many open connections
to a single socket or many open sockets in one executable: I
consistently run into a "Too many open files" problem.

I get this error either when I run into the ZMQ_MAX_SOCKETS limit or
into the operation system resource limit (ulimit -n) on Linux. On
Windows, I can be lucky not to cause a Bluescreen!

I therefore assume this is a general design question, not a specific
problem with 0MQ.

Background: I was considering a program design consisting of many
independent parts that run in many different threads and must exchange
data. I was planning to expose the readable/manipulable properties via
0MQ REQ-REP and PUB-SUB sockets, via the inproc or tcp transport. But in
the naive approach the number of possible sockets and connections in one
executable is too low:

* one file descriptor per socket
* for tcp, one file descriptor per connection

The number needed in my case ranges from a few hundred sockets to many
thousands (configuration dependent) and I don't even know how many
connections I might end up having...

My REQ-REP test-case, stripped of all checks:

#include <vector>
#include <zmq.h>
int main() {
    void* context = zmq_ctx_new();
    void* server = zmq_socket(context, ZMQ_REP);
    zmq_bind(server, "tcp://");
    std::vector<void*> clients;
    for(unsigned int i=0; i<2048; ++i) {
        clients.push_back(zmq_socket(context, ZMQ_REQ));
        zmq_connect(clients.back(), "tcp://");
    return 0;

The full test case is available under http://pastebin.com/hN4PYkX3 .

Any insight is much appreciated!

Thank you,
Olaf Mandel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140206/55ead189/attachment.sig>

More information about the zeromq-dev mailing list