Remote Procedure Call in Distributed systems, Lecture notes of Distributed Programming and Computing

Remote Procedure Call (RPC) is a mechanism that allows distributed applications to communicate with each other across a network, as if they were running on the same machine. It is a fundamental building block of modern distributed systems, allowing programs to transparently invoke functions or methods on a remote machine, without the need for the caller to have any knowledge of the underlying network protocols or details.

Typology: Lecture notes

2022/2023

Available from 04/13/2023

abdel-halim-mansour
abdel-halim-mansour 🇪🇬

3 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Remote Procedure Call
As was mentioned in Chapter 2, the idea of a remote procedure call
(RPC) represents a significant intellectual advance in distributed
computing with the aim of achieving a high level of distribution
transparency and making the programming of distributed systems look
similar, if not identical, to conventional programming. By extending the
abstraction of a procedure call to distributed contexts, this unification is
accomplished in a fairly straightforward manner. Particularly with RPC,
it is possible to invoke distant machine processes as if they were local
address space procedures. Hence, crucial components of distribution,
such as the encoding and decoding of arguments and results, the
transmission of messages, and the preservation of the necessary
semantics for the procedure call, are hidden by the underlying RPC
system. This notion was initially developed by Birrell and Nelson [1984]
and opened the way for many of the innovations in distributed systems
programming employed today.
Design issues for RPC
We examine three topics that are crucial to comprehending RPC
systems before examining their implementation:
programming using interfaces, a method of programming
favoured by RPC;
the RPC-related call semantics;
The crucial matter of openness and how it relates to distance
medical consultations
pf3
pf4

Partial preview of the text

Download Remote Procedure Call in Distributed systems and more Lecture notes Distributed Programming and Computing in PDF only on Docsity!

Remote Procedure Call

As was mentioned in Chapter 2, the idea of a remote procedure call (RPC) represents a significant intellectual advance in distributed computing with the aim of achieving a high level of distribution transparency and making the programming of distributed systems look similar, if not identical, to conventional programming. By extending the abstraction of a procedure call to distributed contexts, this unification is accomplished in a fairly straightforward manner. Particularly with RPC, it is possible to invoke distant machine processes as if they were local address space procedures. Hence, crucial components of distribution, such as the encoding and decoding of arguments and results, the transmission of messages, and the preservation of the necessary semantics for the procedure call, are hidden by the underlying RPC system. This notion was initially developed by Birrell and Nelson [1984] and opened the way for many of the innovations in distributed systems programming employed today.

Design issues for RPC

We examine three topics that are crucial to comprehending RPC systems before examining their implementation:

  • programming using interfaces, a method of programming favoured by RPC;
  • the RPC-related call semantics;
  • The crucial matter of openness and how it relates to distance medical consultations

Programming with interfaces The majority of contemporary programming languages offer a way to structure a program as a collection of interconnected modules. Procedure calls between modules or direct access to the variables in another module are two ways that modules might communicate with one another. Each module has an explicit interface established in order to govern potential interactions between them. The procedures and variables that may be accessible from other modules are specified in a module's interface. When a module is implemented, all information about it outside what can be accessed through its interface is hidden. The implementation of the module may be modified without having any impact on the module's users as long as its interface stays the same. Interfaces in distributed systems: The modules of a distributed program might function as independent processes. Particularly under the client-server architecture, each server makes a set of operations accessible to clients. For example, a file server might provide protocols for reading and writing files. The specification of the procedures provided by a server, which specifies the kinds of arguments used in each operation, is referred to as a service interface. Programming using interfaces in distributed systems has a variety of advantages because of the crucial distinction between interface and implementation:

  • When the caller and procedure are in different processes, the parameter-passing techniques used in local procedure calls, such as call by value and call by reference, are ineffective. Call by reference in particular is not supported. Instead, the parameters are described as input, output, or occasionally both, in the definition of a procedure in the interface of a module in a distributed application. By delivering the values of the arguments in the request message and then including them as arguments in the operation to be conducted in the server, input parameters are sent to the remote server. As a consequence of the call or to swap out the values of the associated variables in the calling environment, output parameters are returned in the reply message. A parameter's value must be sent in both the request and reply messages when it is used for both input and output.
  • Another distinction between local and remote modules is that addresses in one process are not valid in another remote one. Addresses thus cannot be returned as a result of calls to remote modules or supplied as an input. As will be covered in the following lecture note, these restrictions have a substantial effect on the specification of interface definition languages.