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


How the CRNP Authenticates Clients and the Server

The server authenticates a client by using a form of TCP wrappers. The source IP address of the registration message, which is also used as the callback IP address on which events are delivered, must be in the list of allowed clients on the server. The source IP address and registration message cannot be in the denied clients list. If the source IP address and registration are not in the list, the server rejects the request and issues an error reply to the client.

When the server receives an SC_CALLBACK_REG ADD_CLIENT message, subsequent SC_CALLBACK_REG messages for that client must contain a source IP address that is the same as the source IP address in the first message.

If the CRNP server receives an SC_CALLBACK_REG that does not meet this requirement, the server performs one of the following actions:

This security mechanism helps to prevent denial of service attacks, where someone attempts to unregister a legitimate client.

Clients should also similarly authenticate the server. Clients need only accept event deliveries from a server whose source IP address and port number are the same as the registration IP address and port number that the client used.

Because clients of the CRNP service are supposed to be located inside a firewall that protects the cluster, the CRNP does not include additional security mechanisms.