Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.0 |
1. Overview of Resource Management
3. Resource Management API Reference
6. Data Service Development Library
8. Sample DSDL Resource Type Implementation
9. Oracle Solaris Cluster Agent Builder
12. Cluster Reconfiguration Notification Protocol
How a Client Registers With the Server
Assumptions About How Administrators Set Up the Server
How the Server Identifies a Client
How SC_CALLBACK_REG Messages Are Passed Between a Client and the Server
Contents of an SC_CALLBACK_REG Message
How the Server Replies to a Client
Contents of an SC_REPLY Message
How a Client Is to Handle Error Conditions
How the CRNP Authenticates Clients and the Server
Example of Creating a Java Application That Uses the CRNP
How to Set Up Your Environment
How to Start Developing Your Application
How to Parse the Command-Line Arguments
How to Define the Event Reception Thread
How to Register and Unregister Callbacks
How to Create the Registration and Unregistration Messages
How to Parse the Registration Reply
How to Parse the Callback Events
A. Sample Data Service Code Listings
B. DSDL Sample Resource Type Code Listings
C. Requirements for Non-Cluster-Aware Applications
D. Document Type Definitions for the CRNP
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:
Waits for the server to initiate a TCP connection
Accepts the incoming connection from the server
Waits for an SC_EVENT message from the server
Reads an SC_EVENT message from the server
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 reregister by sending another SC_CALLBACK_REG message that contains an ADD_CLIENT message before the client can receive more events.
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.
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.
|