Real-Time Innovations (RTI) is best known for its messaging middleware, which is deployed in support of low-latency applications such as algorithmic trading, within trading firms. Recently, RTI introduced the RTI Routing Service, which can be used to bridge applications and networks running in different locations – up to tens or hundreds of thousands of applications. IntelligentTradingTechnology.com talked about this development with Sumeet Shendrikar, RTI’s director of technology for financial services.
RTI Routing Service be used to link applications running in different locations. What kinds of financial markets uses might it be leveraged for?
Shendrikar: There are a variety of use cases that can take advantage of the RTI Routing Service. The most immediate would be to reduce the time and effort spent integrating DDS (Data Distribution Service – a standard for publish/subscribe messaging middleware) applications across wide area networks and systems-of-systems. Traditionally, multiple publishers within one data center may need to communicate with multiple subscribers in the other data centre. This poses a challenge if an administrator needs to open multiple ports for the data to travel between sites. Complicating matters, a user would have to build a repeater or proxy application when sending data between systems or data centres across the WAN – particularly in the context of multicast distribution. With RTI Routing Service, you can scale DDS beyond a specific system and make it available throughout the WAN, without making any changes to existing DDS applications.
RTI Routing Service acts just like a network router; a user defines the “topics” and their “routes”, so that specific streams are automatically forwarded. The RTI Routing Service can act as the proxy for the remote data centre, simplifying the application architecture. You can take an existing system and integrate it with new applications or other existing systems without any changes to those existing systems. RTI Routing Service also provides secure deployment across multiple sites. You can partition networks and protect them with firewalls and NAT (network address translation) to precisely control the flow of data between network segments. RTI Routing Service allows you to manage the evolution of your data model at the subsystem level; data can be transformed on the fly, as can topic names, type definitions, QoS (quality-of-service), etc. to seamlessly bridge between different generations of applications.
Beyond this, RTI Routing Service allows an easy way to bridge DDS domains. A DDS domain essentially is an isolation container for applications, such that two applications in different domains do not communicate even if in the same network. Firms often use domains to isolate production versus deployment, or to isolate traffic from disparate systems (e.g. a firm could have a domain for all applications that publish/subscribe to market data, and another domain for all applications that send/receive orders & executions). With RTI Routing Service, data can be shared across domains while minimising the traffic. This domain bridging is vital for development and integration testing, where one subsystem can expose or accept selected data from other subsystems.
RTI uses the standards-based DDS protocol across local area networks. Why is it not possible to use it across wide area networks too?
Shendrikar: DDS can be and has been used across wide area networks. The QoS controls allow the user to tailor the protocol appropriate for the underlying network capabilities, whether that be across the WAN or a LAN. For example, DDS has been used across wireless, satellite, Tactical Data, and specific DIL links (Disconnected, Interrupted, and Low-bandwidth). Plus, RTI Data Distribution Service uses a pluggable transport protocol that enables these controls regardless of the underlying protocol (TCP or UDP). However, as with all protocols, there are concerns that must be addressed when going beyond the LAN.
Our product was architected for high performance AND consistent performance (low jitter). To do so, we use UDP as the network level protocol because it allows us to control when packets hit the wire as well as the behavior of the reliability logic. However, many users are hesitant to deploy UDP across a WAN for security and delivery reasons. UDP across a WAN requires either hole punching in a firewall or opening ports which can leave a system exposed. UDP can be de-prioritised in routers not under control (i.e. the public infrastructure) or dropped entirely because UDP doesn’t have flow and congestion controls.
Now, one could use TCP but then performance and scaling become a concern. Further, a WAN subscriber is inherently a slower consumer of the data given the increased latency of the physical connection. Intelligently managing remote applications becomes a requirement, but system architects want minimal impact.
RTI Routing Service enables this rapid development and deployment. Since the RTI Routing Service acts as a nominal subscriber in the LAN (e.g. using multicast), it decouples the remote systems from impacting the local applications. And, by using two RTI Routing Services – one in each data centre – you essentially create a single pipe through which data can flow, again with minimal impact to running systems.
Using the RTI Routing Service, what levels of performance – throughput, latency – are possible? And how scalable is the architecture?
Shendrikar: Though we don’t have concrete performance metrics yet, our expectations are for performance to be comparable to the standard RTI Data Distribution Service middleware: as fast as the network allows. For example, consider the use case where RTI Routing Service is delivering data to a remote system via TCP over the WAN. The network link itself likely is constrained and may require some form of encryption when traversing the WAN. RTI Routing Service will fully utilise the bandwidth available, if so configured. The user also could configure RTI Routing Service to only allow a subset of the data to avoid saturating the link.
As for scalability – we haven’t measured the achievable scalability as of yet. For reference, some of our customers already use RTI Data Distribution Service in deployments of more than 1,000 applications before this product existed. We envision the RTI Routing Service enabling systems-of-systems, where the application count is in the tens or hundreds of thousands.
How is security maintained and enforced in wide area implementations? Can the RTI Routing Service be used to segregate data between different domains for regulatory purposes?
Shendrikar: Security is always a difficult subject because it has so many different definitions. Generally speaking, security is often spoken in terms of information assurance (IA), with specific attention to authentication and encryption. Complicating matters, the “security” of a particular entity cannot necessarily be analysed without looking at its fit within the entire system. Because most of our customers are in the DoD space, suffice it to say that our “security conversation” can go beyond the observed uses in the financial services domain. As one example – RTI works with Tresys, a security specialist company that manages SELinux, a set of patches to Linux that were first made available by the NSA and provide mechanisms for supporting access control security policies within the kernel.
That being said, RTI Routing Service was designed with IA in mind, including uses such as:
– information guards, i.e. one-way information dissemination controlled through topic routes
– transformations that can modify the data before transmission, removing sensitive information
– encryption, both at the user and network level (TLS/TLS-D) – authentication, by leveraging the DDS discovery process
So while DDS already provides a facility for segregating data through the domain concept described earlier, the RTI Routing Service augments this abstraction by sharing data between domains but transforming it in such a way that satisfies regulatory requirements.
Apart from spanning geographies, how can the RTI Routing Service be used to integrated between disparate applications, and integrate legacy applications?
Shendrikar: Legacy applications can be integrated by using RTI Routing Service to normalise the data model; a legacy application may support an older version of the data or in a different format. Some systems get around this by using name/value pairs rather than explicit fields, but even this data might need cleaning up or transformations to support a legacy schema (e.g. a property name has changed between releases). Further, the RTI Routing Service can load a user-defined library that implements a custom data transformation.
Though not yet fully developed, the RTI Routing Service can be augmented to support legacy messaging adapters, thereby integrating legacy applications that use an older messaging bus. This is quite common for our customer base with applications that cannot be modified, but have data that is relevant to newer DDS-based applications. The RTI Routing Service can act as a legacy bridge, converting the data between DDS and the legacy format. Furthermore, the rest of the system is not affected if and when the older apps migrate to DDS. To use RTI Routing Service in this manner, customers can build the non-DDS messaging adapter by working with our Professional Services team.
Click here for more information of the RTI Routing Service.