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
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
Note - The NVPAIR data structure that is used by both SC_CALLBACK_REG and SC_EVENT is defined only once.
<!— SC_CALLBACK_REG XML format specification Copyright 2001, 2012, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Intended Use: A client of the Cluster Reconfiguration Notification Protocol should use this xml format to register initially with the service, to subsequently register for more events, to subsequently remove registration of some events, or to remove itself from the service entirely. A client is uniquely identified by its callback IP and port. The port is defined in the SC_CALLBACK_REG element, and the IP is taken as the source IP of the registration connection. The final attribute of the root SC_CALLBACK_REG element is either an ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT, or REMOVE_EVENTS, depending on which form of the message the client is using. The SC_CALLBACK_REG contains 0 or more SC_EVENT_REG sub-elements. One SC_EVENT_REG is the specification for one event type. A client may specify only the CLASS (an attribute of the SC_EVENT_REG element), or may specify a SUBCLASS (an optional attribute) for further granularity. Also, the SC_EVENT_REG has as subelements 0 or more NVPAIRs, which can be used to further specify the event. Thus, the client can specify events to whatever granularity it wants. Note that a client cannot both register for and unregister for events in the same message. However a client can subscribe to the service and sign up for events in the same message. Note on versioning: the VERSION attribute of each root element is marked "fixed", which means that all message adhering to these DTDs must have the version value specified. If a new version of the protocol is created, the revised DTDs will have a new value for this fixed" VERSION attribute, such that all message adhering to the new version must have the new version number. —> <!— SC_CALLBACK_REG definition The root element of the XML document is a registration message. A registration message consists of the callback port and the protocol version as attributes, and either an ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT, or REMOVE_EVENTS attribute, specifying the registration type. The ADD_CLIENT, ADD_EVENTS, and REMOVE_EVENTS types should have one or more SC_EVENT_REG subelements. The REMOVE_CLIENT should not specify an SC_EVENT_REG subelement. ATTRIBUTES: VERSION The CRNP protocol version of the message. PORT The callback port. REG_TYPE The type of registration. One of: ADD_CLIENT, ADD_EVENTS, REMOVE_CLIENT, REMOVE_EVENTS CONTENTS: SUBELEMENTS: SC_EVENT_REG (0 or more) —> <!ELEMENT SC_CALLBACK_REG (SC_EVENT_REG*)> <!ATTLIST SC_CALLBACK_REG VERSION NMTOKEN #FIXED PORT NMTOKEN #REQUIRED REG_TYPE (ADD_CLIENT|ADD_EVENTS|REMOVE_CLIENT|REMOVE_EVENTS) #REQUIRED > <!— SC_EVENT_REG definition The SC_EVENT_REG defines an event for which the client is either registering or unregistering interest in receiving event notifications. The registration can be for any level of granularity, from only event class down to specific name/value pairs that must be present. Thus, the only required attribute is the CLASS. The SUBCLASS attribute, and the NVPAIRS sub-elements are optional, for higher granularity. Registrations that specify name/value pairs are registering interest in notification of messages from the class/subclass specified with ALL name/value pairs present. Unregistrations that specify name/value pairs are unregistering interest in notifications that have EXACTLY those name/value pairs in granularity previously specified. Unregistrations that do not specify name/value pairs unregister interest in ALL event notifications of the specified class/subclass. ATTRIBUTES: CLASS: The event class for which this element is registering or unregistering interest. SUBCLASS: The subclass of the event (optional). CONTENTS: SUBELEMENTS: 0 or more NVPAIRs. —> <!ELEMENT SC_EVENT_REG (NVPAIR*)> <!ATTLIST SC_EVENT_REG CLASS CDATA #REQUIRED SUBCLASS CDATA #IMPLIED >