Call semantics in RPC take care of how many times the remote procedure is executed and failures are handled.
- Determines if a remote procedure runs once, multiple times, or possibly not at all.
- Explains how the system deals with lost messages, timeouts or retransmissions.
- It helps the client to understand what result expect when errors occur.
Reasons for failure in RPC
RPC Runtime includes code for handling failures. Determine how frequently the remote operation can run in the event of a failure.
- The caller/callee node has failed.
- The response message/ call is missing.
Types of RPC Call Semantics
Call semantics define how many times a remote procedure may execute when failures or retransmissions occur in a distributed system. These semantics determine how the client and server handle lost messages, duplicate requests, and timeouts.
1. Perhaps (Possibly) Call Semantics
This is the weakest guarantee in RPC systems. The client sends the request once and does not retry if a response is not received.
- The procedure may execute zero or one time.
- If the request or reply message is lost, the client cannot determine whether the procedure was executed or not.
- No retransmission mechanism is used.
- Suitable for non-critical operations such as periodic updates.
2. Last-One Call Semantics
This ensures that the result returned to the client corresponds to the most recent procedure call attempt.
- The client retransmits the request if a timeout occurs.
- Multiple executions of the procedure may happen due to retransmissions.
- The client accepts the result of the last executed call.
- Earlier executions may create orphan calls.
3. Last-of-Many Call Semantics
Improves reliability by identifying repeated requests using call identifiers.
- Each RPC request is assigned a unique call identifier (call ID).
- If the request is retransmitted, a new identifier is generated.
- The client accepts the response only if it corresponds to the latest call ID.
- Responses from earlier executions are ignored, preventing confusion caused by orphan calls.
4. At-Least-Once Call Semantics
It guarantees that the remote procedure executes one or more times.
- The client retransmits the request until a response is received.
- Due to retransmissions, the procedure may execute multiple times.
- Suitable for idempotent operations where repeated execution does not affect the result.
- Example: reading data from a server.
5. Exactly-Once Call Semantics
This guarantees that the remote procedure executes exactly once, even if messages are retransmitted.
- The server maintains a reply cache or request identifier table.
- Duplicate requests are detected and ignored.
- The server returns the cached result for repeated requests.
- Cache entries are removed after the client acknowledges the reply.