100 likes | 199 Views
Phones OFF Please. IPC (Remote Procedure Call) Parminder Singh Kang Home: www.cse.dmu.ac.uk/~pkang Email: pkang@dmu.ac.uk. RPC
E N D
Phones OFF Please IPC (Remote Procedure Call) Parminder Singh Kang Home: www.cse.dmu.ac.uk/~pkang Email: pkang@dmu.ac.uk
RPC • RPC is similar mechanism as IPC; it is a way to abstract the procedure call mechanism for systems with network connections (I.e. processes executes on different machines). • RPC system does this by providing Stub on client side. There a separate stub exists for each separate remote procedure. • On calling a remote procedure, RPC system calls appropriate Stub and provide parameters. • And finally stub locates port on server and marshalls the parameters. • Note: communication details are hidden in RPC.
2. WHY RPC? • distributed systems are built around a client/server model. • Clients and Servers on different machines and communicate across a network • Use message passing with send/receive; is I/O oriented and quite complex. • e.g. using TCP (virtual circuit) or UDP (datagram); • TCP – set up the virtual circuit connection to a specified IP and port, set the • data in the appropriate form, and then close the connection. • UDP – create the datagram (e.g. an array of bytes) and send it to a specified IP • and port number • Remote procedure call: the client makes a call to a server for some service • and waits until the reply comes back. • In practice the call looks like a normal program function or procedure call.
Procedure call looks like: • dosomething(a, b, c);------- parameters --------> procedure dosomething • <--------- results returned ---------- • With RPC the procedure will be executed on a remote machine. • The procedure call looks like a normal procedure call in your program. • The call has to go somewhere, though. It goes to a dummy procedure called a (client) stub.
User program Dosomething Procedure Client stub Server Stub Server Process Client Machine Network Server Machine • The stubs implement RPC using message passing; • The user programs calls dosomething with parameters like a normal • program procedure. • The client stub procedure gets the parameters off the stack, builds them • into a network message and sends it off on to the network. • At the other end, the server has a stub which takes the message, unpacks • the parameters, builds it into a procedure call and calls the real dosomething • in the server, e.g. print a file, get data from a database, etc. • When dosomething returns, it returns to the server stub, which packs the • results back into a message and sends it to the client stub.
The client stub unpacks the message and builds a stack frame • and returns to the user program. • The user program takes the results off the stack and continues. • The stubs are normally generated for by a special interface • compiler (e.g. RMIC in Java). • You have to specify the interface to the interface compiler. • The interface contains details of the procedures the server is • supplying and their parameters. • The parameters can be input, output, or input-output.
3. Packing Parameters • This is known as parameter marshalling. • Several procedures can be called on server. • e.g. read something, write something, etc., so we need to send the procedure • name we want to call in the network packet along with the parameters.
5. Problems • Problems can arise if the machines on the network are not all the same type. • Might use different character sets e.g. ASCII v EBCDIC. • Might store multi-byte integers differently. little endian/big endian • Little endian big endian • byte 1 | 0 byte 1 | 0 • 1 2 | 3 4 3 4 | 1 2 • Variable may be different lengths • Floating point - even more variation, IEEE format. • Global variables - not in parameter list. Either prohibit or pass specially. • Using TCP or UDP the programmer usually has to sort this out – in Java this • is done automatically using Serialization.
7. Failures • Client cannot locate server • Message from client to server gets lost • Reply from server to client gets lost • Client crashes after sending message. • Server crashes after receiving message
8. Three scenarios :- • ------- ------- ------- • request -->| receive | request -->| receive | request -->| receive | • | execute | | execute | | crash | • reply <--| reply | ???? <--| crash | ???? <--| ???? | • ------- ------- ------- • (a) (b) (c) • With (a) all works OK, no problems. • With (b) client doesn't want to repeat the operation • With (c) client wants to repeat the operation.