1 / 25

Remote Procedure Call

Remote Procedure Call. Outline Protocol Stack Presentation Formatting. Why Not Use UDP or TCP?. Request/reply paradigm well suited to UDP, but we need reliability

matsu
Download Presentation

Remote Procedure Call

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. Remote Procedure Call Outline Protocol Stack Presentation Formatting CS 332

  2. Why Not Use UDP or TCP? • Request/reply paradigm well suited to UDP, but we need reliability • TCP has too much overhead: going to the trouble of establishing connection, performing flow control, congestion control, etc, just too much for the exchange of a pair of messages. CS 332

  3. Client Server Blocked Request Blocked Computing Reply Blocked RPC Timeline Fromperspective of application, semantics should be identical to local procedure call CS 332

  4. Caller Callee (client) (server) Return Return Arguments Arguments value value Server Client stub stub Request Reply Request Reply RPC RPC protocol protocol RCP Components • Protocol Stack • May want layer for fragmenting and reassembling large messages • Definitely want layer for synchronizing request and reply messages • Definitely want layer for dispatching requests to the correct process • Stubs CS 332

  5. RPC Complications • Pointers • Different address spaces at caller and callee • How do you do call by reference? • Solution: Call by value-result (a.k.a. call by copy/restore) • (as per Programming Language Concepts by Gezzi and Jazayeri “In call by value-result, local variables denoting formal parameters are both initialized at subprogram call (as in call by value) and delivered upon termination (as in call by result).” • Problems of its own: two formal parameters become aliases (I.e. two different names denote same object) • A formal parameter and a nonlocal variable which is visible both by the caller and the callee become aliases CS 332

  6. RPC Complications (cont). • Example of first problem: a[i], a[j] two integer actual parameters corresponding to formal parameters x and y. Routine called at time that i = j, which make x and y aliases of same variable. At initiation of routine, assume a[i] (= a[j]) = 10. Execute: • If parameters passed as call-by-reference, then result should be that a[i]=a[j]=1 at end of routine. • If parameters passed as call by value-result, then either a[i]=a[j]=0 or a[i]=a[j]=11, depending on order in which values copied from stack into actual parameters CS 332

  7. Why a Layer for Fragmenting and Reassembly of Large Messages? • We’re not using TCP, so no guarantee of reliability • If very large packet is lost, need to resend the whole thing • Instead, might want to fragment large packets and use something like selective acknowledgements. CS 332

  8. Why Request/Reply Synchronization? • Synchronize client with server (mimic semantics of local procedure call) • Supports at-most-once semantics • Slow (long running) server or crashed server? • client periodically sends “are you alive” probe, or • server periodically sends “I’m alive” notice • Want to support multiple outstanding calls • Need a way to distinguish calls • Even perhaps mutliple calls to same procedure • Machines crash and reboot CS 332

  9. Synchronous vs Asynchronous • Question: How much does sender know after call to send() returns? • Synchronous: Application not only knows that message was received by peer, but also that peer has returned an answer • Asynchronous: Nothing (not even whether message has successfully left local machine) There’s really a continuum between these CS 332

  10. Client Server Caller Callee xCall xCallDemux SELECT SELECT xCall xCallDemux CHAN CHAN xPush xDemux xPush xDemux Dispatcher • Dispatch to appropriate procedure • Synchronous counterpart to UDP Selection (demux) Synchronization • Address Space for Procedures • flat: unique id for each possible procedure • hierarchical: program + procedure number CS 332

  11. SELECT Synch. Frags IP ETH Potential RPC Stack CS 332

  12. SunRPC • IP implements fragmentation and reassembly • except no selective retransmit • SunRPC implements syncrhonization • except no at-most-once semantics • UDP + SunRPC implement SELECT-equivalent • UDP dispatches to program (ports bound to programs) • SunRPC dispatches to procedure within program CS 332

  13. SunRPC: Identifying Remote Procedures • 32-bit program number (ex. NFS is 0x00100003) • 32-bit procedure number (read is 6, write is 8) • Mapping program numbers to port numbers • Port Mapper (0x00100000) at well known UDP port 111, procedure number 3 • Ex. NFS read(): • Client sends request to Port Mapper at UDP 111 asking that procedure 3 be invoked to map 0x00100003 to correct UDP port. Client then sends SunRPC request to returned port with procedure number 6. SunRPC module listening at this port calls read(). CS 332

  14. 0 31 0 31 XID XID MsgType = CALL MsgType = REPLY RPCVersion = 2 Status = ACCEPTED Data Program Version Procedure Credentials (variable) Verifier (variable) Data SunRPC Header Format • XID (transaction id) • Server does not remember last XID it serviced • Problem if client retransmits request while reply is in transit (because of short term memory about XID, server will interpret request as a new request) • XID memory also problem with long network delays (LANs OK) CS 332

  15. Application Application data data Presentation Presentation encoding decoding … Message Message Message Presentation Formatting • Marshalling (encoding) application data into messages • Unmarshalling (decoding) messages into application data • Data types we consider • integers • floats • strings • arrays • structs • Types of data we do not consider • images • video • multimedia documents CS 332

  16. (2) (17) (34) (126) Big- endian 00000010 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 1 1 1 1 1 1 0 (126) (34) (17) (2) Little- endian 0 1 1 1 1 1 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 0 High Low address address Difficulties • Representation of base types • floating point: IEEE 754 versus non-standard • char: ASCII or EBCDIC • integer: big-endian versus little-endian (e.g., 34,677,374) • Compiler layout of structures CS 332

  17. Taxonomy • Data types • base types (e.g., ints, floats); must convert • flat types (e.g., structures, arrays); must pack • complex types (e.g., pointers); must linearize CS 332

  18. Conversion Strategy • Canonical Intermediate Form • Settle on external representation for each data type • Lots of extra work if two system use same internal representations for data types • Receiver-makes-right • Sender sends data in its own internal representation (but typically must flatten complex data structures) • Every host must be able to convert data from all other machine architectures • An N  N solution (each of N machines must be able to handle N different architectures!) • But N is typically small, and common case is machines with same architecture • Third option: receiver-makes-right if machine knows it’s sending to a machine with the same architecture. CS 332

  19. Taxonomy (cont.) • Tagged versus untagged data • Stubs • Compiled • Faster, more common • Interpreted • Flexible CS 332

  20. eXternal Data Representation (XDR) • Defined by Sun for use with SunRPC • C type system (without function pointers) • Canonical intermediate form • Untagged (except array length) • Compiled stubs CS 332

  21. Count Name 3 7 J O H N S O N List 4 9 7 8 3 2 1 2 6 5 3 Example of rpcgen type stuff #define MAXNAME 256; #define MAXLIST 100; struct item { int count; char name[MAXNAME]; int list[MAXLIST]; }; bool_t xdr_item(XDR *xdrs, struct item *ptr) { return(xdr_int(xdrs, &ptr->count) && xdr_string(xdrs, &ptr->name, MAXNAME) && xdr_array(xdrs, &ptr->list, &ptr->count, MAXLIST, sizeof(int), xdr_int)); } CS 332

  22. type length type length value type length value value Abstract Syntax Notation One (ASN-1) • An ISO standard • Essentially the C type system • Canonical intermediate form • Tagged • Compiled or interpreted stubs • BER: Basic Encoding Rules (tag, length, value) CS 332

  23. Network Data Representation (NDR) • IntegerRep • 0 = big-endian • 1 = little-endian • CharRep • 0 = ASCII • 1 = EBCDIC • FloatRep • 0 = IEEE 754 • 1 = VAX • 2 = Cray • 3 = IBM • Defined by DCE • Essentially the C type system • Receiver-makes-right (architecture tag) • Individual data items untagged • Compiled stubs from IDL • Interface Definition Language • 4-byte architecture tag CS 332

  24. DCE • Distributed Computing Environment • A set of standards and software for building distributed systems • Defined by Open Software Foundation (OSF) • Consortium of companies that included IBM, Digital, HP • Today known as Open Group • DCE-RPC is RPC protocol at core of DCE system • Serves as underlying RPC protocol for Common Object Request Broker Architecture (CORBA) CS 332

  25. DCE-RPC • Runs on UDP • Defines two-level addressing scheme with port mapper (like SunRPC) • Supports at-most-once semantics • Client sends pings, server replies with “working” message to indicate it’s still churning on problem. • Could also respond with “nocall” message indicating it has no idea what you’re talking about • Client can send “quit” message • Server responds with “quack” (quit ACKed) CS 332

More Related