1 / 13

Problems with Send and Receive

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

strom
Download Presentation

Problems with Send and Receive

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

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

  3. Outline of Client code while (1) { build request reply = foo(params) do something } Note: Server can be written as collection of several procedures Outline of Server code foo(params) { …. return reply; } bar (params) { …. return reply; } Programming Client/Server Applications with RPC

  4. 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 • On receipt at server: unpack and push args, call func. (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

  5. RPC Implementation Issues • Weakly typed languages • E.g., C --- what to do if unbounded array passed to RPC? • Communication via global variables impossible • Binding • How does client know where server is? • One solution: use a database • Failures? • What if function is partially executed, or executed twice, or executed never?

  6. RPC Parameter Passing • Client machine may be different than server • ignore this issue -- someone has to convert data • Parameter issues • what to provide? • can be important performance issue • not as easy as it seems at first glance

  7. Call by Value • Simple semantics • Just package up the args, and sent them • Server uses these args • doesn’t need to send them back

  8. Call by Reference • What do pointers mean across machines? • remember, they mean nothing across address spaces • Could do the following: • pass pointer • send back message to client on each reference • SLOW!

  9. Call by Copy/Restore • Similar to call by reference • parameter copied in, same as call by value • but when procedure finished, copy back to caller • not quite same as call by reference, but: • can be problematic if pointer parameter points to a complex data type, e.g. graph or list • method of choice for “reference parameters” when using RPC

  10. (Contrived) example of how call by reference and call by copy- restore can differ inta; unsafe(int x) { x= 2; a= 0; } int main( ) { a= 1; unsafe(a); print (a) } Call by reference outputs 0; call by copy-restore outputs 2

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

  12. Bank Account with RPC module Customer deposit(amt) or withdraw(amt) module Bank void deposit(int) void withdraw(int) int balance = initbalance, cond try deposit(int amt) balance += amt broadcast(try) withdraw(int amt) while (amt > balance) wait(try) balance -= amt Note: deposit and withdraw need to be monitor functions

  13. Bank Account with Rendezvous module Customer deposit(amt) or withdraw(amt) module Bank void deposit(int) void withdraw(int) int balance = initbalance process Teller { while (true) in deposit(amt) balance += amt [] withdraw(amt) and balance >= amt balance -= amt ni }

More Related