Products Design Features

There are several high-performance messaging solutions widely deployed in the market today. We are frequently asked what makes the design of LBM and UME different from EMS™ RV™, Triarch™/RMDS™, or SmartSockets™.

Performance Without Daemons

The team at 29West has been positioned at the forefront of high speed messaging from the design of the first digital trading systems. As we looked at the marketplace and the solutions available in 2003, we were struck by the fact that most high performance messaging problems were being solved with daemon based messaging models originating in the mid-1980s. We believed that by leveraging the intelligence currently built into modern network stacks, switches, operating systems and infrastructure, we could provide a significant jump in performance. We also believed that by focusing on performance and configurability at every design decision, we could provide application developers with a lightweight, but highly tunable solution to allow them to choose the tradeoffs that best fit their application.

Less Message Handling, Less Latency

It was clear early on that to achieve a real performance breakthrough, we would have to eliminate software-based message routing where possible, and remove all message handling processes that exist in legacy messaging designs between the sender and receiver of data. Be they daemons, or message servers (hardware or software based), these extra hops in the data delivery flow reduce scaling and increase latency. The design breakthroughs in the 29West messaging solutions provide true application-to-application dataflow, with full publish/subscribe message semantics. By reducing the tasks and processes that must run in order to deliver a message, we greatly increase efficiency and reduce latency.

Ultra Messaging® Design Advantages

Specifically, 29West has pioneered the following key architectural innovations, which directly improve our performance:

  • We reduce latency by eliminating hops. Each time a message has to be received and re-transmitted by an intermediary daemon or server, significant penalties are incurred by data copies, context switches, process scheduling, and (when the hop goes off-box) network delays. Our design eliminates the need for messaging routers and intermediate messaging daemons. It is purely sender to receiver (application to application).
  • We designed from the start with modern OS and hardware capabilities taken into account. By leveraging the modern OS designs, we create a messaging layer that shares the application’s user space and does not require special daemon processes. Most traditional messaging systems on the market today were originally developed 10 or 20 years ago when networks and machines were not nearly as capable as they are today.
  • Our messaging design does not duplicate the routing capabilities of network infrastructures. We let the network route messages where possible.
  • We allow you to choose the underlying transport protocols to best suit individual application needs. Applications can select the best mix of TCP, Reliable Multicast, Reliable Unicast, Latency-Bounded TCP, and Interprocess Communication on a single host.
  • Our messaging solutions are highly configurable, allowing your application to fine-tune the product’s behavior according to its specific needs. For example, applications that do not need a guarantee of in-order delivery can reap latency and throughput improvements by configuring arrival order delivery. Rate limits, controls over NAK transmissions, and retry limits provide network stability, even under high load and fault conditions.
  • The UME Persistent Store allows a message stream to live on even after the source that sent it is gone. Furthermore, a source need not wait until a receiver is ready before sending messages. In short, sources and receivers need not be running at the same time in order to pass messages.
  • The UME Persistent Store also allows a new source or receiver to pick up where an old one left off. An obvious application of this is a “durable subscription” for a receiver. In this case, a receiver process can stop and restart with no loss of messages, even if new messages were sent while the receiver was stopped. The durable source case can also be beneficial. A source can stop and restart without receivers even knowing.
  • With UMQ, which integrates Queuing into the rest of the already-powerful 29West API, several new features are now available to Ultra Messaging applications, such as once-and-only-once (OAOO) delivery to support clearing and settlement applications, robust failover via Quorum/Consensus (similar to UME failover), and flexible, automatic low-latency load-balancing (LLLB) via the Application Sets feature.

Our pricing structure, support options, and straight-forward licensing provide a business model that we think our customers will find refreshing.

(Note: EMS™, RV™ and SmartSockets™ are trademarks of TIBCO Software Inc. Triarch™ and RMDS™ are trademarks of Thomson Reuters.)