Publish-subscribe messaging

Overview

Robot software is usually split into many programs that run at the same time. They need to exchange data without knowing about each other, and the network between them may drop or delay packets. Publish-subscribe is the pattern most often used for this. A component publishes a typed message to a named topic, and every component subscribed to that topic receives a copy. A new subscriber can be added without changing the publisher 2211.07752 §3.3.

Topics are one of three communication patterns in ROS 2. The other two are request-response services, for confirmed tasks, and actions, for long tasks with feedback and cancellation 2211.07752 §3.3.

The one invariant the paper states is that the same API serves a subscriber in the same process, in another process or on another machine. The transport behind that API can be swapped 2211.07752 §3.4.1. The paper does not claim that the three cases perform alike. Its benchmark shows they do not 2211.07752 fig. 3a.

This page rests on one card. Other publish-subscribe systems are named in the paper but not covered here, so no claims are made about them. See Variants.

Variants

DDS-based topics with quality-of-service settings (ROS 2)

ROS 2 implements topics on the DDS standard. The parts that matter for a design choice are 2211.07752 §3.4, §3.6, §3.7:

• Message types are defined in ROS IDL or OMG IDL. Code is generated for each client language at compile time 2211.07752 §3.4.1.
• Transport. DDS runs over UDP, and DDS decides itself when to retransmit. The paper argues this suits wireless links better than TCP-based ROS 1, but this is not measured separately 2211.07752 §3.6.
• Quality of service is set per endpoint. Reliability is best-effort or reliable. Durability is volatile, or transient-local, which replays earlier data to late subscribers. History is keep-all, or keep-last with a fixed depth. Deadline, lifespan, liveliness and lease duration serve real-time designs 2211.07752 §3.6.
• Middleware swap. An abstraction layer sits between the client libraries and the vendor. All supported implementations are DDS-based. Community implementations for other transports exist 2211.07752 §3.4.
• Security. DDS-Security adds authentication with public-key signatures, access control that governs which participants may discover each other and use which interfaces, and encryption with AES-GCM. SROS 2 tools generate the keys and policies 2211.07752 §3.7.

Card: Robot Operating System 2: Design, Architecture, and Uses In The Wild.

Same-process delivery through component nodes

Nodes can be loaded into one process by configuration. Messages between publisher and subscriber in that process pass a pointer and skip the middleware 2211.07752 §3.4.2 2211.07752 §3.6. The paper's benchmark compares three modes: intra-process, single process using node composition, and inter-process. At the largest message sizes (axis ticks 1m and 8m), the plotted mean latencies are 2211.07752 fig. 3a:

At 8m, the plot also shows intra-process CPU at 17.6% against 34.1% for inter-process. These are single observations (see Contradictions for the statistic used).

When to use which

The evidence behind each row is one benchmark on one machine, with one publisher and one subscriber, and the case studies are mostly qualitative. Use the rows as starting points, not as settled rules. Measure on your own hardware and network before you rely on them.

Implementation sketch

The paper gives no pseudocode. The sketch below restates the delivery path it describes in prose. It is not an algorithm from the paper.

# Publish one message on a topic  [arxiv:2211.07752 §3.4, §3.6]
# Input:  topic, typed message, subscribers (each with its process)
# Output: each subscriber receives one copy

def publish(topic, message, subscribers):
    # Same process: share a pointer and skip the middleware  [§3.6]
    for sub in subscribers:
        if sub.process == self.process:
            sub.queue.push(pointer_to(message))

    # Other process or machine: hand off to the middleware layer  [§3.4]
    # Reliability and history follow the publisher's QoS  [§3.6]
    for sub in subscribers:
        if sub.process != self.process:
            middleware.send(topic, message, qos=self.qos)

Contradictions

• Latency statistic. The text quotes 95th-percentile values, for example 7.85 ms latency and 213 Hz send rate at 8 MB 2211.07752 §3.6. The plotted values are means, 8.37 ms and 198 Hz at the same size 2211.07752 fig. 3a. This page uses the plotted means and labels them as such. Do not mix the two sets of numbers.
• Size units. The text gives sizes in MB. The axis label says bytes, and the tick labels are written with k and m 2211.07752 §3.6 2211.07752 fig. 3a. The paper does not say which unit the ticks use.
• Wireless robustness. The text says ROS 2 handles lossy wireless links better than ROS 1. The paper shows no ROS 1 measurement for this 2211.07752 §3.6 2211.07752 §2.

No other card covers this concept, so contradictions with other papers cannot be checked here.

Papers

• Robot Operating System 2: Design, Architecture, and Uses In The Wild: review of ROS 2 and its DDS-based publish-subscribe layer, quality-of-service settings, security, a small latency benchmark and five case studies.