How the Server Delivers Events to a Client
As events are generated within the cluster, the CRNP server delivers them to all clients who 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 then discover 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 then issues a full-duplex close.
For example, the client carries out the following actions:
-
Waits for the server to initiate a TCP connection
-
Accepts the incoming connection from the server
-
Waits for an SC_EVENT message
-
Reads an SC_EVENT message
-
Receives an indicator that the server has closed the connection (reads 0 bytes from the socket)
-
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 re-register 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, then 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 is allowed to 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 if 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.
|
Class and Subclass |
Publisher and Vendor |
Name and Value Pairs |
Notes |
|---|---|---|---|
|
EC_Cluster ESC_cluster_membership |
Publisher: rgm Vendor: SUNW |
Name: node_list Value type: string array Name: state_list Value type: string array |
The positions of the array elements for state_list are synchronized with those of the node_list. That is, the state for the node listed first in the node_list array is first in the state_list array. The state_list contains only numbers 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. Additional names starting with ev_ and their associated values might be present, but are not intended for client use. |
|
EC_Cluster ESC_cluster_rg_state |
Publisher: rgm Vendor: SUNW |
Name: rg_name Value type: string Name: node_list Value type: string array Name: state_list Value type: string array |
The positions of the array elements for state_list are synchronized with those of the node_list. That is, the state for the node listed first in the node_list array is first in the state_list array. 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. Additional names starting with ev_ and their associated values might be present, but are not intended for client use. |
|
EC_Cluster ESC_cluster_r_state |
Publisher: rgm Vendor: SUNW |
Three required, as follows: Name: r_name Value type: string Name: node_list Value type: string array Name: state_list Value type: string array |
The positions of the array elements for state_list are synchronized with those of the node_list. That is, the state for the node listed first in the node_list array is first in the state_list array. 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. Additional names starting with ev_ and their associated values might be present, but are not intended for client use. |
- © 2010, Oracle Corporation and/or its affiliates