Remote procedure calls
Download
1 / 26

Remote Procedure Calls - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

Remote Procedure Calls. Announcements. Prelim II coming up in one week: Thursday, April 26 th , 7:30—9:00pm, 1½ hour exam 101 Phillips Closed book, no calculators/PDAs/… Bring ID Topics: Since last Prelim, up to (and including) Monday, April 23 rd Lectures 19-34, chapters 10-18 (7 th ed)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Remote Procedure Calls' - maxime


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Announcements
Announcements

  • Prelim II coming up in one week:

    • Thursday, April 26th, 7:30—9:00pm, 1½ hour exam

    • 101 Phillips

    • Closed book, no calculators/PDAs/…

    • Bring ID

  • Topics:

    • Since last Prelim, up to (and including) Monday, April 23rd

    • Lectures 19-34, chapters 10-18 (7th ed)

  • Project 5 due after Prelim II, Monday, April 30th

    • Make sure to look at the lecture schedule to keep up with due dates!


Review use of tcp sockets
Review: Use of TCP: Sockets

  • Socket: an abstraction of a network I/O queue

    • Embodies one side of a communication channel

      • Same interface regardless of location of other end

      • Could be local machine (called “UNIX socket”) or remote machine (called “network socket”)

    • First introduced in 4.2 BSD UNIX: big innovation at time

      • Now most operating systems provide some notion of socket

  • Using Sockets for Client-Server (C/C++ interface):

    • On server: set up “server-socket”

      • Create socket, Bind to protocol (TCP), local address, port

      • call listen(): tells server socket to accept incoming requests

      • Perform multiple accept() calls on socket to accept incoming connection request

      • Each successful accept() returns a new socket for a new connection; can pass this off to handler thread

    • On client:

      • Create socket, Bind to protocol (TCP), remote address, port

      • Perform connect() on socket to make connection

      • If connect() successful, have socket connected to server


Socket setup con t

Server

Socket

Request Connection

new

socket

socket

socket

connection

Client

Server

Socket Setup (Con’t)

  • Things to remember:

    • Connection requires 5 values:[ Src Addr, Src Port, Dst Addr, Dst Port, Protocol ]

    • Often, Src Port “randomly” assigned

      • Done by OS during client socket setup

    • Dst Port often “well known”

      • 80 (web), 443 (secure web), 25 (sendmail), etc

      • Well-known ports from 0—1023


Socket example java
Socket Example (Java)

server: //Makes socket, binds addr/port, calls listen() ServerSocket sock = new ServerSocket(6013); while(true) { Socket client = sock.accept(); PrintWriter pout = new PrintWriter(client.getOutputStream(),true); pout.println(“Here is data sent to client!”); … client.close(); }

client: // Makes socket, binds addr/port, calls connect() Socket sock = new Socket(“169.229.60.38”,6018); BufferedReader bin = new BufferedReader( new InputStreamReader(sock.getInputStream)); String line; while ((line = bin.readLine())!=null) System.out.println(line); sock.close();


Goals for today
Goals for Today

  • Implementing Distributed Applications

  • Messages

    • Send/receive

    • One vs. two-way communication

  • Remote Procedure Call


Distributed applications

Receive

Send

Network

Distributed Applications

  • How do you actually program a distributed application?

    • Need to synchronize multiple threads, running on different machines

      • No shared memory, so cannot use test&set

    • One Abstraction: send/receive messages

      • Already atomic: no receiver gets portion of a message and two receivers cannot get same message

  • Interface:

    • Mailbox (mbox): temporary holding area for messages

      • Includes both destination location and queue

      • For example, mbox is kernel buffer associated with a Socket

    • Send(message,mbox)

      • Send message to remote mailbox identified by mbox

    • Receive(buffer,mbox)

      • Wait until mbox has message, copy into buffer, and return

      • If threads sleeping on this mbox, wake up one of them


Using messages send recv behavior
Using Messages: Send/Recv behavior

  • When should send(message,mbox) return?

    • When receiver gets message? (i.e. ack received)

    • When message is safely buffered on destination?

    • Right away, if message is buffered on source node?

  • Actually two questions here:

    • When can the sender be sure that receive actually received the message?

    • When can sender reuse the memory containing message?

  • Mailbox provides 1-way communication from P1P2

    • P1bufferP2

    • Very similar to producer/consumer

      • Send = V (i.e. signal)

      • Receive = P (i.e. wait)

      • However, can’t tell if sender/receiver is local or not!


Messages for producer consumer
Messages for Producer-Consumer

  • Using send/receive for producer-consumer style:

    Producer: int msg1[1000]; while(1) { prepare message; send(msg1,mbox); }

    Consumer: int buffer[1000]; while(1) { receive(buffer,mbox); process message; }

  • No need for producer/consumer to keep track of space in mailbox: handled by send/receive

    • One of the roles of the window in TCP: window is size of buffer on far end

    • Restricts sender to forward only what will fit in buffer

Send

Message

Receive

Message


Messages for req resp comm
Messages for Req/Resp comm.

  • What about two-way communication?

    • Request/Response

      • Read a file stored on a remote machine

      • Request a web page from a remote web server

    • Also called: client-server

      • Client  requester, Server  responder

      • Server provides “service” (file storage) to the client

  • Example: File service

    Client: (requesting the file) char response[1000]; send(“read rutabaga”, server_mbox); receive(response, client_mbox);

    Server: (responding with the file) char command[1000], answer[1000]; receive(command, server_mbox); decode command; read file into answer; send(answer, client_mbox);

Request

File

GetResponse

Receive

Request

Send

Response


Client server paradigm
Client/Server Paradigm

  • Common model for structuring distributed computations

  • A server is a program (or collection of programs) that

    • provides some service, e.g., file service, name service, …

    • may exist on one or more nodes.

  • A client is a program that uses the service.

    • It first binds to the server,

      • i.e., locates it in the network and establishes a connection.

  • The client then sends requests to perform actions;

    • Using messages to indicate the desired service and params.

    • The server returns a response.


Why not use messages
Why not use messages?

  • Although messages are flexible, they have problems:

    • Requires that programmer worry about message formats

    • Messages must be packed and unpacked

    • Server needs to decode messages to figure out the request

    • Messages are often asynchronous

    • They may require special error handling functions

  • Basically using messages is not a convenient paradigm for most programmers.


Procedure call
Procedure Call

  • More natural way is to communicate using procedure calls:

    • every language supports it

    • semantics are well defined and understood

    • natural for programmers to use

  • Basic idea: define server as a module that exports a set of procedures callable by client programs.

  • To use the server, the client just does a procedure call, as if it were linked with the server

call

Client

Server

return


Remote procedure call
(Remote) Procedure Call

  • So, we would like to use procedure call as a model for distributed communication.

  • Lots of issues:

    • how do we make this invisible to the programmer?

    • what are the semantics of parameter passing?

    • how is binding done (locating the server)?

    • how do we support heterogeneity (OS, arch., language)

    • etc.


Remote procedure call1
Remote Procedure Call

  • The basic model for Remote Procedure Call (RPC) was described by Birrell and Nelson in 1980, based on work done at Xerox PARC.

  • Goal to make RPC as much like local PC as possible.

  • Used computer/language support.

  • There are 3 components on each side:

    • a user program (client or server)

    • a set of stub procedures

    • RPC runtime support


RPC

  • Basic process for building a server:

    • Server program defines the server’s interface using an interface definition language (IDL)

    • The IDL specifies the names, parameters, and types for all client-callable server procedures

    • A stub compiler reads the IDL and produces two stub procedures for each server procedure: a client-side stub and a server-side stub

    • The server writer writes the server and links it with the server-side stubs; the client writes her program and links it with the client-side stubs.

    • The stubs are responsible for managing all details of the remote communication between client and server.


Rpc stubs
RPC Stubs

  • Client-side stub is a procedure that looks to the client as if it were a callable server procedure.

  • Server-side stub looks like a calling client to the server

  • The client program thinks it is calling the server;

    • in fact, it’s calling the client stub.

  • The server program thinks it’s called by the client;

    • in fact, it’s called by the server stub.

  • The stubs send messages to each other to make RPC happen.


Rpc call structure
RPC Call Structure

proc foo(a,b)

begin foo...

end foo

client

program

client makes

local call to

stub proc.

server is

called by

its stub

server

program

call foo(x,y)

call foo

call foo

stub unpacks

params and

makes call

client

stub

proc foo(a,b)

stub builds msg

packet, inserts

params

call foo(x,y)

server

stub

send msg

msg received

runtime sends

msg to remote

node

runtime

receives msg

and calls stub

RPC

runtime

RPC

runtime

Call


Rpc return structure
RPC Return Structure

proc foo(a,b)

begin foo...

end foo

client

program

server

program

server proc

returns

call foo(x,y)

client continues

return

return

stub builds

result msg

with output

args

client

stub

proc foo(a,b)

stub unpacks

msg, returns

to caller

call foo(x,y)

server

stub

msg received

send msg

runtime

responds

to original

msg

runtime

receives msg,

calls stub

RPC

runtime

RPC

runtime

return


Rpc information flow

marshal

args

call

send

Client

Stub

return

receive

Network

Network

return

send

Server

Stub

call

receive

unmarshal

args

RPC Information Flow

Client

(caller)

RPC

Runtime

unmarshal

ret vals

mbox2

Machine A

Machine B

marshal

return values

mbox1

Server

(callee)

RPC

Runtime


Rpc binding
RPC Binding

  • Binding is the process of connecting the client and server

  • The server, when it starts up, exports its interface,

    • identifying itself to a network name server and

    • telling the local runtime its dispatcher address.

  • The client, before issuing any calls, imports the server,

    • which causes the RPC runtime to lookup the server through the name service and

    • contact the requested server to setup a connection.

  • The import and export are explicit calls in the code.


Rpc marshalling
RPC Marshalling

  • Marshalling is packing of procedure params into message packet.

  • RPC stubs call type-specific procedures to marshall (or unmarshall) all of the parameters to the call.

  • On client side, client stub marshalls parameters into call packet;

    • On the server side the server stub unmarshalls the parameters to call the server’s procedure.

  • On return, server stub marshalls return parameters into return packet;

    • Client stub unmarshalls return params and returns to the client.


Problems with rpc
Problems with RPC

  • Non-Atomic failures

    • Different failure modes in distributed system than on a single machine

    • Consider many different types of failures

      • User-level bug causes address space to crash

      • Machine failure, kernel bug causes all processes on same machine to fail

      • Some machine is compromised by malicious party

    • Before RPC: whole system would crash/die

    • After RPC: One machine crashes/compromised while others keep working

    • Can easily result in inconsistent view of the world

      • Did my cached data get written back or not?

      • Did server do what I requested or not?

    • Answer? Distributed transactions/Byzantine Commit

  • Performance

    • Cost of Procedure call « same-machine RPC « network RPC

    • Means programmers must be aware that RPC is not free

      • Caching can help, but may make failure handling complex


Cross domain comm location transparency
Cross-Domain Comm./Location Transparency

  • How do address spaces communicate with one another?

    • Shared Memory with Semaphores, monitors, etc…

    • File System

    • Pipes (1-way communication)

    • “Remote” procedure call (2-way communication)

  • RPC’s can be used to communicate between address spaces on different machines or the same machine

    • Services can be run wherever it’s most appropriate

    • Access to local and remote services looks the same

  • Examples of modern RPC systems:

    • CORBA (Common Object Request Broker Architecture)

    • DCOM (Distributed COM)

    • RMI (Java Remote Method Invocation)


Microkernel operating systems

App

App

App

App

File

sys

windows

file system

address

spaces

Windowing

RPC

VM

Networking

threads

Threads

Microkernel Structure

Monolithic Structure

Microkernel operating systems

  • Example: split kernel into application-level servers.

    • File system looks remote, even though on same machine

  • Why split the OS into separate domains?

    • Fault isolation: bugs are more isolated (build a firewall)

    • Enforces modularity: allows incremental upgrades of pieces of software (client or server)

    • Location transparent: service can be local or remote

      • For example in the X windowing system: Each X client can be on a separate machine from X server; Neither has to run on the machine with the frame buffer.


Summary
Summary

  • Remote Procedure Call (RPC): Call procedure on remote machine

    • Provides same interface as procedure

    • Automatic packing and unpacking of arguments without user programming (in stub)

  • RPC is most common model now for communications in distributed applications.

    • It is language support for distributed programming.

  • RPC relies on a stub compiler to automatically produce client/server stubs from the IDL server description.

  • RPC is commonly used, even on a single node, for communication between applications running in different address spaces. In fact, most RPCs are intra-node.


ad