6. Message Routing

Many application developers want the power and flexibility of a generalized topic-based publish/subscribe messaging paradigm ("pub/sub"). Senders of data do not have to know how many or where the receivers are, and receivers do not have to know how many or where the senders are. The messaging system is responsible for figuring out where messages should go.

One common method of accomplishing this is to have a centralized server with which senders and receivers are required to register. In most server-based messaging systems, that centralized server actually performs the routing of each data message (e.g. TIBCO® SmartSockets™, Sonic JMS, etc.). This application-level message routing can be simple to implement, but for latency-sensitive applications it often introduces unacceptable delay since each message needs to be received, processed, and forwarded to the final destination.

One common method for avoiding these delays is to use UDP multicast as the message transport. This tends to fit well with the pub/sub paradigm since a message need only be sent once onto a given network and all interested machines will receive the message. However, it has only been relatively recently that multicast-enabled routers have been widely deployed. Before then, messaging systems needed to use application-level gateways to get multicast messages from one network to another (e.g. TIBCO RV™). Once again, undesirable latency is introduced by these gateways.

These days it is generally better to make use of multicast-enabled routers to get messages where they belong. Modern routers can do this routing at wire speed, eliminating the user/kernel transitions of application-level servers or gateways. Some designers run into resistance from network administrators to enable multicast routing because it requires greater care and learning to design, configure, and operate the networks. For example, since multicast traffic does not have automatic congestion control built into the kernel, a lack of careful design can lead to severe congestion on the network. When multicast routing is enabled, that congestion can spill over onto all the networks of an organization. However, for latency-sensitive applications, the added cost and effort of careful design and operation can pay large benefits.

The 29West LBM product normally does not make use of application-level servers or gateways, relying instead on modern network hardware to route messages. For organizations that are not willing or able to enable multicast routing, LBM can make use of either TCP or unicast UDP for message transport. However, LBM's rate limits provide very good mechanisms to prevent severe congestion, removing some of the resistance to enabling multicast routing. In addition, LBM allows the designer flexibility in segmenting topic spaces across different multicast addresses, allowing only that traffic that needs to be communication across networks to be routed. Finally, for those cases when multicast routing is inappropriate, a gateway function is currently under development to interconnect multiple multicast networks over lower-speed WAN links.