Please enable JavaScript.
Coggle requires JavaScript to display documents.
Remote Procedure Calls (Mechanism (Marshalling (at sender): the process of…
Remote Procedure Calls
-
Middleware Layer
-
invented to provide common services and protocols that can be used by many different applications:
• A rich set of communication protocols, but which allow different applications to communicate
• (Un)marshaling of data, necessary for integrated systems
• Naming protocols, so that different applications can easily share resources
• Security protocols, to allow different applications to communicate in a secure way
• Scaling mechanisms, such as support for replication and caching
Examples: Domain name system (DNS), authentication protocols, distributed locking protocols, remote procedure call
-
-
Regular procedure calls
Machine instructions for call & return but the compiler really makes the procedure call abstraction work
-
-
Implementing RPC
No architectural support for remote procedure calls Simulate it with tools we have (local procedure calls)
Simulation makes RPC a language-level construct instead of an operating system construct
The trick:
Create stub functions to make it appear to the user that the call is local
Stub function contains the function’s interface
Characteristics
-
The processes do not share address space.
• Passing of parameters by reference and passing pointer values are not allowed.
• Parameters are passed by values.
Called remote procedure executes within the environment of the server process.
• The called procedure does not have access to the calling procedure's (client’s) environment.
Features
• Simple call syntax
• Familiar semantics
• Well defined interface
• Ease of use
• Being able to communicate between processes on the same machine or different machines
Limitations
-
Speed: remote procedure calling (and return) time (i.e., overheads) can be significantly (1 - 3 orders of magnitude) slower than that for local procedure. • This may affect real-time design and the programmer should be aware of its impact.
Failure issues: RPC is more vulnerable to failure (why?). • The programmers should be aware of the call semantics, i.e., programs that make use of RPC must have the capability of handling errors that cannot occur in local procedure calls.
Mechanism
Marshalling (at sender): the process of taking a collection of data items and assembling them into a form suitable for transmission in a message
Unmarshalling (at receiver): the process of disassembling them on arrival to produce an equivalent collection of data items at the destination.
Marshalling and communication with server: • For each RPC, a (client) stub procedure is generated and attached to the (client) program.
-
The (codes in the) stub procedure marshals (the input) arguments and places them into a message together with the procedure identifier (of the remote procedure).
Use IPC primitive to send the (call request) message to the server and wait the reply (call return) message.
Despatching, unmarshalling, communication with client:
• A despatcher is provided. It receives the call request message from the client and uses the procedure identifier in the message to select one of the server stub procedures and passes on the arguments.
• For each procedure at the server which is declared (at the sever interface) as callable remotely, a (server) stub procedure is generated.
• The task of a server stub procedure is to unmarshal the arguments, call the corresponding (local) service procedure.
How does the server transmit the reply back?
• On return, the stub marshals the output arguments into a reply (call return) message and sends it back to the client.
How does the client receive the reply?
• The stub procedure of the client unmarshals the result arguments and returns (local call return). Note that the original remote procedure call was transformed into a (local) call to the stub procedure.
-
-