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

[Bill Torpey]

Hi John:

My two cents, based on empirical observation, rather than inspection of the code...

> • Message contents are never altered.
Correct.


> • Messages between two processes are not duplicated in transit.
That would depend on the underlying transport — e.g., with TCP this is correct

> • Those messages between two processes that are received arrive in the order they were sent.
Again, potentially transport-dependent, but with TCP this is correct.


> • 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.
Nope — not sure what makes you say that.  Many messages can be “in flight” at any given time.


> • Messages to n recipients are transmitted over n one-to-one connections
> which may fail or drop messages independently.
Again, depends on transport.  For instance with epgm, a single message "on the wire” is delivered to potentially many recipients “simultaneously”.


> subscribers should not need to know the particular reason for a disconnection. 
AFAIK there is no way for a subscriber to know that in any case.


> All they need to do is to connect to another publisher.
Or reconnect to the same publisher, which ZeroMQ will handle automatically if you want.

Hope this helps.

Regards,

Bill


> On Jun 2, 2021, at 1:29 PM, John Lång <john.lang at mykolab.com> wrote:
> 
> Hello again,
> 
> I have a new question on this topic. I'm now summarising my assumptions on the network protocols underlying my distributed system. These are my assumptions on 0MQ PUB-SUB connections in my model:
> 
> • Message contents are never altered.
> • Messages between two processes are not duplicated in transit.
> • Those messages between two processes that are received arrive in the order they were sent.
> • 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.
> • Messages to n recipients are transmitted over n one-to-one connections
> which may fail or drop messages independently.
> 
> Are these assumptions sensible?
> 
> 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. 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.
> 
> Best regards,
> John Lång
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev