2. Architectural Differences

2.1. No Daemons, No Servers

Other systems copy and filter messages using host CPU power to run daemon or server processes acting as intermediaries in the flow of messages.

LBM uses a direct path from source to receiver with no intermediaries. Messages are never copied needlessly.

LBM Benefits. Lower latency and higher throughput because there are no CPU bottlenecks in daemons and servers and no bandwidth bottlenecks at the server's NIC.

Section 6 explains the performance impact of this architecture. See Section 7.5 for how this architecture impacts reliability and resilience designs.

2.2. Multiple Transport Sessions Allowed for Each Sender

Server-based systems use a single transport session (or "connection") from each sender to the messaging server, and daemon-based systems send on one transport session per sending daemon. The three potentially negative consequences of using a single transport session are detailed below.

Mixing messages, of interest to different receivers, on a single transport session burdens the receiver CPU or messaging server with message filtering.

LBM Benefit. A source using multiple transport sessions allows network equipment to filter at wire speed.

Mixing messages with different priorities on a single transport session prevents network equipment from telling the difference.

LBM Benefit. A source using multiple transport sessions allows network equipment to apply prioritization and other Quality of Service (QoS) policies to messaging traffic.

Mixing messages to separate topics on a single transport session prevents them from being sequenced and transmitted separately.

LBM Benefits. A source using multiple transport sessions allows messages on separate topics to be sequenced and delivered independently of each other. This feature is particularly handy for messages of significantly different sizes. The transmission time of large messages need not add latency to small messages from the same source because the sending of small messages can be interspersed within the time taken to send a large one.

See Section 7.2 to learn more about how receivers discover the transport sessions in use by sources.

2.3. Designed for Modern Hardware

Other systems were designed when machines had 1 CPU, 1 NIC, and 64 MB of RAM.

LBM Benefits. LBM is designed specifically to leverage today's multi-core, multi-threaded, multi-gigabit-per-second, and multi-gigabyte hardware. LBM lets you bring all available CPU power, NIC bandwidth, and memory to bear on your messaging problems.

See Section 6 for more on the performance impact of this design.

2.4. Choice of Transport Protocols

Other systems offer only TCP or only reliable multicast transport protocols.

LBM applications choose the transport protocol with the right characteristics for the job at hand: Use TCP when flow control is needed so that receivers can set the pace of messaging. Use reliable multicast when sources should set the pace of messaging and when scalability is required. Use reliable unicast when sources set the pace but multicast isn't possible.

LBM Benefit. LBM offers a single, clean messaging API that can be used for all messaging needs.

2.5. Choice of Filtering Locations

Messaging systems that use daemons burden the receiving daemon with filtering irrelevant messages. Those with servers burden the server.

LBM can filter messages at the source so that they never even leave the source if there are no interested receivers. LBM can filter messages in network hardware. That's done at wire speed and in parallel for all receivers in modern network hardware. LBM can filter messages in the operating system kernel of the receiving machine. LBM can filter messages the receiver's messaging library. See Section 7.4 for more on how LBM efficiently filters irrelevant messages that arrive at receivers.

LBM Benefit. Application architects have a the choice of filtering irrelevant messages in the best location for their application. They have a choice of source filtering, network filtering, kernel filtering, or receiver filtering.

2.6. Separate Sequencing of Datagrams and Messages

Other systems only sequence the datagrams that make up the reliable multicast streams used to deliver messages on many topics. When a datagram is lost, it must be recovered before delivery of any of the topics on the transport session can continue. Recovery latency is added to all topics on the transport session.

LBM sequences messages on each topic independently and also sequences datagrams at the reliable multicast transport layer. LBM continues to deliver messages as they arrive after datagram loss for topics that have not suffered message loss--even while it continues with loss repair efforts.

LBM Benefit. When faced with lost datagrams, LBM does not add recovery latency on topics that did not suffer message loss.

See Section 4.2 for other ways that LBM allows for the lowest-possible latency in receivers.

2.7. No Custom Hardware

Hardware built today specifically for messaging won't benefit from future improvements in CPU, network, and operating system performance unless it is redesigned and reimplemented.

LBM Benefits. LBM runs on commodity hardware and commodity operating systems. LBM will automatically take advantage of future improvements in these areas without redesign.

Copyright 2007 - 2008 29West, Inc.