[zeromq-dev] Formally modelling the publish-subscribe pattern
John Lång
john.lang at mykolab.com
Thu Jun 3 09:52:39 CEST 2021
Hi Brett,
Thanks for your answer!
Brett Viren via zeromq-dev kirjoitti 2.6.2021 klo 23.21:
> John Lång <john.lang at mykolab.com> writes:
>
>> • When there is a message in transit between two processes and the sender
>> attempts to transmit another message, then the new message will be dropped.
> No. Or at least not necessarily. My mental picture is:
>
> (sender app)-[sender socket]-[sender queue]
>
> ->-transport->-
>
> [receiver queue]-[receiver socket]-(receiver app)
>
> If (receiver app) stops calling recv() on [receiver socket] then
> [receiver queue] will start to fill until hitting the set high-water
> mark (HWM, default = 1000).
>
> The next message will stay in [sender queue] and that queue will fill
> until hitting its HWM.
>
> The very next message send()'ed to [sender socket] will not enter
> [sender queue] and thus for this receiver it will be dropped.
I should have mentioned that I'm approximating something like HWM 1
because buffering would explode the state space of my model very badly.
The model already takes hundreds of gigabytes of RAM with some
properties and parameters.
>> • Messages to n recipients are transmitted over n one-to-one connections
>> which may fail or drop messages independently.
> This and your other bullets match my understanding.
I'm glad to hear that my assumptions make sense.
>> The point is that the subscribers should not need to know the
>> particular reason for a disconnection. All they need to do is to
>> connect to another publisher.
> The "need to know" and any subsequent behavior is really
> application-specific.
>
> If/when the PUB side "goes away" (for whatever reason) the application
> with the SUB will not be informed that PUB is gone. The SUB side might
> infer PUB's death based on the lack of any recent messages. What it
> then does, depends on the intentions of the application developers.
You're right. This is application-specific. I meant to say that in my
application, subscribers just switch to another publisher if the
connection dies. I have redundant publishers and subscribers. Is there
some timeout parameter to detect if the publisher just vanishes?
Cheers,
John
More information about the zeromq-dev
mailing list