Replacing SmartSockets with LBM

January 12, 2006


Table of Contents
1. Introduction
2. SmartSockets Transition
3. Technical Details

This document contains information for developers converting their applications from TIBCO® SmartSockets to 29West Latency Busters® Messaging (LBM), a fast, efficient, and lightweight messaging system targeted specifically at high performance systems with demanding applications.

TIBCO and SmartSockets are trademarks of TIBCO Software, Inc.


1. Introduction

High-performance messaging systems, like TIBCO SmartSockets, have been a tremendous boon to application developers by giving them a publish/subscribe model of network communications, as well as hiding many of the platform-specific details of the networking API. These systems were designed to take good advantage of the network hardware that was available at that time.

Those developers with the most demanding requirements may benefit from improved messaging performance for their latency-sensitive or high-throughput applications. 29West Latency Busters Messaging (LBM) provides the same functionality as traditional messaging systems, but uses a design which eliminates central servers and daemon processes. This kind of direct communication model offers significant efficiency gains, with some customers seeing a 10-fold performance improvement over traditional messaging systems. Naturally, the measurements made by a particular customer are dependent on many factors, which is why we offer a risk-free software evaluation so that you can measure the performance of your system, in your network, running your applications. In addition, 29West offers integration services for coding, tuning, and roll-out support.

The LBM API is not drop-in compatible with SmartSockets. However, since the important functionality is present in both, the SmartSockets transition is fairly straight-forward. The rest of this document points out the areas that require attention.


2. SmartSockets Transition

If you're considering replacing SmartSockets with LBM, be aware that it can be done as part of a software evaluation with no risk. Converting SmartSockets applications to LBM is not complicated. It generally takes under a month and consists of the following stages:

  1. Conduct a binary evaluation to set a baseline of LBM performance on your network. Use the documentation, including the source code for the binary performance tools, to familiarize yourself with the LBM API.

  2. Examine your application and identify all SmartSockets API calls. Many developers have had good success abstracting these calls into a separate application sub-layer. There is no need to write a completely general abstraction layer that maps every SmartSockets feature to the corresponding LBM feature; designing an abstraction layer that is specific to your application's needs is much simpler and generally takes less than a week. This concentrates the SmartSockets-specific code into a relatively short and uncomplicated module, which can be tested prior to the introduction of LBM. Then an equivalent LBM-specific layer can be written and swapped in. Past experience suggests that the equivalent LBM layer can be written in about a week.

  3. For publish/subscribe applications, choose the appropriate LBM transport for each topic. For latency-sensitive applications, we recommend LBT-RM, which provides latency-bounded reliable multicast. This provides better performance and network stability than SmartSockets transports (TCP and PGM).

  4. For high-bandwidth applications, topics can be assigned to multiple transport sessions, either manually or automatically, to reduce CPU load and improve network utilization.

  5. LBM offers many configurable options that allow fine-tuning its performance for the characteristics of your application and network. This is typically performed after the code is functionally working. 29West provides extensive support to pinpoint performance bottlenecks and address them.


3. Technical Details

Although the general procedure for converting SmartSockets applications to LBM is straight-forward, there are some specific issues that may require extra attention.


3.1. Message Structure

SmartSockets messages often contain structured data. A message structure can contain multiple fields, often two fields per data element with the first being a string that names the element and the second being a typed value. The typing of the value (e.g. STR, INT2, INT4, REAL8, BOOL, etc) allows SmartSockets to marshal the data for different platforms (e.g. byte order differences between SPARC and X86). This relieves the programmer from some of the platform-specific details at the expense of some execution time and complexity.

SmartSockets messages must be created and deleted at run-time.

LBM simplifies this data model by treating application message data as simple collections of uninterpreted bytes. A single buffer can be sent with the lbm_src_send() function, or a group of buffers can be sent with lbm_src_sendv(). If binary data must be passed between differing machine architectures, the programmer can select the marshalling technique most appropriate to his application (e.g. representing all numeric data with ASCII, using standard functions like ntohs() and htonl(), or even a heavy-weight infrastructure like XDR/rpcgen (the marshalling system used by RPC).

The application is responsible for memory management of the message buffers, and can be done in whatever method is most appropriate (static or automatic arrays or structures, malloc/free, new/delete, etc.).


3.2. Configuration

SmartSockets configuration is managed by setting properties. There is one global set of properties that is typically set once during initialization, and remains constant for the application's entire run. The application has some properties that it can set, and the server has properties of its own.

LBM has a more flexible way of managing its configuration. Options come in different "scopes" (context, source, receiver, and event queue). This allows the application to, for example, use one transport protocol with one source (sender) and a different transport protocol for a different source.

There are any number of ways to migrate a SmartSockets application's initialization to LBM. One approach consists of setting the desired options in a set of attribute structures during initialization, and keeping them handy so that senders and receivers can be created with the desired options.


3.3. Portability

SmartSockets provides a set of data types and wrapper functions intended to provide the programmer with a degree of platform and OS portability, not only for the SmartSockets API itself, but also for normal platform-specific OS and run-time functions. For example, TutThreadCreate() creates a thread in a portable way. TutFOpen() replaces fopen(). TutOut() replaces printf(). Etc.

The LBM API is itself portable, but the programmer must take normal precautions to make the application code as portable as is desired. There are several standard software packages available, like APR, which are designed to provide a robust and complete platform for portability.


3.4. Projects

A SmartSockets project is basically a name space that allows different unrelated groups of clients to reuse topic names without interference. Clients from project A cannot normally exchange messages with clients from project B, even if they use the same topic names.

LBM allows similar functionality through the use of the context object; a program can make use of multiple contexts simultaneously. By using different addresses for topic resolution, different groups of hosts can be isolated from each other, and other hosts (e.g. gateways) can communicate with multiple groups.


3.5. Monitoring

SmartSockets provides the RTMon command to provide the programmer/operator with information on the operation of the SmartSockets network. This command communicates with the SmartSockets server to get the information.

Since LBM does not have a central server, there is no central location where this information is being collected. LBM therefore does not provide a command, but it does provide API functions that each source and receiver can use to obtain operational statistics. One approach to network management would be for all processes to send their statistics to a common topic, which a monitoring program could read and make available in whatever manner is appropriate (e.g. web service, private SNMP MIB, etc.).


Copyright 2005 - 2006 29West, Inc.