[zeromq-dev] Requesting input on migrating existing code to 0MQ..

Rick Flower nrf at ca-flower.com
Tue Jan 24 00:25:37 CET 2012

Hi all.. So I've got some 0MQ code working just fine for a logging 
daemon in
a larger project.. All is good there.. However, I've got some other 
in the same codebase currently communicating via sockets.  I'll try to
layout the topology of the threads as they are today -- I'm looking for
inputs on how to use 0MQ in an efficient/fast manner as a replacement 
these sockets.  Ideally, I'd like to use inproc as the backend if at 
possible as speed is utmost here.  In the layout below, the Server and
all helper threads are in a single process space but the Socket clients
are separate processes so inproc can't work there.  More description
below.. Hopefully my diagram won't get munged..

                       | Server |
                       |        |
     |           |         |          |           |
....|..... .....|.... ....|..... ....|.....   ...|....
| Helper | | Helper | | Helper | | Helper | | Helper |
| Thread | | Thread | | Thread | | Thread | | Thread |
`........| `........| `........| `........| `........|
     |                     |                     |
     | Bi-directional      |                     |
  ___|____Flow here..   ___|____               __|_____
| Socket |            | Socket |             | Socket |
| Client |            | Client |             | Client |
'--------'            '--------'             '--------'

Each helper thread receives a single packet at a time from the server
and may or may not respond back with a response.  Some of the
requests are to start or stop or packets indicating a period in time.
IF all of the helper threads replied I'd probably use one of the
request/reply backends but since some do not reply, I'm not sure what
the best approach might be.

To make things more interesting, some of these 10 helper threads turn
around and create another server sort of setup and talk to yet another
group of clients over sockets -- these clients are in a separate 
so inproc is out of the question -- for now I don't think I can even 
0MQ for this part since I can't migrate these other clients over at 
point in time to use a different backend (e.g. 0MQ).

More information about the zeromq-dev mailing list