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 Delivers Events to a Client
How the Delivery of Events Is Guaranteed
Contents of an SC_EVENT Message
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
After processing the registration, the server that received the registration request sends the SC_REPLY message on the TCP connection that the client opened. The server closes the connection. The client must keep the TCP connection open until it receives the SC_REPLY message from the server.
For example, the client carries out the following actions:
Opens a TCP connection to the server
Waits for a connection to be “writable”
Sends an SC_CALLBACK_REG message (which contains an ADD_CLIENT message)
Waits for an SC_REPLY message from the server
Receives an SC_REPLY message from the server
Receives an indicator that the server has closed the connection (reads 0 bytes from the socket)
Closes the connection
At a later point in time, the client carries out the following actions:
Opens a TCP connection to the server
Waits for a connection to be “writable”
Sends an SC_CALLBACK_REG message (which contains a REMOVE_CLIENT message)
Waits for an SC_REPLY message from the server
Receives an SC_REPLY message from the server
Receives an indicator that the server has closed the connection (reads 0 bytes from the socket)
Closes the connection
Each time that the server receives an SC_CALLBACK_REG message from a client, the server sends an SC_REPLY message on the same open connection. This message specifies whether the operation succeeded or failed. SC_REPLY XML DTD contains the XML document type definition of an SC_REPLY message, and the possible error messages that this message can include.
An SC_REPLY message specifies whether an operation succeeded or failed. This message contains the version of the CRNP message, a status code, and a status message, which describes the status code in more detail. The following table describes the possible values for the status code.
|
Under normal conditions, a client that sends an SC_CALLBACK_REG message receives a reply that indicates that the registration succeeded or failed.
However, the server can experience an error condition when a client is registering that prohibits the server from sending an SC_REPLY message to the client. In this case, the registration could either have succeeded before the error condition occurred, could have failed, or could not yet have been processed.
Because the server must function as a failover, or highly available, server in the cluster, this error condition does not mean an end to the service. In fact, the server could soon begin sending events to the newly registered client.
To remedy these conditions, your client should perform the following actions:
Impose an application-level timeout on a registration connection that is waiting for an SC_REPLY message, after which the client needs to retry registering.
Begin listening on its callback IP address and port number for event deliveries before it registers for the event callbacks. The client should wait for a registration confirmation message and for event deliveries in parallel. If the client begins to receive events before the client receives a confirmation message, the client should silently close the registration connection.