Revision history [back]

(I'm just a user, as you are, so the below is based on my understanding of what is there, not what it was designed to do or how it was designed)

This probably does not completely answer your question, but may be something to think about: say I have n publishers on a single topic (something like temperatures). Each msg includes an id field or similar, and each publisher sets this id field to indicate the originating temperature sensor (maybe the location, maybe just a numeric ID).

If we follow your idea -- each topic contains the 'latest state' -- then we have a problem: which of the n sensor msgs represents 'the latest state'? There is no single message that contains the state of the entire system (which is an ambiguous thing anyway). Only by keeping track of msgs that have been received, and storing the data in some internal model would consumers be able to piece together what the aggregate state of all temperature sensors is.

It could still make sense for these publishers to latch their publications though: it allows late joiners to instantly become aware of the latest available state of all temperature sensors indepenent of their sampling & publication period. That is what latching is for.

There is no requirement (or even a convention) for topics to represent "the current state" of anything, unless the author of the node, and thus the designer of the dataflows, decides that it makes sense to him. Named, typed topics are basically an addressing scheme for dataflows, nothing more. It is then the responsibility of the consumers of those dataflows to figure out how to handle incoming messages.

Adding timestamps (ie: headers) to messages is one way in which producers can make it easier for consumers to make sense of incoming messages. The id in the example above is of course similar to what a std_msgs/Header provides with its frame_id and stamp fields, although it's only the space coordinate of a sensor. The time coordinate is missing from the message.

Some additional comments:

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.

Your main assumption here is that all topics always carry some sort of message that encodes some kind of 'state union'.

And this is, in fact, the behavior that publishers in the same node have.

Slight nuance: only if those publishers publish to the same topic.

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

and that is how latching works, but it's up to the subscriber to make sense of the incoming messages. See my earlier example for why your idea doesn't work in the general case.

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?

Can you clarify how this is any different from receiving messages on topics that are not latched? If I have multiple publishers on a topic and a subscriber joins (perhaps late, perhaps not) then that subscriber will also receive multiple messages. The fact that you receive them slightly spread out in time does not matter: without timestamps there is no way to tell -- with any sort of accuracy -- which is newer or older. Delivery order is guaranteed only within a dataflow between a publisher and subscriber, not across all subscriptions that a subscriber might have. If that is important, then infrastructure such as headers and message_filters should be used.

(I'm just a user, as you are, so the below is based on my understanding of what is there, not what it was designed to do or how it was designed)

This probably does not completely answer your question, but may be something to think about: say I have n publishers on a single topic (something like temperatures). Each msg includes an id field or similar, and each publisher sets this id field to indicate the originating temperature sensor (maybe the location, maybe just a numeric ID).

If we follow your idea -- each topic contains the 'latest state' -- then we have a problem: which of the n sensor msgs represents 'the latest state'? There is no single message that contains the state of the entire system (which is an ambiguous thing anyway). Only by keeping track of msgs that have been received, and storing the data in some internal model would consumers be able to piece together what the aggregate state of all temperature sensors is.

It could still make sense for these publishers to latch their publications though: it allows late joiners to instantly become aware of the latest available state of all temperature sensors indepenent of their sampling & publication period. That is what latching is for.

There is no requirement (or even a convention) for topics to represent "the current state" of anything, unless the author of the node, and thus the designer of the dataflows, decides that it makes sense to him. Named, typed topics are basically an addressing scheme for dataflows, nothing more. It is then the responsibility of the consumers of those dataflows to figure out how to handle incoming messages.

Adding timestamps (ie: headers) to messages is one way in which producers can make it easier for consumers to make sense of incoming messages. The id in the example above is of course similar to what a std_msgs/Header provides with its frame_id and stamp fields, although it's only the space coordinate of a sensor. The time coordinate is missing from the message.

Some additional comments:

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.

Your main assumption here is that all topics always carry some sort of message that encodes some kind of 'state union'.union'. That is not true.

And this is, in fact, the behavior that publishers in the same node have.

Slight nuance: only if those publishers publish to the same topic.

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

and that is how latching works, but it's up to the subscriber to make sense of the incoming messages. See my earlier example for why your idea doesn't work in the general case.

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?

Can you clarify how this is any different from receiving messages on topics that are not latched? If I have multiple publishers on a topic and a subscriber joins (perhaps late, perhaps not) then that subscriber will also receive multiple messages. The fact that you receive them slightly spread out in time does not matter: without timestamps there is no way to tell -- with any sort of accuracy -- which is newer or older. Delivery order is guaranteed only within a dataflow between a publisher and subscriber, not across all subscriptions that a subscriber might have. If that is important, then infrastructure such as headers and message_filters should be used.