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

[Rick Flower]

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 
areas
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 
for
these sockets.  Ideally, I'd like to use inproc as the backend if at 
all
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 
process
so inproc is out of the question -- for now I don't think I can even 
use
0MQ for this part since I can't migrate these other clients over at 
this
point in time to use a different backend (e.g. 0MQ).