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 by default, utilize TCP connections for data and control traffic. Compression and encryption can be applied to TCP-only peer links. Optionally, latency can be reduced by adding UDP to the peer link; see UDP Peer Link.
The figure below shows a simple DRO use case, where two DROs bridge an ISP to connect two TRDs using a TCP link.
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 DRO Configuration Reference.
UDP Peer Link <-
By default, a DRO peer link uses a single TCP connection to communicate between two DROs. But TCP can introduce latency outliers and limit throughput, especially when used over a high-bandwidth, high-latency WAN link that experiences occasional packet loss. Latency and throughput can be improved by enabling the UDP peer link option.
When UDP is enabled for a peer link, the TCP peer link is still used for DRO command and control messages. Everything else, including user data, is exchanged using UDP.
To enable UDP on a peer link, use the Router Element "<udp>". At a minimum, you must configure the port number.
When configured, both the TCP and the UDP links must be operational. If either link fails to pass data, the DRO will disconnect and reconnect until both links are successful.
The UDP peer link uses the same reliable unicast protocol as the Transport LBT-RU protocol, and shares many of the same configuration options as the transport. However, unlike LBT-RU, the UDP peer link does not need to have a datagram maximum size configured. It is hard-coded to a large value (above 65,000 bytes), chosen to be sufficient to handle all valid UM fragment sizes.
- Attention
- The compression and encryption peer link features are not available for peer links with UDP enabled.
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.
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.
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.