Major Components of TIBCO SmartSockets


Messages	are the packets of information sent between processes.
Message types	are the templates that describe the data part of a message.
Connection	is an endpoint of a communication link used to send and receive messages between two processes.
RTserver‘	is a process that extends the features of connections to provide transparent publish-subscribe message routing among many processes.
RTclient	is any program, user-defined or TIBCO SmartSockets client, that connects to the RTserver and accesses its services.

Messages

Within a TIBCO SmartSockets application, interprocess communication occurs through messages. A message is a packet of information sent from one process to one or more other processes providing instructions or data for the receiving process. Messages can carry many different kinds of information, including:

graphical commands, such as changing the color of an object or popping up a view on a specified display

commands to a process’s command interface

XML strings

images or audio

user-defined binary data, such as actual C data structures

process information, such as the names and the number of processes currently subscribed to a particular subject

IPC traffic information, such as how many messages are currently in the message queue of a program

executable programs

All of these different kinds of messages are classified by message types. For example, numeric variable data is typically sent in a NUMERIC_DATA type of message, and an operator warning is typically sent in a WARNING type of message. A TIBCO SmartSockets application can use both the standard message types provided with TIBCO SmartSockets, as well as user-defined message types.

Message Composition

A message is composed of the header and the data. The header contains properties that specify control information about the message. Examples of TIBCO SmartSockets message properties are the message sender, destination, type, priority, and delivery mode. The data contains the information you wish to send, and is usually the largest part of the message. The message type property defines the structure of the data part of the message.

Working with Messages

Typically, when building a TIBCO SmartSockets application, there are three steps required when constructing a message:

Set the properties of the message.

Append fields to the message data.

The same message can be used many times, changing only the data part of the message or a property such as the destination. There are many different types of fields that can be appended to a message’s data. These field types include three sizes of integers, character strings, three sizes of real numbers, and arrays of the scalar field types such as an array of four-byte integers. Messages can even be used as fields within other container messages; this allows operations such as large transactions to be represented with a single message.

Once a message is constructed, it can be sent to another process through a connection or published to a subject to be delivered to multiple processes.

Message Types

As described earlier, each message has a type property that defines the structure of the data property of the message. A message type can be thought of as a template, such as class, for a specific kind of message, and each message can be considered an instance of a message type. For example, NUMERIC_DATA is a message type with a pre-defined layout requiring a series of name-value pairs, with each string name followed immediately by a numeric value. To send numeric data to a process, the sending process constructs a message that uses the NUMERIC_DATA message type. A message type is created once and is then available for use as the type for any number of messages.

TIBCO SmartSockets provides a large number of standard (predefined) message types you can use. When a standard message type does not satisfy a specific need, you can create your own user-defined message types. Standard and user-defined message types are handled in the same manner. Once the message type is created, messages can be constructed, sent, received, and processed through a variety of methods.

Connections

All messages are transmitted between processes through connections. A connection is an endpoint of a direct communication link used to send and receive messages between two processes. The two processes, called peer processes, share the link. However, each process has a unique endpoint that it can manipulate independently. Connections can operate on messages in many different ways. Additional features of connections include:

Connections can use one of several different interprocess communications (IPC) protocols to transfer messages: TCP/IP or local (non-network).

Connections can execute callback functions at various points while operating on messages to perform user-defined actions.

Connections can detect many kinds of network failures and take steps to recover from these failures.

Connections can be used for request-reply communication by sending and receiving messages.

Connections can send messages with or without guaranteed message delivery (GMD). GMD stores copies of messages in files for total recovery from network failures.

Connections are safe to use in multithreaded programs.

Connection Composition

A connection is composed of several parts, or properties. These properties are too numerous to describe here, but are described in the connections chapter of the TIBCO SmartSockets User’s Guide. The major components of a connection are:

a communication link to another process (used to transmit messages)

several areas of memory for flexible buffering of incoming and outgoing messages

a prioritized message queue for incoming messages

callbacks (user-defined functions) that can be executed when a message is read in, sent out, processed, queued, and so on

properties for controlling how often to check for possible network failures

Advantages of Connections Over Sockets

Connections are implemented using sockets and take advantage of all the features that sockets have to offer. Connections also have many features that make them easier to use and more powerful than sockets:

Connections have additional data buffers that expand to hold large numbers of messages.

Connections have prioritized message queues.

Connections handle differences between different socket implementations; for example, the Windows NT 4.0 and Solaris 2.5.1 socket APIs are not 100% compatible.

Connections automatically unpack messages read from the byte stream of a socket.

Connections have callbacks to execute user-defined functions when certain operations occur.

Connections automatically convert messages sent between different types of computers.

Connections can detect and recover from network failures.

Connections can perform request-reply interactions by sending and receiving messages.

Connections have guaranteed message delivery, which enables total recovery from network failures.

Connections can be used safely in multi-threaded programs.

Publish-Subscribe

While connections allow two processes to send messages to each other, TIBCO SmartSockets publish-subscribe architecture uses the RTserver and RTclient to allow many processes to communicate with each other. An RTserver process routes messages between RTclient processes. A key feature of TIBCO SmartSockets is the ability to distribute RTserver processes and RTclient processes anywhere over a network. Different processes can run on different computers, taking advantage of all the computing power a network has to offer. Processes can be dynamically started and stopped while the system is running.

The functions of RTserver and RTclient are layered on top of connections and messages, but adds greater functionality and ease of use:

RTserver and RTclient simplify setup and control through options that require no programming.

RTserver can partition a group of RTclients into a project.

RTserver and RTclient use logical addresses called subjects for the sender property and destination property of messages.

RTserver and RTclient use a publish-subscribe communications model, allowing a program to send a message to multiple receivers with a single operation.

Messages can be dynamically routed through a network of RTservers using a shortest path algorithm.

Multiple RTservers can distribute the load of message routing.

Messages can be uniformly distributed to a series of RTclients through load balancing.

An RTclient can automatically start RTserver, automatically restart RTserver, and even continue running when RTserver is temporarily unavailable.

Through RTserver, program and IPC traffic information can be monitored by an RTclient and also through the RTmon graphical development interface (GDI).

RTserver and RTclient Composition

Before you use RTserver and the RTclient API, it helps to have an understanding of the concepts involved. The RTserver and RTclient architecture and the major concepts that you need to understand are:


RTserver	is a process that extends the features of connections to provide transparent publish-subscribe message routing among many processes.
RTclient	is any program, user-defined or TIBCO SmartSockets client, that connects to the RTserver and accesses its services (under this definition RTmon can be considered an RTclient).
Project	is a group of RTservers and RTclients working together.
Subject	is a logical address for a message; an RTclient subscribes to subjects (registers interest in). An RTclient also publishes messages to subjects (sends messages to).
Monitoring	allows you to examine detailed information about your project in real time (not shown in Figure 1).

Projects

A TIBCO SmartSockets project is a group of RTclients working together with one or more RTservers to perform some set of tasks as part of a specific system. Within a project, processes can communicate with other processes on the same machine or over the network. RTclient processes in different projects cannot send messages to each other.

An RTclient belongs to only one project. An RTserver does not belong to any project, but can provide message routing services for one or more projects. You can think of a project as a firewall that prevents messages from being dispatched outside the specified process group.

Project FAC1 has processes C1, S1, S2, and C2.

Project FAC2 has processes C3, S1, C4, S2, and C5.

Both RTserver S1 and S2 are used by both projects.

RTclient C1 cannot send messages to C3, C4, or C5 because they are not in the same project.

A message published (sent) to the /sb1 subject in project FAC2 is received by both RTclient C4 and C5.

For example, in Figure 1, the RTclients are running on the same network and are each monitoring two factories, so the projects named FAC1 and FAC2 are used to ensure that messages are not sent between the two separate projects. The option Project is used to specify the project to which an RTclient belongs. The default value for Project is rtworks. You should always set this option to prevent becoming part of the default project, which may cause unwanted messages to be received.

Subjects

Just as projects restrict the boundaries of where messages are sent, subjects can further partition the flow of messages within a project. A subject is the fundamental concept used in TIBCO SmartSockets publish-subscribe communication services. A subject is a logical message address that can be thought of as providing a virtual connection between RTclients.

When an RTclient has subscribed to a subject, it gets any messages sent to an RTserver whose destination property is set to that subject. For example, in a stock trading application, you might partition messages by stock market sectors — computer stocks, automobile stocks, financial stocks, and so on. These areas would be declared as subjects such as /stocks/computer, /stocks/auto, /stocks/financial. All messages pertaining to computer stocks are constructed with the /stocks/computer subject as its destination property. Any RTclient interested in receiving messages published to /stocks/computers subscribes to the /stocks/computer subject. This is also known as the publish-subscribe communications model in that the RTclients publish messages to a specific subject, and the RTclients subscribe to subjects in which they are interested.

Without TIBCO SmartSockets publish-subscribe services, when two processes create connections to each other, they need protocol-specific network addresses to begin communicating. For example, TCP/IP needs a node name and port number. If a process wants to send a message to many other processes, it first needs to know the protocol-specific network addresses of the other processes, and then creates a connection to all of those processes. This kind of architecture does not scale well, as configuration is complicated and tedious. The publish-subscribe architecture uses subjects for message addresses to allow an RTclient to simply send the message with a subject as the destination property, and an RTserver takes care of routing the message to all RTclients that are receiving that subject.

RTserver

While connections provide a means for two processes to exchange messages, connections by themselves do not scale well to many processes. An RTserver fills this void and expands the capabilities of connection-based message passing. An RTserver is a powerful message router that uses connections to make large-scale distributed IPC easier.

In addition to routing messages between RTclients, multiple RTservers can route messages to each other. Multiple RTservers can distribute the load of message routing. If a project is partitioned so that most of the messages being sent are routed between processes on the same node, then the use of multiple RTserver can reduce the consumption of network bandwidth (processes on the same node can use the non-network local IPC protocol).

RTclient

An RTclient is a process that is connected to an RTserver as a client. Each RTclient has a single global connection, either to an RTserver for unicasting or to an RTgms process for multicasting. An RTclient can send messages, receive messages, create callbacks, and so on, using this connection, just as it does any other connection. The message routing capabilities of RTserver are transparent to an RTclient, and subjects provide a virtual connection between RTclients. The RTclient can also have multiple RTserver connections, in addition to the global connection. See the TIBCO SmartSockets User’s Guide for more information.

An RTclient can have complete control over when it creates a connection to RTserver, or it can automatically create the connection when it is first needed. If RTserver is not already running, an RTclient can start RTserver, and it can restart RTserver if an unrecoverable error occurs (such as a network failure). An RTclient can partially destroy its connection to RTserver and temporarily continue running as if it were still connected, or an RTclient can fully destroy its connection to RTserver and continue as if it had never been connected at all.

Connections Versus RTserver and RTclient

The architecture of RTserver and RTclient is implemented using TIBCO SmartSockets connections and uses all the features that connections have to offer. Both connections (peer-to-peer) and RTserver (client-server) can be used within the same program.

Sometimes it is unclear whether to send and receive messages using a connection or using an RTserver. A general guideline is to use only connections when performing very high-speed communication between exactly two processes (a peer-to-peer situation) and to use an RTserver otherwise. These scenarios illustrate this guideline in detail:

Use connections when only two processes need to communicate (subjects are unnecessary). A single connection is faster and easier to configure, and the messages sent on this connection do not mix with the messages sent to and received from connections to RTserver. You may use RTserver to locate the ends of the connections, and then establish a peer-to-peer connection between the two programs for very fast IPC.

Use RTserver when there are a varying number of processes involved in the task. For example, if a process needs to communicate equally well with 1, 10, or 20 other processes, using RTserver instead of connections simplifies the development required.

TIBCO SmartSockets includes a robust API and class library for monitoring IPC and process information in an application. This API cannot monitor direct, peer-to-peer communication through connections.

RTmon

RTmon enables you to monitor and manage your entire distributed project. You can access the RTmon with the RTmon Graphical Development Interface (GDI) or through a built-in command-oriented interface called the RTmon Command Interface (CI).

The RTmon GDI is a graphical point-and-click interface that is intuitive and easy to use. The RTmon provides an assortment of tools for viewing your project, including graphical trees, browsers, graphical charts, and watch windows. The content and functionality of the RTmon GDI are identical between the Windows and Motif platforms.

The RTmon CI is a command-based interface, allowing you to monitor and manage your project with a command prompt.

The RTmon Main window presents an animated graphical tree of your project, with nodes in the tree representing RTclients, the subjects to which they are subscribing, and the RTservers running in the project. As changes occur, such as a process leaves the project, the tree is updated in real time. The Watch Server Connections window graphically displays the RTservers in your project and their connection topology. You can use this window to monitor the load on your RTservers and their connections using a variety of different metrics. RTmon even allows you to look at individual messages and their contents as they are passed from program to program.

One of the principal features of RTmon is that it is non-intrusive. You can monitor, debug, and log information in your project without changing the running processes. RTmon also provides real-time system usage information on processes, such as CPU and memory resources. This is useful for stopping a process that is using excessive system resources.

	The RTmon GDI has been deprecated and may be removed in a future release.

Note that the programs appearing in Lessons 1 through 4 in this tutorial do not allow monitoring and debugging using the RTmon GDI. If you attempt to use the RTmon GDI while working on the programs presented in these lessons, you may receive an error message. In Lesson 5: Monitoring, you use RTmon to monitor and debug some of the applications you write.