[zeromq-dev] More robust version of syncpub/syncsub example

Greg Ward greg at gerg.ca
Wed Oct 9 18:43:22 CEST 2013

Hi all --

the ZeroMQ guide has an example, syncpub/syncsub, of a publisher and
subscribers synchronizing over REQ/REP sockets before starting
publishing in order not to lose messages. The example uses a sleep()
to paper over the delay between the subscriber connect()ing to the
publisher and actually being able to read messages from the publisher.

After explaining what the sleep() is for, there's a little teaser
sketching the "right way" to do it:

"""A more robust model could be:

  * Publisher opens PUB socket and starts sending "Hello" messages
    (not data).
  * Subscribers connect SUB socket and when they receive a Hello
    message they tell the publisher via a REQ/REP socket pair.
  * When the publisher has had all the necessary confirmations, it
    starts to send real data.

Since I'm still learning, I thought I'd try implementing this.
Unfortunately, it doesn't work, and I'm not sure if I messed up the
implementation, or the idea as presented is... umm... flawed.

The problem (I think) is that the publisher sends out a loooong stream
of "hello" messages while waiting for all subscribers to connect and
synchronize (i.e. send a message on their REQ socket). Subscribers
that synchronize early receive those "hello" messages while later
subscribers are still hooking up.

So subscribers that should meaningful "update" messages (the content
that the publisher sends after synchronization is complete) instead
get a long stream of meaningless "hello" messages.

I added a loop to the subscriber to consume those meaningless "hello"
messages before moving on to the main body. That helps some of the
time, but now there's a synchronization problem again: sometimes, the
publisher publishes all of its meaningful updates before some
subscriber consumes the meaningless "hello"s, and that subscriber
misses meaningful published messages. So I've just moved the
synchronization problem a few milliseconds later and the code is much
more complex: not a win.

You can see my code here:


Any tips? Has anyone successfully fleshed out the idea sketched in the

Thanks --


More information about the zeromq-dev mailing list