[zeromq-dev] first message never received when SUB binds (0MQ 3)

MinRK benjaminrk at gmail.com
Tue Sep 6 19:12:53 CEST 2011


On Tue, Sep 6, 2011 at 01:02, Martin Sustrik <sustrik at 250bpm.com> wrote:

> On 09/04/2011 08:47 PM, MinRK wrote:
>
>> When binding with SUB, and connecting with PUB, it seems impossible to
>> receive the first message.
>>
>
> This is caused by introduction of subscription forwarding. The scenario
> goes like this:
>
> 1. subscriber connects to the publisher
> 2. publisher starts sending messages
> 3. there's no filter so far, so the messages get dropped
> 4. subscriber subscribes
> 5. from this point on the messages are delivered
>
> The real problem behind the issue is mixing the "message distribution" and
> "message aggregation" patterns in what's PUB/SUB pattern today. In the
> former the above behaviour is expected (you get only the messages after
> you've asked for them, old messages will never be delivered). In the latter
> there's a reliability requirement, but there's no need for subscriptions,
> which would make the problem disappear.
>
> As a quick hack, the problem can be solved by introducing a new "start"
> command to be sent from subscriber to the publisher:
>
> 1. subscriber connects to the publisher
> 2. it sends all the active subscriptions to the publisher
> 3. it sends the "start" command to the publisher
> 4. publisher start sending messages to the consumer


> Thoughts?
>

What concerns me most immediately is that the behavior is not agnostic of
the connection direction, which I thought was part of 0MQ's design.

Case A. (PUB-binding)

sub.connect(iface)
pub.bind(iface)
sub.subscribe = b''
time.sleep(.1) # give subscribe a chance to propagate
pub.send('hi')
print sub.recv()

recv gets 'hi'

Case B. (SUB-binding)

sub.connect(iface)
pub.bind(iface)
sub.subscribe = b''
time.sleep(.1) # give subscribe a chance to propagate
pub.send('hi')
print sub.recv()

recv will *not* get 'hi'.

It also seems like a problem that this means that you cannot use poll on a
sub socket that binds to wait for the first available message, because it
will never come until after you have actually called recv once.

The PUB-binding/SUB-connecting behavior seems perfectly reasonable to me.
 I'm fine with losing messages that were sent before the connection was
established, but it doesn't make sense that even after sockets are connected
and a subscription is established, all messages prior to the first recv are
dropped if and only if the sub socket is the listener.

-MinRK

Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110906/6ad3be0b/attachment.htm>


More information about the zeromq-dev mailing list