Remote Procedure Calls

1
Remote Procedure Calls
2
Announcements

• Prelim II coming up in one week
• Thursday, April 26th, 730900pm, 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!

3
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

4
Socket Setup (Cont)

• 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 01023

5
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()

6
Goals for Today

• Implementing Distributed Applications
• Messages
• Send/receive
• One vs. two-way communication
• Remote Procedure Call

7
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 testset
• 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

8
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, cant tell if sender/receiver is local
  or not!

9
Messages for Producer-Consumer

• Using send/receive for producer-consumer style
• Producer int msg11000 while(1)
  prepare message send(msg1,mbox)
• Consumer int buffer1000 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
10
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
  response1000 send(read rutabaga,
  server_mbox) receive(response, client_mbox)
• Server (responding with the file) char
  command1000, answer1000 receive(command,
  server_mbox) decode command read file into
  answer send(answer, client_mbox)

Request File
GetResponse
Receive Request
Send Response
11
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.

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

13
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
14
(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.

15
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

16
RPC

• Basic process for building a server
• Server program defines the servers 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.

17
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, its calling the client stub.
• The server program thinks its called by the
  client
• in fact, its called by the server stub.
• The stubs send messages to each other to make RPC
  happen.

18
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
proc foo(a,b)
call foo(x,y)
client stub
stub builds msg packet, inserts params
server stub
send msg
msg received
runtime sends msg to remote node
runtime receives msg and calls stub
RPC runtime
RPC runtime
Call
19
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
proc foo(a,b)
call foo(x,y)
client stub
stub unpacks msg, returns to caller
server stub
msg received
send msg
runtime responds to original msg
runtime receives msg, calls stub
RPC runtime
RPC runtime
return
20
RPC Information Flow
Client (caller)
RPC Runtime
unmarshal ret vals
mbox2
Machine A
Machine B
marshal return values
mbox1
Server (callee)
RPC Runtime
21
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.

22
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 servers procedure.
• On return, server stub marshalls return
  parameters into return packet
• Client stub unmarshalls return params and returns
  to the client.

23
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

24
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)
• RPCs can be used to communicate between address
  spaces on different machines or the same machine
• Services can be run wherever its 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)

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

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