JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Cluster Data Services Developer's Guide     Oracle Solaris Cluster 4.1
search filter icon
search icon

Document Information

Preface

1.  Overview of Resource Management

2.  Developing a Data Service

3.  Resource Management API Reference

4.  Modifying a Resource Type

5.  Sample Data Service

6.  Data Service Development Library

7.  Designing Resource Types

8.  Sample DSDL Resource Type Implementation

9.  Oracle Solaris Cluster Agent Builder

10.  Generic Data Service

11.  DSDL API Functions

12.  Cluster Reconfiguration Notification Protocol

CRNP Concepts

How the CRNP Works

CRNP Semantics

CRNP Message Types

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 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 Generate the XML

How to Create the Registration and Unregistration Messages

How to Set Up the XML Parser

How to Parse the Registration Reply

How to Parse the Callback Events

How to Run the Application

13.  Security for Data Services

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

E.  CrnpClient.java Application

Index

How the Server Replies to a Client

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:

  1. Opens a TCP connection to the server

  2. Waits for a connection to be “writable”

  3. Sends an SC_CALLBACK_REG message (which contains an ADD_CLIENT message)

  4. Waits for an SC_REPLY message from the server

  5. Receives an SC_REPLY message from the server

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

  7. Closes the connection

At a later point in time, the client carries out the following actions:

  1. Opens a TCP connection to the server

  2. Waits for a connection to be “writable”

  3. Sends an SC_CALLBACK_REG message (which contains a REMOVE_CLIENT message)

  4. Waits for an SC_REPLY message from the server

  5. Receives an SC_REPLY message from the server

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

  7. 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.

Contents of an SC_REPLY Message

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.

Status Code
Description
OK
The message was processed successfully.
RETRY
The registration of the client was rejected by the server due to a transient error. The client should try to register again, with different arguments.
LOW_RESOURCE
Cluster resources are low, and the client can only try again at a later time. The cluster administrator for the cluster can also increase the resources in the cluster.
SYSTEM_ERROR
A serious problem occurred. Contact the cluster administrator for the cluster.
FAIL
Authorization failed or another problem caused the registration to fail.
MALFORMED
The XML request was malformed and could not be parsed.
INVALID
The XML request was invalid , that is, it does not meet the XML specification.
VERSION_TOO_HIGH
The version of the message was too high to process the message successfully.
VERSION_TOO_LOW
The version of the message was too low to process the message successfully.

How a Client Is to Handle Error Conditions

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: