260 likes | 465 Views
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
E N D
Remote Procedure Call Outline Protocol Stack Presentation Formatting CS 332
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
Client Server Blocked Request Blocked Computing Reply Blocked RPC Timeline Fromperspective of application, semantics should be identical to local procedure call CS 332
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
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
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
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
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
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
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
SELECT Synch. Frags IP ETH Potential RPC Stack CS 332
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
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
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
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
(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
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
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
Taxonomy (cont.) • Tagged versus untagged data • Stubs • Compiled • Faster, more common • Interpreted • Flexible CS 332
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
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
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
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
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
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