[zeromq-dev] equivalent of accept

Martin Sustrik sustrik at 250bpm.com
Wed Apr 21 13:06:01 CEST 2010


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



More information about the zeromq-dev mailing list