Brian, > On Tue, Apr 20, 2010 at 06:45:16PM +0200, Martin Sustrik wrote: >> 0MQ does this for you. Actual networking stuff is done in I/O >> thread(s). Your application thread is free to do the actual >> processing. > > Could you also clarify for my benefit: if you have (say) five worker threads > which want to handle incoming REQs from clients, should the five threads all > call zmq_recv on the same socket, or should the five threads each create > their own zmq_socket bound to the same proto/port? > > In the first case, it's not clear to me how the zmq_send would route the > response back to the correct client - is it implied by which thread is > calling zmq_send? > > In the second case, a normal socket API would give EADDRINUSE.
Yes. The right way to do this is: Each clinet has a REQ socket to send requests to and receive replies from. In the server's main thread create a TCP XREP socket to handle the clients. Create an inproc XREQ socket to speak to worker threads. Then start the worker threads and run the queue device: zmq_device (ZMQ_QUEUE, xrep_socket, xreq_socket) The worker threads shoud create an inproc REP socket and connect to the inproc XREQ socket created by the main thread. However: 1. The XREP/XREQ sockets are broken in a current trunk. I need one full day with no distractions to focus on it :( 2. The functionality is experimental, meaning that the API may change in future versions of 0MQ. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
