Dynamic Routing Guide
DRO Architecture


DRO Portals  <-

The DRO uses interfaces, called portals, through which to pass data. A DRO consists of two or more bidirectional portals that may be one of two types:

  • An endpoint portal, which communicates directly to a UM topic resolution domain (TRD; see Topic Resolution Domains).
  • A peer portal, which communicates via TCP with another peer portal (of another DRO), allowing tunneling between DROs. Two peer portals connected to each other are referred to as companion peers, and utilize TCP connections for all data and control traffic (UDP is not supported for this). Compression and encryption can be applied to peer links.

The figure below shows a simple DRO use case, where two DROs bridge an ISP to connect two TRDs.

portals.png

You configure portals in the DRO's XML configuration file, specifying the portal's name, cost, UM Configuration, Access Control Lists and other attributes. See XML Configuration Reference.


Topic Resolution Domains  <-

Since topic resolution uses UDP, sources and receivers must have UDP connectivity to each other. When they do, we consider them to be in the same topic resolution domain (TRD). More specifically, UM contexts must satisfy the following two requirements to belong to the same topic resolution domain.

  • The contexts must use the same topic resolution UM configuration (i.e., resolver_* options are the same).
  • Contexts can communicate using the protocols required for both message transport and topic resolution traffic.

For example, two contexts on separate machines in the same LAN are not in the same topic resolution domain if they use different resolver addresses. See Multicast Resolver Network Options. A topic resolution domain can span a WAN if the UM contexts on each side of a firewall use the same UM configuration and the firewall allows UDP traffic (multicast or unicast) to pass.

Each endpoint portal must identify its associated topic resolution domain with a domain-id the DRO's XML configuration file, as in the example below. All portals in the same TRD must have the same domain-id, and different TRDs networked together via DROs must have domain-ids unique to each other.

<portals>
<endpoint>
<name>LAN100</name>
<domain-id>100</domain-id>
<lbm-config>lan100.cfg</lbm-config>
</endpoint>
<endpoint>
<name>LAN200</name>
<domain-id>200</domain-id>
<lbm-config>lan200.cfg</lbm-config>
</endpoint>
</portals>


Proxy Sources and Proxy Receivers  <-

To resolve a topic across a DRO (described in Basic DRO Operation), the DRO creates, within portals, proxy sources and proxy receivers (shown in the figure below by their dashed lines). These proxies behave like their UM counterparts; they resolve topics on the TRDs like normal sources and receivers, and the DRO internally passes data from one portal to the other. However unlike regular sources, proxy sources do not have retransmission retention buffers normally used for Late Join or OTR.

proxies.png

Portals exist while the DRO is running, however, the DRO creates proxy sources and receivers during topic resolution and deletes them when the topic is retired.

Note
The proxy sources created by the DRO are unrelated to proxy sources created by the UMP persistent store.


DRO and Transport Sessions  <-

When the DRO creates proxy receivers to get messages to forward, be aware that the transport sessions carrying those messages are not extended to the destination TRD. Instead, the proxy receiver simply takes the messages from the originating transport sessions and transfers them to the destination DRO's proxy sources. Those proxy sources create new transport sessions for those outgoing messages.

The proxy sources' outgoing transport sessions are unrelated to the originating sources' transport sessions. They can even use different transport types, performing a protocol conversion. In fact, a single transport session can contain multiple sources from different originating publishing applications for the same topic. Alternatively, multiple sources from the same originating publishing application which are mapped to the same originating transport session can be split into multiple transport sessions by the proxy sources in a remote TRD.

One consequence of the independence of incoming and outgoing transport sessions is that TCP flow control does not transit the DRO. A slow receiver in a remote TRD cannot "push back" on a fast source. In cases where a TCP transport session is slowed down due to one or more slow receivers, an intermediate DRO will eventually have to drop messages.

Warning
A single source's "source string" will be different in different TRDs connected by DROs. See Source Strings in a Routed Network for details.


Routing  <-

In multiple-DRO environments where more than one DRO can provide possible messaging pathways, the DROs are able to cooperatively determine and establish optimal routes. Also, the DRO network is able to detect link or other DRO outages and automatically reroute traffic as needed. See Routing Topologies for more information.