Before you use RTserver and the RTclient API, it helps to have an understanding of the concepts involved:
Many RTclients can simultaneously use the same computer, and RTclients on different computers can also send messages to each other. Two RTclients on a network may or may not want to receive each other’s messages. Projects provide a way to distinguish between groups of SmartSockets processes. A group of RTservers exchange messages only with other RTclients in the same project. For SmartSockets, a project is typically used to acquire, analyze, archive, and display data. A project is designated by a name, which must be an identifier. For example, one common project name is the name of your company’s product or application.
A project is a self-contained unit or partition that prevents unwanted messages from being sent to processes, in that RTclients in different projects cannot send messages to each other. Typically, an RTclient belongs to only one project, while an RTserver can provide publish-subscribe routing services for one or more projects. It is possible for an RTclient to connect to more than one project in the same RTserver or to multiple projects across RTservers. See Connecting to Multiple RTservers for more information.
For example, if RTclients are separately monitoring two factories, and the processes are running on the same network, two projects can be used to ensure that messages are not sent between the two separate factory projects. As shown in Figure 11, these projects could be named FAC1 and FAC2. 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 rtworks project, which may cause unwanted messages to be received.
Just as projects restrict the boundaries of where messages are sent, subjects can also further partition the flow of messages in a project. A subject is a logical message address that can be thought of as providing a virtual connection between RTclients. Subjects allow an RTclient to send a message to many processes with a single publish operation. Subjects are designated by a name, which can be any character string with a few restrictions (see Hierarchical Subject Namespace for details).
The following sections discuss the properties of subjects and the operations that can be performed with subjects. The programming aspects of these operations are described in detail in Using Subjects.
As described in Chapter 1, Messages, a message has both a sender property and a destination property. When the TipcConn* functions are used to send messages through connections, the sender and destination properties are by default not used. There are no predefined values for these properties when working with connections.
For RTserver and RTclient, though, subjects are used for these properties. When an RTclient is subscribing to a subject, it receives any published messages (sent to RTserver) whose destination property is set to that subject. For example, in a satellite project, you might partition messages by functional area — electrical power, thermal, pointing control, and so on. These areas are declared as subjects such as /elec_pwr, /thermal, /pt_ctrl. All messages pertaining to electrical power are constructed with the /elec_pwr subject as their destination property. Any RTclient interested in receiving messages destined for /elec_pwr subscribes to the /elec_pwr subject. This is also known as the publish-subscribe paradigm in that RTclients publish messages to specific subjects, and RTclients subscribe to subjects in which they are interested.
The core capability of SmartSockets publish-subscribe is conceptually similar to how electronic mail (email) mailing lists operate. A person sends an email message addressed to the list, and the message is delivered to all persons subscribed to the list. SmartSockets publish-subscribe is much more powerful, however, as it offers much higher performance, more dynamic capabilities, monitoring, and so on.
When two processes create any kind of peer-to-peer connection to each other, including through T_IPC_CONN connections, they need specific physical network addresses, such as for TCP/IP a node number and port number, to begin communicating. If a process wants to send a message to many other processes, it needs first to know the physical network addresses of the other processes, and then to create connections to all of those processes. This kind of architecture does not scale well, as configuration is complicated and tedious. The RTserver and RTclient architecture’s use of subjects for message addresses allows an RTclient to simply send the message with a subject as the destination property, and RTserver takes care of routing the message to all RTclients that are subscribed to that subject. RTclient can start or stop subscribing to a subject at any time, which allows RTclient to control the quantity of incoming data as desired.
To provide greater flexibility and scalability for large projects, SmartSockets subject names are arranged in a hierarchical namespace much like UNIX file names or World Wide Web Universal Resource Locators (URLs). This hierarchical namespace allows for large numbers of subject names to be created with similar but not conflicting names, such as /system/primary/elec_pwr and /system/backup/elec_pwr, and also for many powerful operations, such as publish-subscribe with wildcards, to be performed. Small SmartSockets projects can be built without requiring large amounts of complexity, and large projects can also be more easily built with these hierarchical subject names.
A hierarchical subject name consists of components laid out left-to-right separated by forward slashes (/). Each component can contain any other non-slash characters except asterisks (*) and the ellipsis (...), both of which are used for wildcards in publish-subscribe. Examples of hierarchical subject names include /system, /system/primary/eps, /system/backup/eps and /nodes/workstation.tibco.com/support.
Generally, a subject name is unlimited in length. However, each individual component of a hierarchical subject name is limited to 63 characters in length, due to restrictions imposed when certain commands, such as subscribe, unsubscribe, or setopt, are processed.
An absolute subject name starts with a forward slash (/). SmartSockets allows for greater flexibility and easier configuration by allowing any combination of absolute and non-absolute subject names used in a project. All non-absolute subject names automatically have the value of the option Default_Subject_Prefix prefixed to them so as to create a fully qualified name for the hierarchical subject namespace. This allows projects written using non-absolute subject names to be easily moved from one area of the hierarchical subject namespace to another, such as from /company/new-york to /company/san-francisco, by simply changing the value of the option Default_Subject_Prefix. Both RTclient and RTserver have the option Default_Subject_Prefix. If the option is not set in the RTclient (that is, has the value unknown), the RTclient inherits the Default_Subject_Prefix from the first RTserver it connects to.
 |
From this point on, any non-absolute subjects used in examples should be treated as if they have Default_Subject_Prefix prefixed to them when they are used by RTclient.
|
Using wildcards (* or ...) in subjects is much like using wildcards for file names in an operating system command line. The asterisk wildcard operates much as it does on Windows, UNIX, OpenVMS, or MVS ISPF environments. It can be used for an entire subject name component or as part of a more complicated wildcard containing other characters, such as foo*bar. A wildcard component using an asterisk (*) never matches more than one component, such as foo*bar does not match foo/bar.
The ellipsis wildcard operates much as it does on OpenVMS, where it matches any number of levels, including zero levels, of components. It must be used as an entire component (that is, auto... is not a wildcard). Multiple wildcards can be used in a subject name, such as /a*b*/.../d. The following table shows several wildcarded subjects with examples of matches and mismatches.
When a message is published, if multiple subscribed-to subjects match, only one copy of the message is delivered to each subscribing RTclient. An example use of wildcard subscribes is to subscribe to a wildcard subject such as /stocks/auto/... so as to receive all messages published to the non-wildcard subjects that match. An example use of wildcard publishes is to publish to a wildcard subject such as /stocks/auto/... so as to send messages to all subscribers of the non-wildcard subjects that match. An easy way to publish a message to all RTclients in the entire project is to publish the message to the subject "/...". RTserver caches the matching values for wildcard subjects so that potentially time-consuming wildcard matching is not needed for each message it routes.
There is some overlap between projects and hierarchical subjects in that both can be used to partition publish-subscribe, but projects should be used when it is certain that no intercommunication should be allowed. Projects are also useful for having the same subject names simultaneously in both a testbed application and a production application.
For more details on using hierarchical subjects in large-scale projects, see Dynamic Message Routing.
RTclient can also monitor many things about a subject, such as:
This is useful for monitoring process activity. RTclient can start or stop monitoring a subject at any time. Monitoring subjects is discussed in Chapter 5, Project Monitoring, and is shown in detail in the example code in Running an RTclient With a Hot Backup.
Each RTclient has a unique subject that is always used as the sender property of a message sent to RTserver. When an RTclient first connects to RTserver, it automatically subscribes to its unique subject. RTserver does not allow multiple processes to have the same unique subject. By using the unique subject as the sender property, an RTclient that receives a message can easily determine who sent the message and also what subject to use to reply to the message if needed. The option Unique_Subject is used to specify the unique subject of an RTclient. The default value for Unique_Subject is _Node_Pid, where Node is the network node name of the computer on which the process is running, and Pid is the operating system process identifier of the process.
The Unique_Subject option is also used to configure GMD and monitoring. For GMD, Unique_Subject is used to construct the pathnames for GMD disk files (see Configuring GMD for details). For monitoring, Unique_Subject is used to identify all RTclients and RTservers.
Because subjects are an integral part of publish-subscribe communication, several standard subjects provide a way to consolidate some useful subject-based operations. The standard subjects are operated on as a set. The standard subjects are:
These operations can be performed in a single step on the standard subjects:
User-defined subjects that are not listed in the Subjects option may also be used at any time by using API functions, such as TipcSrvSubjectSetSubscribe, or commands, such as subscribe, through a control channel.
While connections provide a means for two processes to exchange messages, connections by themselves do not scale well to many processes. RTserver fills this void and expands the capabilities of connection-based message passing; RTserver is a publish-subscribe message router that uses connections to make large-scale distributed IPC easier. RTserver also has advanced GMD and monitoring function.
RTserver runs as a background process (on OpenVMS and Windows this is known as a detached process, on MVS it can be an STC or started task) without an interactive command interface. You can start RTserver manually from the operating system prompt, or it can be started automatically when an RTclient first tries to connect to RTserver on most platforms.
To start and use an RTserver, you must have a license for that RTserver. The license needs to be added to the license file, talarian.lic, in the standard directory. Or you can brand the RTserver using the rtbrand command. The information in the license file takes precedence over any branding that you might do. If you are upgrading an existing license to add more RTservers or to change the type, such as from a single threaded to a multi-threaded RTserver, you must add the new license information to the license file or else re-brand the RTservers. See the TIBCO SmartSockets Installation Guide for information on the license file and on branding.
In addition to routing publish-subscribe 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 published are routed between RTclients on the same node, then the use of multiple RTservers can reduce the consumption of network bandwidth, because processes on the same node can use the non-network local IPC protocol. See Dynamic Message Routing for more information on multiple RTservers.
Most project and subject information is kept in RTserver. RTserver maintains a table of some RTclients (including warm RTclients, which are discussed in Warm RTclient in RTserver), a table of all projects, and a table of some of the subjects in each project. These tables contain information about RTclients subscribing to a subject, the information being monitored by RTclients, and which other RTservers have RTclients subscribing to a subject. Each RTserver knows only the information necessary for its own publish-subscribe operation. Each RTserver does not know about all RTclients. This greatly increases the scalability of SmartSockets publish-subscribe projects. These scalability features are discussed in more detail in Dynamic Message Routing.
When RTserver is running but not being used, it uses very little CPU time. The amount of memory used by RTserver varies depending on the number of other (RTserver and RTclient) processes RTserver has connections to and the number of messages that RTserver has buffered to be routed to other RTservers and RTclients. RTserver also deallocates memory for defunct subjects (a subject becomes defunct when no more processes are subscribed to it) so that its memory consumption does not grow over long periods of time. For more information, refer to Starting and Stopping RTserver.
This section provides an example of how a message originating from a single RTclient is published (sent) to RTserver and routed to all RTclients subscribing to a subject. In this example, there are three RTclients: RTclient1, RTclient2, and RTclient3. Each of these RTclients is connected to the same RTserver. RTclient2 and RTclient3 are both subscribed to the /sb1 subject. If RTclient1 publishes a message to the /sb1 subject, this sequence of events occurs:
Figure 12 shows this flow of the message through RTserver. Note that if RTclient1 also subscribes to the /sb1 subject prior to publishing the message to the /sb1 subject, it too receives the message from RTserver.
RTclient can monitor many things about RTserver. Some of these are listed below.
This is useful for monitoring process activity. RTclient can start or stop monitoring an RTserver at any time. Monitoring RTserver is discussed in Chapter 5, Project Monitoring.
An RTclient is a process that is connected to an RTserver as a client. Usually, each RTclient has one T_IPC_CONN connection to one RTserver, because an RTclient cannot have more than one global connection at a time. In rare instances where an RTclient requires multiple connections to RTservers, that RTclient can use multiple RTserver connections. These are described in more detail in Connecting to Multiple RTservers.
An RTclient can send messages, receive messages, and create callbacks using the global connection just as it would any other connection. The publish-subscribe message routing capabilities of RTserver are transparent to an RTclient, and subjects provide a virtual connection between RTclients.
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 an RTserver is not already running, an RTclient can start an RTserver. If an unrecoverable error (such as a network failure) occurs, the RTclient can restart the RTserver.
All of the capabilities of the TipcConn* functions are available to an RTclient, including most of the connection callback types (all except encode and decode). 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. An RTclient using GMD can even crash, be restarted, and recover from most network failures.
Because of some extra function in RTclient, you do not use the TipcConn* functions, but instead use a parallel set of TipcSrv* functions. Almost every TipcConn* function has an equivalent TipcSrv* function. Figure 13 shows the relationships among the various IPC functions.
See Working With RTclient for a full discussion of the TipcSrv* functions.
RTclient can monitor many things about any RTclient, such as:
This is useful for monitoring process activity. RTclient can start or stop monitoring an RTclient at any time. Monitoring RTclients is discussed in Chapter 5, Project Monitoring.
The publish-subscribe architecture of RTserver and RTclient is implemented using SmartSockets peer-to-peer connections and takes advantage of all the features that connections have to offer. Sometimes it can be unclear when to use a connection to send and receive messages, and when to use RTserver to send and receive messages. A general guideline is to use just connections when communicating between exactly two processes (that is, a peer-to-peer situation) and to use RTserver otherwise. These scenarios illustrate this guideline in detail:
Keep in mind that a process can use as many connections as it wants and can mix TipcConn*, TipcSrv*, and TipcMon* functions as needed.
RTclient and RTserver can be controlled using both options and API functions. Throughout this chapter, both approaches are documented as appropriate. All RTclient and RTserver options are documented in Chapter 8, Options Reference. The API functions are documented in the TIBCO SmartSockets Application Programming Interface reference.
|
TIBCO SmartSockets™ User’s Guide Software Release 6.8, July 2006 Copyright © TIBCO Software Inc. All rights reserved www.tibco.com |