[zeromq-dev] Formally modelling the publish-subscribe pattern

[John Lång]

Oh, just one more point. Consider this statement in the documentation:

"When a |PUB| socket enters the mute state due to having reached the 
high water mark for a subscriber, then any messages that would be sent 
to the subscriber in question shall instead be dropped until the mute 
state ends."

When the mute state ends, which messages does the subscriber receive? 
Those that were in the queue when the mute state began or those that the 
publisher sent after the mute state ended? From Bill Torpey's answer, I 
got the impression that it's the messages sent after the ending of the 
mute state. This would be the preferable behaviour for my particular 
application. For my purposes, the latest messages are more valuable than 
the old ones. This question affects the way how I need to represent the 
connection in PROMELA.

Cheers,
John

On 16.10.2020 14.44, John Lång wrote:
>
> Hi Kevin,
>
> Thanks for the clarification!
>
> Best regards,
> John
>
> On 16.10.2020 14.39, Kevin Sapper wrote:
>>
>> Hi John,
>>
>>       * SHALL create a queue when initiating an outgoing connection
>>         to a subscriber, and SHALL maintain the queue whether or not
>>         the connection is established.
>>
>> This action is taken when a SUB socket binds to an address and the 
>> PUB socket connects to it.
>>
>>       * SHALL create a queue when a subscriber connects to it. If
>>         this subscriber disconnects, the PUB socket SHALL destroy its
>>         queue and SHALL discard any messages it contains.
>>
>> This action is taken when a PUB socket binds to an address and the 
>> SUB socket connects to it.
>>
>>     What is the difference between initiating an outgoing connection
>>     to a subscriber and a subscriber connecting to a publisher? In
>>     the C++ source code of my system, a publisher binds to a PUB
>>     socket and a subscriber connects to the address of a publisher. I
>>     guess this sounds more like the second point, but I'm not certain.
>>
>> Yes, the second point!
>>
>>     Did I understand correctly that this message queue between a
>>     publisher and a subscriber works FIFO? It says that for outgoing
>>     messages, "SHALL silently drop the message if the queue for a
>>     subscriber is full." Does this imply that those messages that fit
>>     in the queue are delivered in the order they were sent in? I take
>>     it that the queue being full means that the high water mark has
>>     been exceeded.
>>
>> When a PUB socket enters the mute state due to having reached the 
>> high water mark for a subscriber, then any messages that would be 
>> sent to the subscriber in question shall instead be dropped until the 
>> mute state ends. The send function does never block for this socket 
>> type.
>>
>>     What is a binary comparison? Is it the same as bitwise
>>     comparison? To me, "binary comparison" sounds like just comparing
>>     two things with each other.
>>
>> It means that the byte content of the first frame is compared against 
>> the bytes of a subscription. Hence a subscription can use any binary 
>> prefix not just characters.
>>
>> //Kevin
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20201017/68fd6ffe/attachment.htm>