7. Ordered Delivery

Modern networks are very reliable, and dropped packets happen far less often then they used to. However, most messaging systems still need to deal with dropped packets and arrange for their retransmission. That obviously introduces latency in the reception of that particular packet (waiting for its retransmission), but in most systems the delivery of packets subsequent to that lost packet are likewise held up. Buffering of successfully-received packets after a loss, and delay of delivery until successful re-transmission of the lost packet is a characteristic of virtually all modern messaging systems. It is needed to make the message delivery order the same as the message transmission order (a requirement for many applications).

To minimize the impact of ordered delivery delay after packet loss, a designer needs to minimize the frequency of lost packets. The most effective way of minimizing packet loss is to prevent network congestion. One way to do this is to use TCP as the message transport. TCP uses very effective algorithms to detect and control network congestion. However, Latency-sensitive applications are often better served by other techniques, such as the 29West LBM product's multicast rate limits (see Section 3 for more on congestion).

Another technique for reducing average latency is to segment application data across several topics and use a separate transport session for each topic (where a session might correspond to a TCP connection, a UDP port, or a multicast address). A packet loss in one transport session will only add latency to that transport session. However, this can become impractical if the number of desired topics becomes very large (e.g. a separate topic per stock symbol).

The 29West LBM product introduces a new design for UDP-based transports where multiple topics can be mapped to a particular transport session, but order is not maintained across the whole transport session. Instead, each topic is ordered independently from other topics. Thus, a packet lost on a transport session will only add latency to the affected topic(s), while other topics on the same transport session will be unaffected.

For those applications that can tolerate out-of-order messaging, LBM also makes available arrival-order delivery. A lost packet will not delay the delivery of subsequently-received messages of the same topic. Instead, the application will continue to receive the latest data while LBM requests retransmission in the background. The application will receive the retransmitted data when it becomes available. (Note - as will be discussed below, there are other potential benefits to designing applications to be able to handle out-of-order data. We often encourage designers to at least give the option some thought.)