How SC_CALLBACK_REG Messages Are Passed Between a Client and the Server
A client initiates a registration by opening a TCP connection to the server's IP address and port number. After the TCP connection is established and ready for writing, the client must send its registration message. The registration message must be one correctly formatted SC_CALLBACK_REG message that does not contain extra bytes either before or after the message.
After all the bytes have been written to the stream, the client must keep its connection open to receive the reply from the server. If the client does not format the message correctly, the server does not register the client, and sends an error reply to the client. If the client closes the socket connection before the server sends a reply, the server registers the client as normal.
A client can contact the server at any time. Every time a client contacts the server, the client must send an SC_CALLBACK_REG message. If the server receives a message that is malformed, out of order, or invalid, the server sends an error reply to the client.
A client cannot send an ADD_EVENTS, REMOVE_EVENTS, or REMOVE_CLIENT message before that client sends an ADD_CLIENT message. A client cannot send a REMOVE_CLIENT message before that client sends an ADD_CLIENT message.
If a client sends an ADD_CLIENT message and the client is already registered, the server might tolerate this message. In this situation, the server silently replaces the old client registration with the new client registration that is specified in the second ADD_CLIENT message.
In most situations, a client registers with the server once, when the client starts, by sending an ADD_CLIENT message. And a client unregisters once by sending a REMOVE_CLIENT message to the server. However, the CRNP provides more flexibility for those clients that need to modify their event type list dynamically.
Contents of an SC_CALLBACK_REG Message
Each ADD_CLIENT, ADD_EVENTS, and REMOVE_EVENTS message contains a list of events. The following table describes the event types that the CRNP accepts, including the required name and value pairs.
-
Sends a REMOVE_EVENTS message that specifies one or more event types for which the client has not previously registered, or
-
Registers for the same event type twice
|
Class and Subclass |
Name and Value Pairs |
Description |
|---|---|---|
|
EC_Cluster ESC_cluster_membership |
Required: none Optional: none |
Registers for all cluster membership change events (node death or join) |
|
EC_Cluster ESC_cluster_rg_state |
One required, as follows: rg_name Value type: string Optional: none |
Registers for all state change events for resource group name |
|
EC_Cluster ESC_cluster_r_state |
One required, as follows: r_name Value type: string Optional: none |
Registers for all state change events for resource name |
|
EC_Cluster None |
Required: none Optional: none |
Registers for all Sun Cluster events |
- © 2010, Oracle Corporation and/or its affiliates