Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

## How the Server Delivers Events to a Client

As events are generated within the cluster, the CRNP server delivers them to each client that requested events of those types. The delivery consists of sending an `SC_EVENT` message to the client's callback address. The delivery of each event occurs on a new TCP connection.

Immediately after a client registers for an event type, through an `SC_CALLBACK_REG` message that contains an `ADD_CLIENT` message or an `ADD_EVENT` message, the server sends the most recent event of that type to the client. The client can determine the current state of the system from which the subsequent events come.

When the server initiates a TCP connection to the client, the server sends exactly one `SC_EVENT` message on the connection. The server issues a full-duplex close.

For example, the client carries out the following actions:

1. Waits for the server to initiate a TCP connection

2. Accepts the incoming connection from the server

3. Waits for an `SC_EVENT` message from the server

4. Reads an `SC_EVENT` message from the server

5. Receives an indicator that the server has closed the connection (reads 0 bytes from the socket)

6. Closes the connection

When all clients have registered, they must listen at their callback address (the IP address and port number) at all times for an incoming event delivery connection.

If the server fails to contact the client to deliver an event, the server tries again to deliver the event the number of times and at the interval that you define. If all attempts fail, the client is removed from the server's list of clients. The client also needs to reregister by sending another `SC_CALLBACK_REG` message that contains an `ADD_CLIENT` message before the client can receive more events.

### How the Delivery of Events Is Guaranteed

There is a total ordering of event generation within the cluster that is preserved in the order of delivery to each client. In other words, if event A is generated within the cluster before event B, client X receives event A before that client receives event B. However, the total ordering of event delivery to all clients is not preserved. That is, client Y could receive both events A and B before client X receives event A. In this way, slow clients do not hold up delivery to all clients.

All events that the server delivers (except the first event for a subclass and events that follow server errors) occur in response to the actual events that the cluster generates, except if the server experiences an error that causes it to miss cluster-generated events. In this case, the server generates an event for each event type that represents the current state of the system for that type. Each event is sent to clients that registered interest in that event type.

Event delivery follows the “at least once” semantics. That is, the server can send the same event to a client more than once. This allowance is necessary in cases in which the server goes down temporarily, and when it comes back up, cannot determine whether the client has received the latest information.

### Contents of an `SC_EVENT` Message

The `SC_EVENT` message contains the actual message that is generated within the cluster, translated to fit into the `SC_EVENT` XML message format. The following table describes the event types that the CRNP delivers, including the name and value pairs, publisher, and vendor.

Note - The positions of the array elements for `state_list` are synchronized with those of the `node_list`. That is, the state for the node that is listed first in the `node_list` array is listed first in the `state_list` array.

Additional names starting with `ev_` and their associated values might be present, but are not intended for client use.

Class and Subclass | Publisher and Vendor | Name and Value Pairs
--- | --- | ---
`EC_Cluster` `ESC_cluster_membership` | Publisher: `rgm` Vendor: ORCL | Name: `node_list` Value type: string array Name: `state_list` The `state_list` contains only numbers that are represented in ASCII. Each number represents the current incarnation number for that node in the cluster. If the number is the same as the number that was received in a previous message, the node has not changed its relationship to the cluster (departed, joined, or rejoined). If the incarnation number is –1, the node is not a member of the cluster. If the incarnation number is a number other than a negative number, the node is a member of the cluster. Value type: string array
`EC_Cluster` `ESC_cluster_rg_state` | Publisher: `rgm` Vendor: ORCL | Name: `rg_name` Value type: string Name: `node_list` Value type: string array Name: `state_list` The `state_list` contains string representations of the state of the resource group. Valid values are those values that you can retrieve with the `scha_cmds`(1HA) commands. Value type: string array
`EC_Cluster` `ESC_cluster_r_state` | Publisher: `rgm` Vendor: ORCL | Name: `r_name` Value type: string Name: `node_list` Value type: string array Name: `state_list` The `state_list` contains string representations of the state of the resource. Valid values are those values that you can retrieve with the `scha_cmds`(1HA) commands. Value type: string array

Copyright © 2000, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |