Inter-transport Communication

Inter-transport communication becomes necessary, when participants want to communicate that are connected to the unified bus using different transport mechanisms.


This description describes the TCP-based transport but also applies to the Spread transport.

Inter-Transport Setup

digraph interTransport {

subgraph clusterInprocessAndSocket {
  label="inprocess-and-socket : Process"

  l1 [label="Listener", shape=box, style=filled, fillcolor="#c0ffc0"]
  sic1 [label="Socket In Connector", shape=octagon, style=filled, fillcolor="#ffc0c0"]
  iic1 [label="Inprocess In Connector", shape=octagon, style=filled, fillcolor="#ffc0c0"]

  sic1 -> l1
  iic1 -> l1

  i1 [label="Informer", shape=box, style=filled, fillcolor="#c0ffc0"]
  soc1 [label="Socket Out Connector", shape=octagon, style=filled, fillcolor="#ffc0c0"]
  ioc1 [label="Inprocess Out Connector", shape=octagon, style=filled, fillcolor="#ffc0c0"]

  i1 -> soc1
  i1 -> ioc1

  ib [label="Inprocess Bus", shape=ellipse, style=filled, fillcolor="#c0c0ff"]

  ib -> iic1
  ioc1 -> ib

subgraph clusterSocketOnly {
  label="socket-only : Process"

  l2 [label="Listener", shape=box, style=filled, fillcolor="#c0ffc0"]
  sic2 [label="Socket In Connector", shape=octagon, style=filled, fillcolor="#ffc0c0"]

  sic2 -> l2

sb [label="Socket Bus", shape=ellipse, style=filled, fillcolor="#c0c0ff"]

sb -> sic1
soc1 -> sb
sb -> sic2

This page describes how to setup participants for inter-transport communication using the following scenario which is illustrated in the above figure:

Participants reside in two separate processes


With this setup, the listener in the inprocess-and-socket process will currently receive all events twice.

There are two ways to attach multiple transports to participants:

  1. Via configuration options (configuration file, environment variables, etc.)
  2. Programmatically

These two alternatives are described below.

Via Configuration Options

When configured via the configuration mechanism, the multi-transport setup will have a global effect in the following sense: it will affect all participants in all processes which are not explicitly instantiated with a different set of connectors.

In addition to the Spread transport which is (currently) enabled by default, other transports can be enabled globally using a configuration file fragment like this:

enabled = 1

Programmatically (C++)

The set of transports used by individual participants or as a default by all newly created participants can be configured by modifying rsb::ParticipantConfig::Transport objects. These objects contain, among other things, an option which controls whether a particular transport is enabled. A modified rsb::ParticipantConfig object can be used in two ways:

Globally for a Process

The example programs inprocess-and-socket.cpp and socket-only.cpp implement the inter-transport setup described above by modifying the default participant configuration in the inprocess-and-socket process to include the inprocess transport.

Locally for a Participant

In order to use a prepared rsb::ParticipantConfig object only locally instead of installing it as a global default, it can be passed to the following methods:

  • rsb::Factory::createReader
  • rsb::Factory::createListener
  • rsb::Factory::createInformer


In each of these cases, the modified configuration options will only effect the participant created by the method call.