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.l...@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@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
