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

[Brett Viren]

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.

> • 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 also have an assumption expressing that the publisher process may
> disconnect from the subscriber at any time, but these disconnections 
> could be also caused by reasons other than network failures, e.g.,
> server breakdowns or even planned maintenance.

Yes.

> 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.

-Brett.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20210602/97c2e136/attachment.sig>