Problems with Send and Receive
• Low level
– programmer is engaged in I/O
– server often not modular
– takes 2 calls to get what you want (send, followed by receive) — error prone
• Solution
– use procedure calls — familiar model
Remote Procedure Call (RPC)
• Allow procedure calls to other machines
– servicing of procedure remote
– caller blocks until procedure finished, as usual – simpler than explicit message passing
• Complications
– caller and receiver in different address spaces
– parameter passing
– where is the server? – what about crashes?
}
Recall: Programming Client/Server Applications (General Outline)
Outline of Client code while (1) {
Outline of Server code while (1) {
receive(request) switch(request) case type1:
send(client, reply1) case type2:
send(client, reply2) etc.
build request send(request, server) receive(reply)
do something
}
Programming Client/Server Applications with RPC
Outline of Client code while (1) {
build request
reply = foo(params) do something
}
Note: Server is written as collection of several procedures
Outline of Server code foo(params) {
….
return reply1; }
bar (params) { ….
return reply2; }
Basics of RPC Implementation
• Goal: provide complete transparency
– For RPC, replace a normal procedure call with:
• pack arguments (including func) into a message via “stub function”
– may need to worry about byte ordering, linked list, etc
• send message to server; block waiting for reply
– implemented via explicit message passing
Picture of Stub Function
Basics of RPC Implementation
• Goal: provide complete transparency
– On receipt at server: unpack and push parameters onto the stack, call function (create new thread)
• Implemented by forking a “stub” (sometimes called “skeleton” function)
– On receipt of reply at client: put result where it belongs, unblock client
RPC Implementation Issues
• Weakly typed languages
– E.g., C — what to do if unbounded array passed to RPC?
– Pointers across different machines?
• Communication via global variables impossible
• Binding
– How does client know where server is? • Onesolution:useadatabase
• Failures?
– What if function is partially executed, or executed twice, or executed never?
RPC Parameter Passing
• Client machine may be a different architecture than server
– we will ignore this issue – one side must convert data if byte ordering is an issue
• Parameter issues
– what parameter passing style should be provided? – can be important performance issue
– not as easy as it seems at first glance
Call by Value
• Simple semantics
• Just package up the args, and send them
– can be problematic (efficiency-wise) if pointer parameter points to a complex data type, e.g. graph or list
• Server uses these args
– doesn’t need to send them back
Call by Reference
• What do pointers mean across machines?
– remember, they mean nothing across address spaces
• Could send back message to client on each reference
• SLOW!
Call by Copy/Restore
• Similar to call by reference
– parameter copied in, same as call by value
• same disadvantages of having to copy entire structures
– but when procedure finished, copy back to caller
– not quite same as call by reference:
– method of choice for “reference parameters” when using RPC
(Contrived) example of how call by reference and call by copy- restore can differ
int a; foo(int x) {
x = 2; a = 0; }
int main( ) {
a = 1; foo(a); print(a)
}
Call by reference outputs 0; call by copy-restore outputs 2
Rendezvous
• Similar to RPC
– Key difference: no new process created on the
server (but unlike RPC, there is synchronization)
– Caller side is the same as with RPC
– Server looks roughly as follows: in op1(…)
execute code for op1 [] op2(…)
execute code for op2 ni
– Server blocks until >= 1 pending invocation on any op (can be implemented via UNIX select)
Bank Account Problem: Picture
Bank Account with RPC
module Customer
deposit(amt) or withdraw(amt) // these are RPCs
monitor Bank
void deposit(int)
void withdraw(int)
int balance = INIT_BALANCE, cond try
void deposit(int amt) balance += amt broadcast(try)
void withdraw(int amt) while (amt > balance)
wait(try) balance -= amt
Note: deposit and withdraw need to be monitor functions
Bank Account with Rendezvous
module Customer
deposit(amt) or withdraw(amt) // also remote invocations
module Bank // just a class—not a monitor! void deposit(int)
void withdraw(int)
int balance = INIT_BALANCE
process Teller { while (true)
in deposit(amt) balance += amt
[] withdraw(amt) and balance >= amt balance -= amt
ni }