[zeromq-dev] Failing to synchronize 0mq sockets

[Daniele Varrazzo]

On Tue, Apr 3, 2012 at 3:34 PM, Michel Pelletier
<pelletier.michel at gmail.com> wrote:
> On Tue, Apr 3, 2012 at 4:16 AM, Daniele Varrazzo
> <daniele.varrazzo at gmail.com> wrote:
>> On Tue, Apr 3, 2012 at 7:36 AM, Michel Pelletier
>> <pelletier.michel at gmail.com> wrote:
>>> Your example works fine for me if you change the tcp PUB endpoint
>>> transport to inproc.
>>
>> This means that it doesn't work, does it? I mean, my program
>> establishes an unequivocal temporal sequence, that somehow is not
>> respected. I wonder why, as it makes syncing impossible even with the
>> best intentions. If it works using inproc and not other transports I
>> assume it only does by implementation accident.
>
> It works, you just have to compare apples to apples.  A tcp connect
> can take several milliseconds, an inproc connect is essentially a
> no-op.  Your thread sync is not the performance critical part of your
> program, why not just switch it to tcp, or switch the publisher to
> inproc?  What's the point of publishing externally but synchronizing
> internally?  If you use the same transports for pub and sync, and more
> closely follow the synchronized subscriber pattern in the gude (using
> REQ/REP, not PAIR) everything will work fine, and if you use a process
> approach instead of threads you can scale beyond a core or two.

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. Is there any guarantee that syncing solely
on tcp *is* reliable? If zmq_connect can actually return before
connecting, is the program now correct? (I've updated the script into
<https://gist.github.com/2286899>) Or does it just work because of
delays and still subject to chances?

>> More or less this is the same conclusion I've reached: that connect()
>> doesn't block and returns before really establishing a connection.
>
> Yep, it's asynchronous, that's a feature.  Since you're using
> eventlet, I imagine you can understand how that's a benefit to you in
> the sense that it doesn't block your eventlet io loop.

Well, I would have definitely preferred to have my thread (native or
green) blocked until connection established: it would have made
verifying the program correctness much easier. But I'm here just to
learn a new paradigm, so I don't mind surprises here and there :)

>> But
>> in this case how can you write a correct program using zmq? Is this a
>> design decision or an unexpected behaviour?
>
> It's exactly expected, your problem is synchronizing one transport
> with another.  Unify them an you will have no problems.

This is was I was expecting across transports too, but now that I know
it I'll stick to a single transport for synchronization.

However, is it documented that syncing connections on the same
transport does work? Because this now contradicts what the zmq_connect
note says. Could it ever be that zmq will establish the connection on
the req/rep pair while still delaying the pub/sub connection?

Thank you,

-- Daniele