This article will go through the Call Semantics, its types, and the issues in RPC in distributed systems in detail. RPC has the same semantics as a local procedure call, the calling process calls the procedure, gives inputs to it, and then waits while it executes. When the procedure is finished, it can return results to the calling process. If the distributed system is to achieve transparency, the following problems concerning the properties of remote procedure calls must be considered in the design of an RPC system:
- Binding: Binding establishes a link between the caller process’s name and the remote procedure’s location.
- Communication Transparency: It should be unknown to the users that the process they are calling is remote.
- Concurrency: Communication techniques should not mix with concurrency mechanisms. When single-threaded clients and servers are blocked while waiting for RPC results, considerable delays might occur. Lightweight processes permit the server to handle concurrent calls from several clients.
- Heterogeneity: Separate machines may have distinct data representations, operate under different operating systems, or have remote procedures written in different languages.
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 Call Semantics:
- Perhaps or Possibly Call Semantics: It is the weakest one, here, the caller is waiting until a predetermined timeout period and then continues with its execution. It is used in services where periodic updates are required.
- Last-one Call Semantics: Based on timeout, retransmission of call message is made. After the elapsing of the timeout period, the obtained result from the last execution is used by the caller. It sends out orphan calls. It finds its application in designing simple RPC.
- Last-of-Many Call Semantics: It is like Last-one Call semantics but the difference here is that it neglects orphan calls through call identifiers. A new call-id is assigned to the call whenever it is repeated. It is accepted by the caller only if the caller id matches the most recent repeated call.
- At-least-once Call Semantics: The execution of the call is there for one or more times, but the results given to the caller are not specified. Here also retransmissions rely on the time-out period without giving a thought to orphan calls. In the case of nested calls, the result is taken from the first response message if there are orphan calls and others are ignored irrespective of the accepted response is whether from orphan or not.
- Exactly-once Call Semantics: No matter how many times the call is transmitted, the potential of the procedure being conducted more than once is eliminated. When the server receives an acknowledgment from the client then only it deletes information from the reply cache.