[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