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

## How the Server Replies to a Client

After processing the registration, the server that received the registration request sends the `SC_REPLY` message on the TCP connection that the client opened. The server closes the connection. The client must keep the TCP connection open until it receives the `SC_REPLY` message from the server.

For example, the client carries out the following actions:

1. Opens a TCP connection to the server

2. Waits for a connection to be “writable”

3. Sends an `SC_CALLBACK_REG` message (which contains an `ADD_CLIENT` message)

4. Waits for an `SC_REPLY` message from the server

5. Receives an `SC_REPLY` message from the server

6. Receives an indicator that the server has closed the connection (reads 0 bytes from the socket)

7. Closes the connection

At a later point in time, the client carries out the following actions:

1. Opens a TCP connection to the server

2. Waits for a connection to be “writable”

3. Sends an `SC_CALLBACK_REG` message (which contains a `REMOVE_CLIENT` message)

4. Waits for an `SC_REPLY` message from the server

5. Receives an `SC_REPLY` message from the server

6. Receives an indicator that the server has closed the connection (reads 0 bytes from the socket)

7. Closes the connection

Each time that the server receives an `SC_CALLBACK_REG` message from a client, the server sends an `SC_REPLY` message on the same open connection. This message specifies whether the operation succeeded or failed. `SC_REPLY` XML DTD contains the XML document type definition of an `SC_REPLY` message, and the possible error messages that this message can include.

### Contents of an `SC_REPLY` Message

An `SC_REPLY` message specifies whether an operation succeeded or failed. This message contains the version of the CRNP message, a status code, and a status message, which describes the status code in more detail. The following table describes the possible values for the status code.

Status Code | Description
--- | ---
`OK` | The message was processed successfully.
`RETRY` | The registration of the client was rejected by the server due to a transient error. The client should try to register again, with different arguments.
`LOW_RESOURCE` | Cluster resources are low, and the client can only try again at a later time. The cluster administrator for the cluster can also increase the resources in the cluster.
`SYSTEM_ERROR` | A serious problem occurred. Contact the cluster administrator for the cluster.
`FAIL` | Authorization failed or another problem caused the registration to fail.
`MALFORMED` | The XML request was malformed and could not be parsed.
`INVALID` | The XML request was invalid , that is, it does not meet the XML specification.
`VERSION_TOO_HIGH` | The version of the message was too high to process the message successfully.
`VERSION_TOO_LOW` | The version of the message was too low to process the message successfully.

### How a Client Is to Handle Error Conditions

Under normal conditions, a client that sends an `SC_CALLBACK_REG` message receives a reply that indicates that the registration succeeded or failed.

However, the server can experience an error condition when a client is registering that prohibits the server from sending an `SC_REPLY` message to the client. In this case, the registration could either have succeeded before the error condition occurred, could have failed, or could not yet have been processed.

Because the server must function as a failover, or highly available, server in the cluster, this error condition does not mean an end to the service. In fact, the server could soon begin sending events to the newly registered client.

To remedy these conditions, your client should perform the following actions:

- Impose an application-level timeout on a registration connection that is waiting for an `SC_REPLY` message, after which the client needs to retry registering.

- Begin listening on its callback IP address and port number for event deliveries before it registers for the event callbacks. The client should wait for a registration confirmation message and for event deliveries in parallel. If the client begins to receive events before the client receives a confirmation message, the client should silently close the registration connection.

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