Communication Protocols For RPCs

This article will go through the concept of Communication protocols for Remote Procedure Calls (RPCs) in Distributed Systems in detail.

Communication Protocols for Remote Procedure Calls:

The following are the communication protocols that are used:

• Request Protocol
• Request/Reply Protocol
• The Request/Reply/Acknowledgement-Reply Protocol

Request Protocol:

• The Request Protocol is also known as the R protocol.
• It is used in Remote Procedure Call (RPC) when a request is made from the calling procedure to the called procedure. After execution of the request, a called procedure has nothing to return and there is no confirmation required of the execution of a procedure.
• Because there is no acknowledgement or reply message, only one message is sent from client to server.
• A reply is not required so after sending the request message the client can further proceed with the next request.
• May-be call semantics are provided by this protocol, which eliminates the requirement for retransmission of request packets.
• Asynchronous Remote Procedure Call (RPC) employs the R protocol for enhancing the combined performance of the client and server. By using this protocol, the client need not wait for a reply from the server and the server does not need to send that.
• In an Asynchronous Remote Procedure Call (RPC) in case communication fails, the RPC Runtime does not retry the request. TCP is a better option than UDP since it does not require retransmission and is connection-oriented.
• In most cases, asynchronous RPC with an unstable transport protocol is utilized to implement periodic update services. One of its applications is the Distributed System Window.

Request/Reply Protocol:

• The Request-Reply Protocol is also known as the RR protocol.
• It works well for systems that involve simple RPCs.
• The parameters and result values are enclosed in a single packet buffer in simple RPCs. The duration of the call and the time between calls are both briefs.
• This protocol has a concept base of using implicit acknowledgements instead of explicit acknowledgements.
• Here, a reply from the server is treated as the acknowledgement (ACK) for the client’s request message, and a client’s following call is considered as an acknowledgement (ACK) of the server’s reply message to the previous call made by the client.
• To deal with failure handling e.g. lost messages, the timeout transmission technique is used with RR protocol.
• If a client does not get a response message within the predetermined timeout period, it retransmits the request message.
• Exactly-once semantics is provided by servers as responses get held in reply cache that helps in filtering the duplicated request messages and reply messages are retransmitted without processing the request again.
• If there is no mechanism for filtering duplicate messages then at least-call semantics is used by RR protocol in combination with timeout transmission.

The Request/Reply/Acknowledgement-Reply Protocol:

• This protocol is also known as the RRA protocol (request/reply/acknowledge-reply).
• Exactly-once semantics is provided by RR protocol which refers to the responses getting held in reply cache of servers resulting in loss of replies that have not been delivered.
• The RRA (Request/Reply/Acknowledgement-Reply ) Protocol is used to get rid of the drawbacks of the RR (Request/Reply) Protocol.
• In this protocol, the client acknowledges the receiving of reply messages and when the server gets back the acknowledgement from the client then only deletes the information from its cache.
• Because the reply acknowledgement message may be lost at times, the RRA protocol requires unique ordered message identities. This keeps track of the acknowledgement series that has been sent.

Complicated RPCs

• RPCs that involve long-duration calls or large gaps between calls.
• RPCs that involve parameters(arguments) and/or result in values that are too large to fit in a single datagram packet.
• RPCs that involve long-duration calls or large gaps between calls:
  • The client probes the server regularly: After the submission of a request message from a client to the server, the client continuously sends a probe packet which a server needs to acknowledge.The exception status is communicated to the corresponding user if a communication failure occurs. Each probe packet contains the message identifier from the initial request message.
  • The server generates an acknowledgement regularly: If the generation of the next packet by the server gets delayed then the predicted retransmission time interval, then it generates an acknowledgement on its own. Hence, during a long-duration call, many acknowledgements may be generated from the server as several acknowledgements directly correspond to the call duration. If within the set interval of time the response or acknowledgement from the server has not been received by the client then it comes to the conclusion that either server has crashed or the failure occurs on the client-side or in case of communication failure user is alerted about the exception condition.
• RPCs that involve parameters/arguments and/or result in values that are too large to fit in a single datagram packet:
  • RPCs with Long Messages: To handle such an RPC, employ many physical RPCs for a single logical RPC. The sending of data in each physical RPC is made in the size of a single datagram packet. This technique is inefficient since each RPC incurs a set amount of overhead regardless of the quantity of data transmitted.
  • Multidatagram Messages: Multidatagram messages are another approach for dealing with sophisticated RPCs in this category. It involves the division of long RPC parameters(arguments) or result into many packets and then sent in multiples. All the packets in a multi datagram message utilize a single acknowledgement packet for enhancing communication performance.