March 01, 2019 - By Justin Wilson, OCI Principal Software Engineer
Middleware News Brief (MNB) features news and technical information about Open Source middleware technologies.
When the Object Management Group (OMG) released the Data Distribution Specification (DDS) in 2004, the goal of the DDS specification was to define the concepts, interfaces, programming language mappings, etc. necessary for developing distributed applications based on a shared cache model.
Recognizing a need for interoperability among DDS vendors, the OMG released the DDS Interoperability Wire Protocol Specification, which defines the Real-Time Publish Subscribe (RTPS) protocol, in 2008.
Like any specification, standard, or system, DDS and RTPS were designed with certain goals and limitations in mind. OpenDDS, as an implementation of DDS and RTPS, is subject to the same limitations. The authors of these specifications could not have foreseen the rise of cloud computing and the (Industrial) Internet of Things.
To build truly interoperable and standards-based applications, we desire the ability to use RTPS in environments like the cloud and public Internet. The overall goal of RTPS is to distribute samples produced by writers to all associated readers. But before writers exchange data with their associated readers, the readers and writers must discover each other.
In RTPS terminology, a reader or writer is called an endpoint, and a collection of endpoints is called a participant. A locator is an IP address and port. Each endpoint is associated with one or more locators.
RTPS accomplishes discovery in two steps: participant discovery and endpoint discovery.
Participants discover each other using the Simple Participant Discovery Protocol (SPDP).
SPDP messages contain endpoints corresponding to built-in readers and writers that RTPS uses for endpoint discovery. Once a participant is discovered, the built-in readers and writers associate and exchange data about the application-defined endpoints.
The protocol that governs the exchange of application-defined endpoints is called the Simple Endpoint Discovery Protocol (SEDP).
SEDP can use unicast without any difficulty, while SPDP relies upon a mechanism like multicast (or broadcast) for periodic announcements.
Many virtual private cloud networks, including Google Cloud Platform, Microsoft Azure, Amazon Web Services, and the public Internet do not support multicast. Thus, SPDP via multicast cannot be used in these environments.
Both SPDP and SEDP messages contain IP addresses and ports in the form of locators. If an endpoint is behind a firewall or router that is performing network address translation (NAT), which is common in many home, office, and industrial LANs, its locators become useless.
Furthermore, configuring a firewall to support RTPS is a daunting task, given the way ports are assigned. Due to these difficulties, RTPS cannot be used in these environments.
In this middleware-focused SETT article, we address the challenge of running OpenDDS in a cloud environment.
Software Engineering Tech Trends (SETT) is a regular publication featuring emerging trends in software engineering.
