Share via

3.2.3.3 Reconnect Logic Initialization

  • Article

Along with establishing an RPC connection, client-side initialization SHOULD gather the state that is necessary to execute the reconnect-on-failure logic as specified in sections 3.2.1 and 3.2.4.6. The client SHOULD initialize reconnect logic according to the following procedure. This procedure MUST NOT be executed until an RPC connection is successfully established, as specified in section 3.2.3.2.

The client SHOULD call the ApiGetClusterName (section 3.1.4.1.4 for protocol version 2, or 3.1.4.2.4 for protocol version 3) method in order to retrieve the cluster name and the current server computer name. As long as this method fails with status 0x000006BF (RPC_CALL_FAILED_DNE), the client SHOULD<222> try the method again, although it SHOULD NOT exceed four attempts. If the method fails, either with a status other than 0x000006BF (RPC_CALL_FAILED_DNE) or by exhausting retries, the client SHOULD terminate the RPC connection and deduce that the server is not an active node in a cluster. If the method is successful, the client SHOULD add the cluster name to the list of reconnect candidates, as specified in section 3.2.1, and save the current server computer name.

The client SHOULD call the ApiOpenCluster (section 3.1.4.1.1 for protocol version 2, or 3.1.4.2.1 for protocol version 3) or ApiOpenClusterEx (section 3.1.4.2.116 for protocol version 3) method. If the method fails, the client SHOULD terminate the RPC connection and deduce that the server is not an active node in a cluster.

The client SHOULD retrieve an enumeration of cluster nodes by using the ApiCreateEnum (section 3.1.4.1.8 for protocol version 2, or 3.1.4.2.8 for protocol version 3) method. If the method fails, the client SHOULD terminate the RPC connection and deduce that the server is not an active node in a cluster. If the method is successful, the client SHOULD add the Computer Name of all cluster nodes to the list of reconnect candidates, as specified in section 3.2.1.