Note: There are two versions of each method in this class. When multiple RTserver connections are created by the createSrv method, then the version that requires a TipcSrv object as its first argument should be used. If the RTserver connection was created using the Srv property, then use the version that does not take a TipcSrv object as its first argument.
The publish-subscribe architecture of SmartSockets allows RTclient process to easily send messages to each other, independent of where they reside on the network. In addition to enabling easy development of distributed applications, RTserver, RTmon, and RTclient processes also have monitoring capabilities built in. These additional services help to examine detailed information about your project, as well as determining where processes are located in your network.
From within an RTclient, hundreds of pieces of information can be gathered in real time about all parts of a running SmartSockets project, including:
This information can be either polled once to provide a one-time snapshot
of information or watched to provide asynchronous updates when changes occur.
A monitoring request can specify either a specific object or all objects
matching a wildcard scope filter. The information is delivered to the
requesting program in standard message types TipcMt_Fields.MON_*
The fields of these message types contain the information the RTclient is
interested in.
All monitoring of a SmartSockets project goes through RTserver. Typically, a request for particular information is sent to RTserver, then RTserver proceeds in one of these ways:
To initiate a monitoring request in an RTclient, call one of the functions
in the TipcMon class. This sends a message of type
TipcMt_Fields.MON_*_POLL_CALL or
TipcMt_Fields.MON_*_SET_WATCH to the RTserver. The information is
returned to the program by an RTserver using a
TipcMt_Fields.MON_*_POLL_RESULT or TipcMt_Fields.MON_*_STATUS
message. When the information returns, an RTclient message process callback
(created with addProcessCb can be used
to process the message.
The ss.monitor_scope option specifies the level of interest for SmartSockets monitoring in those monitoring categories with no parameters (such as RTclient names poll) or an RTclient or RTserver parameter of ALL (such as subject subscribe watch). ss.monitor_scope acts as a filter that prevents a large project from overloading a monitoring program. The default is "/*", which matches all subject names at the first level of the hierarchical subject namespace. All monitoring information is enabled (all filtering is disabled) if ss.monitor_scope is set to "/...", which matches all names. The value "/..." should be used with caution on large projects, as this gathers monitoring information for the entire project, and may cause noticeable peformance degradation.
Polling for information allows you to receive a one-time snapshot of information. Polling can be done at regular time intervals by issuing poll requests repeatedly. All polling of a project goes through RTserver. Typically, a request for particular information is sent to RTserver, then RTserver retrieves the information from its internal tables, from other RTservers, or from RTclients and sends it back to the requesting program.
When the results of a poll are returned in a
TipcMt_Fields.MON_*_POLL_RESULT message, the message is processed
in one of these two ways:
Typically, after performing a one-time poll for information, the program blocks and waits for the result before continuing. An example of this is to find out if any RTclients are subscribing to a subject before sending a message. When polling often, or watching for information, using callbacks is usually the preferred method, as it is unclear when the monitoring results may be returned to the program.
Watching information is very different from polling. When watching information, the RTclient that initiated the watch is notified asynchronously, through a message, whenever the item(s) of interest changes. All watching of a project goes through RTserver. Typically, a request to watch particular information is sent to RTserver. RTserver then notifies the process holding the information (the same RTserver, a different RTserver, or an RTclient) that a program is interested in watching the specified information. Then, whenever the information changes, the process holding the information sends it back to the requesting program in a message. Unlike polling, which is a one time request for information, watching causes status messages to continue to be sent until watching is turned off for that particular information.
To set up watching in your program, you set the watch status for the type
of information of interest to true. In a similar fashion,
watching is turned off by setting the watch status to false.
When the results of a watch are returned in a
TipcMt_Fields.MON_*_STATUS message, the message can be processed
using an RTclient message process callback (created with
addProcessCb). Using callbacks to
process the status messages that are returned as the result of a watch being
enabled is the recommended method for processing watch results. The main
reason for this is that the messages arrive asynchronously. It is often
unclear as to when or how often the information may change.
For a list of all members of this type, see TipcMon Members.
System.Object
TipcMon
Namespace: TIBCO.SMARTSOCKETS Namespace
Assembly: TIBCO.SS.dll
TipcMon Members | TIBCO.SMARTSOCKETS Namespace