Remote Procedure Call (RPC)

Slides:



Advertisements
Similar presentations
RPC Robert Grimm New York University Remote Procedure Calls.
Advertisements

Remote Procedure Call Design issues Implementation RPC programming
CCNA – Network Fundamentals
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Tam Vu Remote Procedure Call CISC 879 – Spring 03 Tam Vu March 06, 03.
Computing Systems 15, 2015 Next up Client-server model RPC Mutual exclusion.
Distributed Object & Remote Invocation Vidya Satyanarayanan.
Remote Procedure CallCS-4513, D-Term Remote Procedure Call CS-4513 Distributed Computing Systems (Slides include materials from Operating System.
Slide 1 Client / Server Paradigm. Slide 2 Outline: Client / Server Paradigm Client / Server Model of Interaction Server Design Issues C/ S Points of Interaction.
Tutorials 2 A programmer can use two approaches when designing a distributed application. Describe what are they? Communication-Oriented Design Begin with.
CS533 - Concepts of Operating Systems 1 Remote Procedure Calls - Alan West.
OCT 1 Master of Information System Management Organizational Communications and Distributed Object Technologies Lecture 5: Distributed Objects.
Outcomes What is RPC? The difference between conventional procedure call and RPC? Understand the function of client and server stubs How many steps could.
Remote Procedure Calls. 2 Client/Server Paradigm Common model for structuring distributed computations A server is a program (or collection of programs)
.NET Mobile Application Development Remote Procedure Call.
Chapter 5: Distributed objects and remote invocation Introduction Remote procedure call Events and notifications.
CSE 486/586 CSE 486/586 Distributed Systems Remote Procedure Call Steve Ko Computer Sciences and Engineering University at Buffalo.
Communication Tran, Van Hoai Department of Systems & Networking Faculty of Computer Science & Engineering HCMC University of Technology.
CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered: Distributed Computing Fundamentals.
CS425 /CSE424/ECE428 – Distributed Systems – Fall Nikita Borisov - UIUC1 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S.
Chapter 4: Interprocess Communication‏ Pages
Lecture 15-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2010 Indranil Gupta (Indy) October 12, 2010 Lecture 15 RPCs and Distributed.
RPC Design Issues Presented By Gayathri Vijay S-8,CSE.
Politecnico di Milano © 2001 William Fornaciari Operating Systems R P C Remote Procedure Call Lecturer: William Fornaciari Politecnico di Milano
1 Lecture 5 (part2) : “Interprocess communication” n reasons for process cooperation n types of message passing n direct and indirect message passing n.
 Remote Procedure Call (RPC) is a high-level model for client-sever communication.  It provides the programmers with a familiar mechanism for building.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved RPC Tanenbaum.
IS473 Distributed Systems CHAPTER 5 Distributed Objects & Remote Invocation.
REQUEST/REPLY COMMUNICATION
Page 1 Remote Procedure Calls Paul Krzyzanowski Distributed Systems Except as otherwise noted, the content of this presentation.
Chapter 5: Distributed objects and remote invocation Introduction Remote procedure call Events and notifications.
 Communication Distributed Systems IT332. Outline  Fundamentals  Layered network communication protocols  Types of communication  Remote Procedure.
Distributed Objects & Remote Invocation
Distributed Objects and Remote Invocation Source: George Colouris, Jean Dollimore, Tim Kinderberg & Gordon Blair (2012). Distributed Systems: Concepts.
Remote Procedure Call Andy Wang Operating Systems COP 4610 / CGS 5765.
1 Conventional Procedure Call read(fd,buf,nbytes) a)Parameter passing in a local procedure call: the stack before the call to read b)The stack while the.
Remote Procedure Call RPC
Mark Stanovich Operating Systems COP Primitives to Build Distributed Applications send and receive Used to synchronize cooperating processes running.
09/14/05 1 Implementing Remote Procedure Calls* Birrell, A. D. and Nelson, B. J. Presented by Emil Constantinescu *ACM Trans. Comput. Syst. 2, 1 (Feb.
Lecture 4 Mechanisms & Kernel for NOSs. Mechanisms for Network Operating Systems  Network operating systems provide three basic mechanisms that support.
Manish Kumar,MSRITSoftware Architecture1 Remote procedure call Client/server architecture.
Reliable Client-Server Communication. Reliable Communication So far: Concentrated on process resilience (by means of process groups). What about reliable.
Computer Science Lecture 3, page 1 CS677: Distributed OS Last Class: Communication in Distributed Systems Structured or unstructured? Addressing? Blocking/non-blocking?
Implementing Remote Procedure Calls Andrew D. Birrell and Bruce Jay Nelson Xerox Palo Alto Research Center Published: ACM Transactions on Computer Systems,
Remote Procedure Call (Introduction)
Distributed objects and remote invocation Pages
© Oxford University Press 2011 DISTRIBUTED COMPUTING Sunita Mahajan Sunita Mahajan, Principal, Institute of Computer Science, MET League of Colleges, Mumbai.
Distributed Systems Lecture 8 RPC and marshalling 1.
1 Network Communications A Brief Introduction. 2 Network Communications.
Computer Science Lecture 4, page 1 CS677: Distributed OS Last Class: RPCs RPCs make distributed computations look like local computations Issues: –Parameter.
Distributed Computing & Embedded Systems Chapter 4: Remote Method Invocation Dr. Umair Ali Khan.
Process-to-Process Delivery:
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Topic 3: Remote Invocation Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Distributed Web Systems Distributed Objects and Remote Method Invocation Lecturer Department University.
Object Interaction: RMI and RPC 1. Overview 2 Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products.
Object Interaction: RMI and RPC 1. Overview 2 Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products.
Client-Server Communication
03 – Remote invoaction Request-reply RPC RMI Coulouris 5
Prof. Leonardo Mostarda University of Camerino
CMSC621: Advanced Operating Systems Advanced Operating Systems
DISTRIBUTED COMPUTING
Distributed Systems CS
Distribution Infrastructures
Remote Procedure Call Hank Levy 1.
Remote invocation (call)
Remote Procedure Call Hank Levy 1.
Distributed Systems CS
Remote Procedure Call Hank Levy 1.
Last Class: Communication in Distributed Systems
Presentation transcript:

Remote Procedure Call (RPC) An extension of conventional procedure call (used for transfer of control and data within a single process) allows a client application to call procedures in a different address space in the same or remote machine ideal for the client-server modeled applications primary goal is to make distributed programming easy, which is achieved by making the semantics of RPC as close as possible to conventional local procedure call what is the semantics of local procedure call?

Local vs. Remote Procedure Calls

RPC Communication

RPC System Components Message module IPC module of Send/Receive/Reply responsible for exchanging messages Stub procedures (client and server stubs) a stub is a communications interface that implements the RPC protocol and specifies how messages are constructed and exchanged responsible for packing and unpacking of arguments and results (this is also referred to as “marshaling”) these procedures are automatically generated by “stub generators” or “protocol compilers” (more later)

Client stub packs the arguments with the procedure name or ID into a message sends the msg to the server and then awaits a reply msg unpacks the results and returns them to the client Server stub receives a request msg unpacks the arguments and calls the appropriate server procedure when it returns, packs the result and sends a reply msg back to the client

RPC System Components and Call Flows

RPC Design Issues Parameter Passing in conventional calls: pass by-value and pass by-reference possible in RPC: pass by-value only (why?) pointers (addresses) are meaningless in a separate address space Also called copy-in/copy-out parameter passing Single vs. multiple input and output parameters

Transport Support for RPC RPC mechanisms can be built on top of either connection oriented (reliable) or connectionless (unreliable) transport service (e.g., on top of TCP or UDP) most RPC implementations allow the user to choose the underlying transport service why is the connectionless transport service more desirable for supporting RPCs? RPC messages are generally short and overhead involved with connections may be undesirable Servers generally serve a large number of clients and maintaining state information on connections may be undesirable LANs are generally reliable

RPC Interface Definition Language and Compiler an interface definition language (IDL) is used to define the interfaces of procedures provided by a server an interface contains a list of procedure signatures include names of the procedures plus the types of their input and output parameters the client and server procedures are type checked against interface definitions interface compiler (or stub generator) generates client and server stubs automatically

RPC Semantics during a RPC, problems may occur: Request msg may be lost Reply msg may be lost Server & client may crash  in the last two cases, the procedure may have been called (What are possible consequences?)

Some strategies for different RPC msg delivery guarantees Retry request message - retransmit the request msg until either a reply is received or the server is assumed to have failed Duplicate filtering - filtering duplicate requests at the server when retransmissions are used Retransmission of replies - keep a history of reply messages to enable lost replies to be retransmitted without re-executing the server operations

RPC mechanisms usually include timeouts to prevent clients waiting indefinitely for reply msgs RPC call semantics “maybe” call semantics “at-least-once” call semantics “at-most-once call semantics no retransmission of request messages not certain whether the procedure has been executed no fault-tolerance measures generally not acceptable

2. “at-least-once” call semantics the msg module repeatedly resends request msg after timeouts until it either gets a reply msg or some max. # of retries have been made no duplicate request msg filtering the remote procedure is called at least once if server not down the client does not know how many times the remote procedure has been called unless the called procedure is “idempotent” (i.e., repeatable), this could produce undesirable results (e.g., money transfer)

3. “at-most-once” call semantics retransmission of request messages duplicate request msg filtering if the server does not crash and the client receives the result of a call, then the procedure has been called exactly once otherwise, an exception is reported and the procedure will have been called wither once or not at all this works for both idempotent and non-idempotent operations more complex support required due to the need for request msg filtering and for keeping track of replies

Binding binding refers to determining the location and identity (communication ID) of the called procedure in UNIX: a communication ID is a socket address containing host’s Internet address and a port number static binding (which binds the host address of a server into the client program at compilation time) is undesirable (why?) The client and server programs are compiled separately and often at different times The server may be moved from one host to another dynamic binding is more desirable allows servers to register their exporting services allows servers to remove services allows clients to lookup the named service

Binder Interface Example PROCEDURE Register (serviceName:String; serverPort:Port; version:integer) causes the binder to record the service name and server port of a service in its table, together with a version number. PROCEDURE Withdraw (serviceName:String; serverPort:Port; version:integer) causes the binder to remove the service from its table. PROCEDURE LookUp (serviceName:String; version:integer): Port the binder looks up the named service and returns its address (or set of addresses) if the version number agrees with the one stored in its table.

Locating the Binding Service Clients and servers need to know where the binder is available before they can use it Some approaches for locating the binder Always run the binder on a “well-known” address (i.e., fixed host and port) what is the problem with this approach? OS supplies the current address of the binder (e.g., via environment variable in UNIX) client & server programs need not be recompiled Use a broadcast message to locate the binder the binder can be easily relocated most flexible approach

Asynchronous RPC RPC calls that do not block waiting for replies more efficient than synchronous RPC when replies are not required When no reply message is required - a client can make a RPC and proceed without waiting for the server to complete the operation - several client requests can be buffered and transmitted together When a reply message is required - a client can make a call, proceed with other operations and claim the reply later e.g., X-Window system - X Window manager as a server - X Window applications as clients

- Variation: deferred synchronous RPC: Asynchronous RPCs Essence: Try to get rid of the strict request-reply behavior, but let the client continue without waiting for an answer from the server. - Variation: deferred synchronous RPC:

Local RPCs: Doors Essence: Try to use the RPC mechanism as the only mechanism for IPC. Doors are RPCs implemented for processes on the same machine