Abstract
This
article discusses the following questions: 1. What are the tradeoffs with the
current leading messaging paradigms? 2. Given the growth in messaging and data
rates, the focus on low latency data delivery, and the need to deliver data
over a range of network topologies, what requirements must future solutions meet?
We
look at the leading approaches of peer-to-peer broadcast/multicast and
server-based messaging and compare them with the performance gains possible
when using a true application to application messaging model, like the one used
by the 29West messaging products: Latency Busters® Messaging (LBM) and Ultra MessagingÔ for the Enterprise (UME).
Before 29West, the
dominant solutions used in high-performance messaging applications tended to be
either server based or daemon based designs. Each model has performance and
feature tradeoffs, with network and application type impacting its performance.
This article summarizes the key features and tradeoffs.
Early high-speed
messaging systems, like the Rich/Reuters TRIARCH system, were developed in the
mid-1980’s as part of the first digital trading floors and worked under many
constraints. They had limited processing power, memory and networking
capabilities; these constraints led to the development of UDP-based broadcast
protocols that used concepts like packet numbering to detect and recover lost
data. This data would typically be the only data on the network, and frequently
all machines would see all traffic. To make this class of system work, each
receiving machine had a messaging daemon that discarded the network traffic
that applications on that machine were uninterested in (did not subscribe to).
This approach has worked well for years, and is the most widely deployed legacy
messaging model in the high performance, financial messaging market today. Due
to the amount of data being broadcast/multicast, however, this model had
difficulty distributing data in this way across more complex networks. To solve
this problem, gateway boxes were typically employed to isolate unwanted traffic
from crossing physical or logical network boundaries.
In the 1990’s,
messaging systems were built around a central message broker: Talarian
introduced the SmartSockets model for messaging; the Java Messaging Service
(JMS) was a standards based pub/sub messaging model that also emerged at that
time. In these models, all traffic was sent to a central server (or a server
cloud for load balancing), and that server forwarded traffic only to interested
machines. All traffic would typically be sent point to point. This model
offered a number of advantages; using TCP and unicast addressing, it could
easily distribute messages over complex topologies and through routers and
firewalls. In addition, receiving machines received only the traffic they were
interested in, and the central server provided value-added services, such as:
store and forward capability, security, authentication, guaranteed messaging
and “durable subscriptions.” As the number of subscribers, publishers, or
message rates grew, however, the server load increased, and delivery of data to
multiple receivers became “unfair” (i.e., someone got it first, and someone got
it last). Besides the scaling issues, message routing by a separate “message
broker” or server added considerable latency to the data path.
2. New Market Forces
A decade ago,
financial industry technologists dreamed about, and worked on, completely
automatic financial processes like electronic trading, black box trading,
algorithmic trading, automatic execution engines, electronic exchanges, direct
exchange feeds, crossing networks, and t+0 settlements. These automated
solutions are now becoming common.
Furthermore,
as the business volumes of quotes, trades, and orders have grown phenomenally,
all market participants have been constantly challenged to increase compute
power, messaging throughput, and network speeds. Similar challenges appear wherever
completely automated financial systems connect directly, with human response
times not a factor that can slow the process.
Within
this large eco-system, automatic systems use high-speed messaging software to interact.
In fact, the speed, latency, reach and reliability of the underlying messaging
infrastructure represent major limiting factors for many of today’s business
processes. A successful messaging architecture must also allow for run time
tradeoffs between reliability guarantees, application size, and performance – parameters that can
vary, depending on the nature of the data, the needs of the applications, and
the networking environment through which the message data travel. In some
streaming applications, potential data loss in peak conditions is preferable to
re-sending data to allow recovery. You may prefer to miss a stock quote, for
example, if by doing so you ensure that a more current quote arrives with
minimal latency. A new class of applications becomes practical as network speed
increases and the cost of high performance, end-user devices drops.
Many large
end-users saw the need for a new messaging model over the last seven years; and
before LBM appeared in 2004, companies that wanted a more efficient messaging
model were forced to develop their own solutions. These “home grown solutions”
were some of the earliest players in the Ultra Messaging™ market – solutions
that the
application-to-application messaging products from 29West currently address.
29West is focused
on the needs of the very high performance, low latency messaging applications:
the Ultra Messaging market. For some applications, high performance and low
latency are not critical and mass-market, legacy messaging solutions can
perform adequately.
When you wish to
get the best performance and scalability for very high performance, low latency
messaging applications, however, your solution must address the following key
requirements:
·
Enable the sending application to choose, on a per topic basis, the
appropriate transport for the topic being published
·
Support for multiple transports, including: TCP/IP, latency bounded
TCP/IP, reliable UDP unicast and reliable UDP multicast
·
Ensure there are no additional processes in the data path between
sender and receivers – pure application to application messaging that minimizes
data copying and removes the need for daemon processes and central servers,
which add latency and reduce throughput
·
Enable the support of millions of “topics” with very high throughput
·
Support a distributed network state, so that all participants share the
responsibility for service discovery and management
·
Provide full commercial support
·
Enable the support of both streaming messaging models and persistence
and guaranteed messaging models at wire speeds
·
Enable the support of low latency, fail over models like “Hot – Hot”
and leverage commodity hardware, used redundantly, to provide cost effective,
fault tolerant, solutions
·
Support for a C API as well as .NET and JAVA language support
Where possible, we
want to leverage network intelligence to handle group traffic, identify
available services, and reduce the loads on individual receivers. We are
focused on the high speed, low latency delivery of very large amounts of
message traffic. With this in mind, we have reduced multi-level architectures
wherever possible. By removing the role of separate messaging daemons to filter
unwanted traffic, the 29West design eliminates the occurrence of central choke
points like message servers, extra data copying and processing. In addition, we
want the sending application to be able to control data flow as well as
protocol selection.
To achieve these
goals, 29West Messaging products draw on the following unique features:
· Support for reliable IP multicast, TCP/IP, latency bounded TCP/IP and reliable UDP unicast.
The combination of
many transport models allows the 29West messaging layer to provide the approach
that bests suits the application parameters and network capabilities. By
providing extensive remote configuration support and management capabilities,
we have reduced the time it takes to update an application and make it easy to
scale LAN /WAN and other network boundaries.
29West messaging
layer design has focused on flexibility, application independence, network
independence, and raw performance (both high message rates and low latency)
with low overhead. We have been able to achieve these goals with remarkable
success. In a demonstration at the Futures Industry Association Show in October
of 2004, LBM delivered message rates of over 1,400,000 messages/sec. For more
details, please see http://www.29west.com/products/lbm/messaging-performance-lbm.php,
and http://www.29west.com/links/29west-fia-2004.pdf. Using 2007 hardware, these
numbers easily climb to over 2,400,000 messages per second. For details, please
see http://www.29west.com/products/lbm/messaging-performance-lbm.php
In applications
where LBM has replaced other leading messaging layers, many of our customers
and evaluation accounts have been able to increase throughput by a factor of between
3 and 10 times the data rate they achieved with their existing solutions.
Improvements in measured latency by factors of 10 or more are typical. The most
interesting numbers result from measuring performance in your application and
network environment. Because many factors can impact performance, we encourage
interested prospects to put 29West evaluation software to the test and see what
gains we provide in your environment. We are confident you will see very
significant performance gains. Over 80 percent of the firms that evaluate
29West messaging solutions move to a software license agreement.
Gaining the very
highest performance always involves tradeoffs, and 29West offers consulting and
integration support for customers who are interested in taking a systems level
view of their data flow and application design. 29West enable customers to
truly manage message flow, exception handling, and overall application design,
making truly high performance applications easier to create and support in
production.
Until the
announcement of persistence in the 29West product family in September of 2006,
applications that needed features like delivery confirmation, durable
subscriptions, and late join support were forced to provide that logic in the
application layer. With
What gets left
behind? We believe you lose no key functionality and gain some key performance
and flexibility. Any truly new design will be different; and since 29West has
created a clearly new design, you may need to modestly redesign messaging
applications built on legacy systems to benefit the most from our support for
multiple protocols, a wide range of network addresses and other unique
features. Most customers have found that simply porting over an existing design
dramatically improves performance, but the best way to determine this is to use
our evaluation model to see what gains you can expect with your applications
running on your network.
In addition to our
“C” language API, we offer a JAVA API and a .NET API. We provide support for
the Solaris, Windows, Linux and AIX operating systems. Customers have been able
to move production systems from legacy messaging systems to a 29West-based
model in as little as 30 days. Most of our evaluations end up with a running
pilot at the end of the 30 day evaluation. Since we provide a range of sample
applications with the evaluation software, customers can hit the ground running
and port applications fairly quickly.
29West has been
able to provide a competitive advantage to many of the largest banks, hedge
funds and exchanges worldwide, with production deployments of 29West messaging
in applications ranging from exchanges to program trading to direct exchange
feedhandlers, order entry and many more.
As applications
evolve to require new data delivery models, more performance, and lower
latency, the messaging layer must have an adaptable and flexible delivery
mechanism and be designed from the ground up for efficiency. The team at 29West
started with over 20 years of financial market data delivery experience, a
clean sheet of paper, and a single goal: to build the highest throughput,
lowest latency, most flexible messaging products for the financial markets. In
June of 2004, we announced LBM and our first customer, and have been setting
the performance standard in the market ever since. With innovative design
ideas, the absolutely highest performance and customer focused integration
expertise, 29West is servicing the growing needs of the ultra-low latency
messaging market. Our goal is to provide our customers with a solution that not
only provides a strong performance boost, but is also more tightly coupled to
the customer’s business and data delivery model.
When we first
announced LBM, prospects could not believe our performance claims. The market
is far less skeptical now, as we are deployed in production at firms world-wide
and as other vendors are planning to come to market with design ideas that
29West pioneered over three years ago. With the addition of
If you would like to learn more about 29West Messaging, please
visit http://www.29west.com/
or contact us at info@29west.com.
We have offices in