dsTest broadcasts notifications regarding test events and system events to clients that are eligible to receive them. In most cases all that is needed is to issue a register command for the desired type of notification and a deregister command to discontinue the notifications. Exceptions are noted below. If you're using the RESTful API, notifications will be queued up until they are retrieved with a GET request.
Interval notifications are generated when the reporting interval expires or when the reporting interval has been changed. In addition to conveying the interval ID and time stamp, this notification also contains the number of errors that have been reported during the test. dsClient Desktop registers for these notifications when you use one of the live reports.
Threshold notifications are generated when a minimum or maximum OM threshold you defined has been crossed.
Status Change notifications are generated when the status of a node changes - when it starts, stops, connects to a peer, or disconnects from a peer. dsClient Desktop registers for these notifications when you transmit your test configuration and the notifications are displayed along with other responses received from dsTest.
Configuration Update notifications are generated when a loaded configuration has been modified with a command.
SmartMonitor notifications track a subscriber's path through your SmartEvents state machine. In addition to registering for notifications, you must execute a SmartMonitor command to specify the subscriber(s) to be monitored. A notification is generated as the subscriber transitions from one state to another, and it identifies the event that triggered the transition. dsClient Desktop uses these mechanisms to implement its SmartMonitor feature.
Command Event notifications are generated when commands that affect the life cycle of a test are issued - starting or stopping an action, for example.
Failure notifications are generated when a transaction or subscriber session fails due to an interface application or protocol error - the same type of error that would cause an error measurement to be incremented.
Throttling notifications are sent whenever the throttling phase changes.
System Utilization notifications are generated when a test configuration is loaded or unloaded and when a TCP client connects to or disconnects from dsTest. They contain a time stamp, the event type, and either test name and user name for test events or user name only for user events.
Log notifications transmit the messages written to log files. Use the log command with the verbose attribute set to the level of log messages desired or 0 to discontinue. Use with caution as there can be many log messages per second.
Broadcast notifications transmit the message entered with a wall command to all clients currently connected to that instance of dsTest. Establishing a TCP connection with dsTest implicitly registers a client for this type of notification.
Licensing notifications convey errors related to your dsTest license - an expiration warning for a node-locked license, for example - and they are transmitted to TCP clients.
Notifications are processed on a low priority thread and thus if the dsTest platform is operating at or near capacity some notifications may be dropped.
With dsClient Desktop
As noted above, there are some notifications that dsClient Desktop will automatically handle. You can use the Notification Panel to register for any other types of notifications you wish to receive or to turn off those that are no longer relevant. Notifications received are displayed in a scrolling table. dsClient will clean up active registrations while it's shutting down.
With dsClient Terminal
You can use the register and deregister commands with dsClient Terminal and notifications will be printed to the console as they are received.
Since this is a low priority activity, you must launch dsClient Terminal with a low priority connection as shown below.
With the RESTful API
When you register for notifications using REST, the registration is maintained as long as the REST client remains connected. With HTTP 1.1 this requires that you include a Connection: keep-alive header in your requests.
No message body is required for either the register or deregister commands and therefore you can use GET requests for the commands. dsTest will queue notifications until they are retrieved with a GET request.
Register URI: /dsTest_v1/register:type:status_change
Deregister URI: /dsTest_v1/deregister:type:status_change
Collection URI: /dsTest_v1/notifications