[zeromq-dev] threaded client-server?

[Jan Müller]

Hi all,

I seem to have a problem getting one of our software to use zmq...

I have multiple clients which connect to a server and request some data. 
The server processes the requests and eventually sends back an 
acknowledge or some piece of data.

What we did so far: for each new connecting client a thread was started 
which processed the request and sent the reply back (through the same 
TCP/IP socket).

One problem is, from time to time it might take a while before the 
server can send back the data because he has to wait for an other (slow) 
process to make this data available. In our current implementation the 
client and his communication link just blocks until the requested data 
got available.


I saw this example: http://www.zeromq.org/blog:multithreaded-server

but I'm not sure how I can get this to scale up well with zmq and our 
application. I can create a number of threads at startup but what can I 
do when all threads happen to be in a blocked state and a new client 
(with a non blocking request) attempts to connect (and wants to get his 
answer back)?

If I want to naively use the REQ/REP pattern and create a thread after 
recv() returns, how can I map the 'answer' of the thread (which might of 
course arrive in any order) to the respective send() ?

One way could be to have some kind of resource manager and check when 
the number of unblocked threads gets too low and then start more 
threads. But this seems a bit too muck like a hack around for a standard 
problem.

And I'm sure there must be an elegant way/pattern to design this problem 
with zmq!? Do I miss something? Does anyone has an idea?


Thanks for any hints..

Regards,
Jan