1 / 10

Phones OFF Please

Phones OFF Please. IPC (Remote Procedure Call) Parminder Singh Kang Home: www.cse.dmu.ac.uk/~pkang Email: pkang@dmu.ac.uk. RPC

Download Presentation

Phones OFF Please

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Phones OFF Please IPC (Remote Procedure Call) Parminder Singh Kang Home: www.cse.dmu.ac.uk/~pkang Email: pkang@dmu.ac.uk

  2. 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.

  3. 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.

  4.  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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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

  10. 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.

More Related