Skip to main content

Access transparency and modern RPC

Short answer

Access transparency means local and remote resources are accessed identically. Conventional RPC breaks it due to different call syntax, value-only parameters, new failure modes, and heterogeneous data. Modern RPC restores it by using IDL-generated stubs with standard data representation, dynamic binding, deep copy of parameters, and mapping failures to exceptions.

Define transparency in distributed system. Give the reason for "access transparency is not maintained by conventional RPC". How can it be solved? Explain in detail the modern RPC procedure.

Transparency

Transparency is the hiding of the separation of components of a distributed system so that it looks like a single system. Access transparency means that local and remote resources are accessed using identical operations.

Why conventional RPC does not maintain access transparency

  • The remote call syntax is different: the programmer must call special RPC library routines, define interfaces and manually bind to the server.
  • Parameters are only passed by value; pointers, references and global variables cannot be used since address spaces differ.
  • The programmer must deal with new failures (server crash, lost messages, timeouts) which do not exist in local calls.
  • Different data representation on heterogeneous machines must be handled by the programmer in some cases.
  • Latency and call semantics (at-least-once) differ from the exactly-once of a local call.

How it is solved: modern RPC

Modern RPC (DCE RPC, ONC+, and RPC in Java/CORBA) makes the remote call look like a local one.

  1. An IDL describes the interface, and an IDL compiler automatically generates the stubs, which hide marshalling and communication.
  2. Standard data representation (NDR/XDR) removes differences between machines.
  3. Dynamic binding through a directory service gives location transparency.
  4. Complex parameters and pointers are passed by copying the data referenced (deep copy) or by remote references.
  5. Exception handling and at-most-once semantics map failures to errors in the language.
  6. Threads, asynchronous RPC and security services.

Modern RPC procedure

 Client app -> client stub -> RPC runtime ==network==>
 RPC runtime -> server stub -> server procedure
  1. At development time, the IDL file is compiled to the client stub, server stub and header.
  2. At start, the server registers its interface and endpoint with the directory service/binder.
  3. The client stub locates the server through the binder (dynamic binding).
  4. The client calls the procedure; the stub marshals the parameters into a message in standard format.
  5. The runtime sends the call with a call id, with timeouts and retransmission.
  6. The server runtime filters duplicates, passes it to the server stub, which unmarshals and calls the procedure (in a server thread).
  7. The result is marshalled and returned; the client stub unmarshals and returns it, or raises an exception.

✓ Answer checked by Claude Opus 5.5 (high effort)

Related questions

All Distributed System chapter 2 questions →