Available Monitoring Information

As described in the previous chapter, the publish-subscribe architecture of SmartSockets allows RTclient processes 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 and naming services. These additional services help you, as a developer (and those ultimately responsible for monitoring the deployed application), 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. These are some of the kinds of information available:

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, prefixed with T_MT_MON_. (For brevity, the T_MT_ portion is omitted from this point on.) The fields of these monitoring message types contain the information the RTclient is interested in.

There is no monitoring available for peer-to-peer connections or for programs that do not use the SmartSockets API or C++ Class Library.

Monitoring is built into SmartSockets. No user-defined code is needed to support monitoring in an RTclient. Just as RTserver and RTclient are layered on top of the functionality of connections, monitoring is layered on top of the RTserver and RTclient architecture.