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 Server Delivers Events to a Client
How the Delivery of Events Is Guaranteed
Contents of an SC_EVENT Message
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
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:
Ignores the request and sends an error reply to the client
Assumes that the request comes from a new client, depending on the contents of the SC_CALLBACK_REG message
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.