Distributed Systems Development - Autonomics Development: A Domain-Specific Aspect Language Approach - page 17

Caller site failure: The caller process fails or the host running the caller process
fails.
Callee site failure: The callee process fails or the host running the callee process
fails. In this case, the caller may be indefinitely suspended awaiting a re-
sponse from the callee.
Most RPC systems, such as DCE RPC [109], attempt to hide their distributed
nature from the programmer so that, to the programmer, the RPC system is trans-
parent. The RPC system, and not the application code, is therefore responsible
for ensuring a message reaches its intended destination and a response is received.
If, however, no response is received within a specific timeout period, one of
four different conditions may have occurred [90]:
1. The callee did not receive the request.
2. The callee received the request and acted upon it but the caller did not receive
the response.
3. The callee failed during the execution of the call and either resumed execution
of the call upon restarting or did not.
4. The callee was still busy executing the call when the caller timed out.
According to Soares [90], a major design decision for an RPC mechanism is
the choice of call semantics in the presence of failures. Spector [95] defines four
different call semantics:
Maybe: The callee does not return a response to the caller and the caller receives
no indication of success or failure.
At least once: The remote procedure is executed at least once.
Only once type 1: This is commonly referred to as at most once [108]. The remote
procedure is executed at most once.
Only once type 2: This is commonly referred to as exactly once [108]. The call has
been executed once only.
Although exactly once call semantics are generally considered to only be
possible using asynchronous procedure calls [95], a number of attempts have been
made to provide exactly once semantics for synchronous procedure calls.
Heindel and Kasten [48] have implemented reliable synchronous RPC calls
for DCE by imposing a middleware layer between the caller and callee. This
middleware layer, however, uses asynchronous messaging to achieve this reliability
and therefore can be considered asynchronous in implementation.
The Encina transaction monitor attempts to implement reliable synchronous
messaging using an extension of DCE's RPC, called TRPC - transactional RPC
[89]. This approach is, in many ways, similar to the asynchronous approach as
transactions are written to a log file before being committed. Other approaches,
such as replicated procedure calls, have been implemented [22]. Unfortunately