[zeromq-dev] equivalent of accept
sustrik at 250bpm.com
Wed Apr 21 13:06:01 CEST 2010
> 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
> 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.
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.
More information about the zeromq-dev