[zeromq-dev] Pattern for two clients and one server

Bob Eby ebyrob at gmail.com
Thu Jan 25 05:45:43 CET 2018


I recently wrote a client server application that seems a bit similar to yours.

> How should I pair the request/reply calls?

Initially I used single threaded REQ / REP on client and server to test.

In order to avoid the server blocking, I created multiple worker
threads on server each connected back to a ROUTER / DEALER
configuration as in Figure 16 of http://zguide.zeromq.org/page:all

It only took me about 2 days to go from a nearly complete one client
to one server application to fully functional multiple client / many
threaded server.  (I even built the server so if I ran the .exe twice,
the second instance would fire up more threads in a separate process!
All done in the 2 days.)

I did have to be sure that my server code was thread-safe, but given I
was already using an SQL database for most of the heavy lifting this
was very easy.

> I need the communication to be asynchronous, without doing busy waiting.

I'm not entirely sure what you mean here.  It's up to the client to be
sure that it is not waiting around for a server on slow operations.
Also, it is important to note that even for multi-part messages, all
of a full message must be stored up before it can be sent and
processed by the other end.  So breaking apart long slow operations
into more smaller ones is very important.

> I went through the ZMQ guide but still I am not pretty sure whether this is
> the right approach.

I would say start with something very simple and plan to reconfigure
the design later.  If you're not sure that will work, write a hello
client server with REQ / REP and get it fully working with 1 server 1
client, then pick another pattern from the guide and try switching to
it to see how much effort it will (or won't) be.

The biggest limitation of REQ / REP will be that every single
operation will have to start with a client asking for something and
then end with a timeout / error or a valid response from the server.
It's a little reminiscent of "stateless" HTTP...

Good luck,
Robert Eby



More information about the zeromq-dev mailing list