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

Brian Granger ellisonbg at gmail.com
Tue Sep 6 20:40:27 CEST 2011


On Tue, Sep 6, 2011 at 10:12 AM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> 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

Can the filter be sent automatically upon connection?

>> 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
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com



More information about the zeromq-dev mailing list