Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

How should a subscriber interpret multiple messages upon subscription?

If I have multiple nodes who each latch a message onto a particular topic, a node that later subscribes to that topic will receive multiple messages immediately upon subscription. If those message types do not include a timestamped header, how should that message pair be interpreted?

The way I wish (and previously thought) topics were conceptualized, a topic would represent a stream of messages that supersede each other (like, the current position of something). In that case, it seems like latching should be "per topic". When a new subscriber subscribes to the topic, it makes perfect sense that they would like to see what the current state of the topic is, even before another message is published. In this case, I would expect that when a publisher latches a message, any other latched message should be unlatched -- future subscribers will want the most recent message on that topic, regardless of source, and messages prior to the most recent one are now obsolete. And this is, in fact, the behavior that publishers in the same node have.

But, when the publishers are in different nodes, multiple messages are sent to a new subscriber. This is different from my conceptualization. I understand that the way topics work, in fact, is that latched messages are resent by their publisher (on a per-node basis) to a new subscriber whenever it detects that new subscriber. But WHY does this behavior happen? What is the rationale behind having all publishers with latched messages send them upon a new subscription? In my conceptualization, the idea is "a new subscriber should be able to know the current state of the topic upon subscription, and that state is defined by the most recent message published to the topic". What is the equivalent idea for receiving multiple messages upon subscription?

How should a subscriber interpret multiple messages upon subscription?

If I have multiple nodes who each latch a message onto a particular topic, a node that later subscribes to that topic will receive multiple messages immediately upon subscription. If those message types do not include a timestamped header, how should that message pair be interpreted?

The way I wish (and previously thought) topics were conceptualized, a topic would represent a stream of messages that supersede each other (like, the current position of something). In that case, it seems like latching should be "per topic". When a new subscriber subscribes to the topic, it makes perfect sense that they would like to see what the current state of the topic is, even before another message is published. In this case, I would expect that when a publisher latches a message, any other latched message should be unlatched -- future subscribers will want the most recent message on that topic, regardless of source, and messages prior to the most recent one are now obsolete. And this is, in fact, the behavior that publishers in the same node have.

But, when the publishers are in different nodes, multiple messages are sent to a new subscriber. This is different from my conceptualization. I understand that the way topics work, in fact, is that latched messages are resent by their publisher (on a per-node basis) to a new subscriber whenever it detects that new subscriber. But WHY does this behavior happen? What is the rationale behind having all publishers with latched messages send them upon a new subscription? In my conceptualization, the idea is "a new subscriber should be able to know the current state of the topic upon subscription, and that state is defined by the most recent message published to the topic". What is the equivalent idea for receiving multiple messages upon subscription?

EDIT: To clarify, the difference between a new subscriber connecting to a topic and immediately receiving two latched messages, and an old subscriber receiving those messages when they were published, is that approximate time synchronization is lost. Assume a topic with superseding messages (and see gvdhoorn's answer for why that might not be a good assumption) that don't include a timestamped header. If publisher 1 publishes and latches message 1, and then an hour later, publisher 2 publishes and latches message 2, the old subscriber knows that message 2 represents the true state of the topic. The new subscriber receives message 1 and message 2 in a random order upon subscription and has no way of knowing which message represents the state of the topic. See answers for responses to this.