[zeromq-dev] Failing to synchronize 0mq sockets

[Michel Pelletier]

> I've verified that using tcp req/rep synchronization works with my
> example. I agree that inproc sync makes no point if sockets are to
> talk across processes. But the example is about synchronization, it's
> just a toy to understand what can I build on.
>
> So, you say there is no guarantee that connections across different
> transports can be synced.

Certainly you *can* synchronize across transports.  What you're using
is a pattern that says: because I synced channel B after channel A was
created, channel A should be connected up by the time I use it.  But
there's no guarantee either end of A is actually up, especially if
channel B uses a much faster to connect transport, it beats channel A
to the connected state.  You haven't actually synced the two streams,
you're just relying on their order of connection, which is most cases,
like when you use the same transport, works perfectly fine.

A more robust pattern would be two-phase, 1) hey there producer, my id
is X, i called connect, start publishing my id and i'll let you know
when I see it, 2) ok I see my id now, I'm synced with you, you can
stop publishing my id and start publishing real data once you hear
from everyone else you're expecting, and publish a special signal for
us to start paying attention.

Also, see the "Clone Pattern" in the guide for an example of advanced syncing.

If your using the same transport and both channels are connecting to
the same peer, which is the predominant case, then the simpler pattern
is better.

> Is there any guarantee that syncing solely
> on tcp *is* reliable?

Your confusing the notion of "syncing" with some feature zmq provides.
 syncing is a pattern, and there are many ways to do it depending on
many different application specific details.

Zeromq messaging is as reliable as you make it.  It's powerful and
simple *because* it doesn't do it for you, or pollute its API with the
many different needs and options that other people consider important
to their notion of "reliable".

As for clarifying the documentation I'd suggest going ahead and making
the change and submitting a pull request.

-Michel