[zeromq-dev] Formally modelling the publish-subscribe pattern
Kevin Sapper
kevinsapper88 at gmail.com
Sat Oct 17 17:04:56 CEST 2020
Hi John,
> 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.
>
The first case, those that were in the queue when the mute state began.
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 listzeromq-dev at lists.zeromq.orghttps://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> 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/7176d7eb/attachment.htm>
More information about the zeromq-dev
mailing list