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

[John Lång]

Hi Kevin,

Thanks again!

Cheers,
John

On 17.10.2020 18.04, Kevin Sapper wrote:
> 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 list
>>>     zeromq-dev at lists.zeromq.org  <mailto:zeromq-dev at lists.zeromq.org>
>>>     https://lists.zeromq.org/mailman/listinfo/zeromq-dev  <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>     <https://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/20201018/5d1e63db/attachment.htm>