---
kind: concept
slug: publish-subscribe-messaging
title: Publish-subscribe messaging
summary: >-
  Publishers send typed messages to a named topic, and any number of subscribers receive them without knowing each other. This page covers one design, DDS-based topics in ROS 2, with its quality-of-service settings, same-process delivery and security. Only one review card is available so far. Its benchmark is one publisher and one subscriber, so its numbers are indicative only.
tags: [middleware, robotics, publish-subscribe, quality-of-service, security]
papers: ["2211.07752"]
related: [robot-simulation, functional-safety]
status: draft
updated_at: 2026-10-19
---

## 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 [arxiv: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 [arxiv: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 [arxiv:2211.07752 §3.4.1]. The paper does not
claim that the three cases perform alike. Its benchmark shows they do not
[arxiv: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 [arxiv: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 [arxiv: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 [arxiv: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 [arxiv: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 [arxiv: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 [arxiv:2211.07752 §3.7].

Card: [Robot Operating System 2: Design, Architecture, and Uses In The Wild](/papers/2211.07752).

### 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
[arxiv:2211.07752 §3.4.2] [arxiv: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 [arxiv:2211.07752 fig. 3a]:

| Mode | Latency at 1m | Latency at 8m |
|---|---|---|
| Intra-process | 0.23 ms | 1.20 ms |
| Single process (node composition) | 0.34 ms | 3.58 ms |
| Inter-process | 0.71 ms | 8.37 ms |

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.

| Situation | Use | Why |
|---|---|---|
| Two components can share a process and messages are large | Intra-process delivery in one process | Lowest plotted latency and CPU at large sizes [arxiv:2211.07752 fig. 3a] |
| Several components should share a process for resources or latency | Component nodes loaded by configuration | The paper says this saves resources or reduces latency; it gives no separate measurement [arxiv:2211.07752 §3.4.2] |
| Messages cross processes at large sizes | Tune QoS and buffers, or move the pair into one process | Default DDS handles data above about 1 MB poorly; tuning or composition helps. Inter-process send rate falls to 411 Hz at 4m and 198 Hz at 8m against a 1,000 Hz target [arxiv:2211.07752 §3.6] [arxiv:2211.07752 fig. 3a] |
| Lossy wireless link | DDS over UDP, with QoS chosen per endpoint | The paper's loss test at 20% shows about 8 messages received in the first second and 12 to 28 later, against about 29 sent per second [arxiv:2211.07752 fig. 3b]. The QoS used is not stated [arxiv:2211.07752 §3.6] |
| Data must reach late-joining subscribers | Transient-local durability | Replays earlier data to late subscribers [arxiv:2211.07752 §3.6] |
| The transport must be replaceable | Write against the client library and choose the middleware implementation below it | Vendors implement the middleware layer, and implementations can be swapped without code changes [arxiv:2211.07752 §3.4] |
| Microcontroller with limited resources | micro-ROS | A full stack is not expected on microcontrollers; micro-ROS is the stated reuse path [arxiv:2211.07752 §3.2.2] |
| Nodes must authenticate and encrypt traffic | DDS-Security with SROS 2 tooling | Covers authentication, access control and encryption [arxiv:2211.07752 §3.7] |
| Confirmed one-off task, or long task with feedback | Services, or actions | Services confirm a task and the client does not block; actions add feedback and cancellation [arxiv:2211.07752 §3.3] |
| Safety certification is needed | Check the process yourself | The paper gives one example, certification of an autonomous-vehicle stack built on ROS 2 to ISO 26262, and no procedure [arxiv:2211.07752 §3.2.2] |

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

```pseudocode
# 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 [arxiv:2211.07752 §3.6]. The
  plotted values are means, 8.37 ms and 198 Hz at the same size
  [arxiv: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 [arxiv:2211.07752 §3.6]
  [arxiv: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
  [arxiv:2211.07752 §3.6] [arxiv: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](/papers/2211.07752): review of ROS 2 and its DDS-based publish-subscribe layer, quality-of-service settings, security, a small latency benchmark and five case studies.