Partager via

3.2.3.4.1 Failure Semantics

  • Article

A server protocol built on top of these extensions can encounter a failure while executing a method call. It can handle the failure at the application protocol layer, it can expose the failure to the RPC protocol layer, or it can choose application-specific handling not specified in this document.

If it handles the error at the application protocol layer, the interaction appears to be successful from the point of view of the RPC runtime. The [out] parameters are filled, and the RPC implementation on the server sends a response PDU with the stub data (as specified in [C706] section 14.4). In this case, the [out] parameters SHOULD indicate the occurrence of an error, although the exact mechanism for doing so is left to the application protocol layer.

If the server implementation of the application protocol layer exposes the error to the RPC protocol layer, it SHOULD indicate to the RPC runtime (usually through calling an API) that the method call has failed, and, if so, it also SHOULD supply a single unsigned long number that indicates the failure code.

In this case, the server SHOULD send back to the client a fault PDU (as specified in [C706] section 12.5.3.5) where the status field of the fault PDU is set to the failure code received from the application protocol layer. The call then enters STATE_COMPLETE.<90>