Other systems using UDP for messaging often force each message into its own datagram, sacrificing efficiency for small- to medium-sized messages. Each datagram sent consumes CPU power at the source, protocol overhead on the network, and CPU power at the receiver. This lack of batching offers low latency at low message rates, but the CPU power and network bandwidth consumed makes latency much worse as message rates peak.
LBM allows sources to control the batching of messages into datagrams. Batching parameters control the batch size and maximum latency to be added in the interest of efficiency. Applications may also explicitly flush the batching buffer with the sending of a message. Managing batching efficiency can be critically important in high-throughput, low-latency applications like options feed handlers.
LBM Benefit. Applications have the batching controls needed to get high efficiency and the lowest-possible latency when they need it most--when messaging rates peak.
Other systems deliver messages only in the order they were sent. Messages that arrive after a temporary loss occurs make the lost message irrelevant or greatly diminish its value for some types of message streams. Latency must be added as the system attempts to repair the loss if messages must be delivered in the order they were sent.
LBM allows receivers to avoid this latency by specifying that messages should be delivered in the order they arrive. Each message is delivered with the sequence number that LBM automatically added at the source. The receiver gets messages with the lowest-possible latency but it also has the information it needs to determine the relevance of each message. The ordering decision is local to each receiver and each topic. It does not affect the source.
LBM Benefits. Applications need to incur message reordering latency only when they benefit from ordered delivery.
Some messaging systems deliver messages only on a thread from the receiving application. A thread context switch from the messaging system to the application is required for the delivery of each message, thus limiting throughput and adding latency.
Other messaging systems deliver messages only on a thread owned by the messaging system. No thread context switch is required, but the application message delivery callback code cannot block without bringing the messaging system to a halt.
LBM gives each receiver the option of running the message delivery callback code on an LBM thread for the lowest-possible latency. Alternatively, a receiver may choose to use an event queue mechanism built into LBM. The application then provides a thread to dispatch events from the queue. Event callbacks may block without impacting LBM. Simultaneous execution of messaging and application threads makes optimal use of modern multi-core and multi-CPU systems. Any number of queues and dispatching threads may be used.
LBM event queues can be configured with limits on the latency or size of the queue. This allows applications fine-grained control over their queues.
LBM Benefit. Application developers can choose the lowest-possible latency or the freedom to have their callbacks take as long as desired with parallel execution of messaging and application threads.
Copyright 2007 - 2009 29West, Inc.