What is Message Buffering?

Remote Procedure Call (RPC) is a communication technology that is used by one program to make a request to another program for utilizing its service on a network without even knowing the network's details. 

The inter-process communication in distributed systems is performed using Message Passing. It permits the exchange of messages between the processes using primitives for sending and receiving messages. The programmer must understand the message as well as the names of the source and destination processes. The send() primitive is used by the process for sending messages and receive() primitive is used by the process for receiving messages.

RPC Messages:

In distributed systems, communication is carried out between processes by passing messages from one process to another. Message passing is at the lowest level of abstraction whereas RPC represents higher abstraction. Because of the lowest level of abstraction, it requires that the application programmer be able to identify the message, source process, destination process, and data types likely from the involved processes. 

Syntax: The syntax used in message passing for the send() and receive() primitives are as follows:

send (receiver, message) // requires the name of the destination process 
                            and the message data as arguments
receive(sender, message) // requires the name of the sender process 
                            and the message data as arguments

Semantics:

1. Blocking/non-blocking: A blocking send() stops the process and waits until the message has been sent and the message buffer has been cleared before continuing. A blocking receive, on the other hand, blocks at receive() until the message arrives. A non-blocking send quickly returns control to the caller. The message transmission process is then run in parallel with the sending phase.
2. Buffered/Unbuffered messages: Unbuffered receive() means that instead of using a message buffer, the transmitting process sends the message immediately to the receiving process. The address, receiver, in send() is the process's address; however, in buffered send(), the address is the buffer's address.
3. Reliable/Unreliable send: Unreliable send() transmits a message to the recipient without expecting it to be acknowledged, and it does not automatically retransmit the message to ensure receipt. A reliable send() ensures that the message has been received by the time the send() is finished.
4. Direct/Indirect Communication: The use of ports allows for indirect communication. The transmitter sends messages to the port, and the receiver receives them from the port. Instead of sending the message to an intermediate port, the message is sent directly to the process, which is identified specifically in the send, receive in case of direct communication.
5. Fixed/Variable size messages: The size of fixed-size messages is limited by the system. Variable size messages are more complex to construct, but they make programming easier; the opposite is true for fixed-size messages.

Message Types:

There are two types of messages used in the RPC implementation:

1. Call Messages
2. Reply Messages

1. Call Messages:

The client sends the call message to the server so that the remote procedure can be executed.

Format:

1. Remote Procedure Identifier: This field has the information regarding the remote procedure which is to be executed.
2. Arguments: The arguments that are required for the execution of the procedure.
3. Message Identification: This field is used to identify the messages that are lost and duplicated through the sequence number.
4. Message Type: This field is used to identify the message type i.e. whether a message belongs to call message type or reply message type.
5. Client Identification: This field allows the server to identify the client and to authenticate the client process as well.

RPC Call Message Format:

2. Reply Messages:

The server returns the result of the remote procedure execution to the client using a reply message.  There are two forms of reply messages- successful messages and unsuccessful messages. 

A. Successful Reply Message: If the particular remote procedure is executed successfully.

Format:

Message Identifier     Message Type     Reply Status (0) - Successful     Result

B. An Unsuccessful Message: If any of the following conditions arise then the message is of unsuccessful type:

1. The server identifies by scanning the client's identifier field that the client is not authorized to utilize the service.
2. The Identifier is missing.
3. If the server does not find any detail in program number, version number, or procedure number fields.
4. During the execution of the remote procedure, an exception condition occurs.
5. If the server is unable to decode the given arguments.
6. The server finds that the call message is not coherent to it.

Format:

Message Identifier     Message Type     Reply Status (1) - Unsuccessful     Reason for failure

Message Buffering

Buffering implies queuing of sending or receiving messages during transmission to and from one process to another. The buffer is the temporary storage area used to hold the message until receiving process is not ready to receive the message so that it can be retrieved later on. Following are the buffering mechanisms depending on synchronous and asynchronous systems:

1. Synchronous Systems

These systems can have no buffer or single message buffer.

Null Buffer or No Buffer:

 In the no buffer strategy, no temporary storage is used for keeping the messages. It is used in an asynchronous mode of communication. Two approaches are used in this strategy- Message will remain in the sender's address space i.e. sending is delayed until receiver executes the receive() primitive after completing current receiving. Another one, a message will be discarded and then will be resent after a certain period which is set.

Single-Message Buffer:

In a single-message buffer mechanism, a buffer is maintained to store only a single message at the receiver end. The message will be buffered only in that case if the receiver is not ready to receive the message. The location of the buffer can either be in the kernel's address space or at the receiving side in the receiver's process address space. It is used in a synchronous mode of communication.

2. Asynchronous Systems:

These systems can have an unbounded capacity buffer or a finite bound message (multiple message buffer).

Unbounded Capacity Buffer:

In this strategy, the sender need not wait for sending messages if, on the receiving side, the receiver is not ready to receive the messages. Unbounded Capacity refers that will keep all the messages received from the sender and assure that these will be delivered to the receiver. It is used in an asynchronous mode of communication.

Finite-bound Buffer (Multiple-message Buffer):

In a finite-bound buffer, the mechanism is used to handle the issue of buffer overflow. It is used in an asynchronous mode of communication. The allocated buffer space depends on implementation.  Following are the two ways that can be used to handle this issue of overflow:

1. Unsuccessful Communication: The send() primitive returns an error message to the sending process i.e. the communication is unsuccessful because the message is not delivered to the intended destination. It is less reliable.
2. Flow-Controlled Communication: Here the flow control strategy is used in which the sender remains blocked until the receiver starts accepting some messages so that space is created in the buffer for new messages. This strategy rules out the asynchronous mode of communication by blocking the sender and thus results in unexpected deadlocks.

The allocation of buffer space is dependent on implementation. On the receiving side, the receiver holds messages in the mailbox which is located either in the kernel's address space or at the receiving side in the receiver's process address space.