Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

## `SC_CALLBACK_REG` XML DTD

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
    >

Copyright © 2000, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |