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

Document Information


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

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


CRNP Concepts

The CRNP defines the Application, Presentation, and Session layers of the standard seven-layer Open System Interconnect (OSI) protocol stack. The Transport layer must be TCP, and the Network layer must be IP. The CRNP is independent of the Data Link and Physical layers. All Application layer messages that are exchanged in the CRNP are based on XML 1.0.

Note - You can run the CRNP only on a global-cluster voting node.

How the CRNP Works

The CRNP provides mechanisms and daemons that generate cluster reconfiguration events, route the events through the cluster, and send them to interested clients.

The cl_apid daemon interacts with the clients. The Oracle Solaris Cluster Resource Group Manager (RGM) generates cluster reconfiguration events. This daemon uses syseventd to transmit events on each local node. The cl_apid daemon uses Extensible Markup Language (XML) over TCP/IP to communicate with interested clients.

The following diagram shows the flow of events between the CRNP components. In this diagram, one client is running on cluster node 2, and the other client is running on a computer that is not part of the cluster.

Figure 12-1 Flow of Events Between CRNP Components

image:Flow diagram showing how the CRNP works

CRNP Semantics

Clients initiate communication by sending a registration message (SC_CALLBACK_RG) to the server. This registration message specifies the event types for which the clients want to receive notification as well as a port to which the events can be delivered. The source IP of the registration connection and the specified port, taken together, form the callback address.

Whenever an event of interest to a client is generated within the cluster, the server contacts the client on its callback address (IP and port) and delivers the event (SC_EVENT) to the client. The server is highly available, running within the cluster itself. The server stores client registrations in storage that persists even after the cluster is rebooted.

Clients unregister by sending a registration message (SC_CALLBACK_RG, which contains a REMOVE_CLIENT message) to the server. After the client receives an SC_REPLY message from the server, the client closes the connection.

The following diagram shows the flow of communication between a client and a server.

Figure 12-2 Flow of Communication Between a Client and a Server

image:Flow diagram showing flow of communication between client and server

CRNP Message Types

The CRNP uses three types of XML-based messages. Use of these messages is described in the following table. These message types are described in more detail later in this chapter.

CRNP Message Type
This message takes four forms: ADD_CLIENT, REMOVE_CLIENT, ADD_EVENTS, and REMOVE_EVENTS.

Each of these forms contains the following information:

  • Protocol version

  • Callback port in ASCII format (not binary format)

ADD_CLIENT, ADD_EVENTS, and REMOVE_EVENTS also contain an unbounded list of event types.

Each of these forms includes the following information:

  • Event class

  • Event subclass (optional)

  • List of the name and value pairs (optional)

Together, the event class and event subclass define a unique “event type.” The document type definition (DTD) from which the classes of SC_CALLBACK_REG are generated is SC_CALLBACK_REG. This DTD is described in more detail in Appendix D, Document Type Definitions for the CRNP.

This message contains the following information:
  • Protocol version

  • Error code

  • Error message

The DTD from which the classes of SC_REPLY are generated is SC_REPLY. This DTD is described in more detail in Appendix D, Document Type Definitions for the CRNP.

This message contains the following information:
  • Protocol version

  • Event class

  • Event subclass

  • Vendor

  • Publisher

  • Name and value pairs list (0 or more name and value pair data structures)

    • Name (string)

    • Value (string or string array)

The values in an SC_EVENT are not typed. The DTD from which the classes of SC_EVENT are generated is SC_EVENT. This DTD is described in more detail in Appendix D, Document Type Definitions for the CRNP.