| Replacing SmartSockets with LBM | ||
|---|---|---|
| Prev | ||
Although the general procedure for converting SmartSockets™ applications to LBM is straight-forward, there are some specific issues that may require extra attention.
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.).
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.
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.
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.
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.