Hi Brett,
Thanks for your answer!
Brett Viren via zeromq-dev kirjoitti 2.6.2021 klo 23.21:
John Lång <john.l...@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
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
