1
play

1 Digression: local procedure calls Digression: local procedure - PDF document

Aug 28, 2023 •226 likes •315 views

Problems with sockets Sockets interface is straightforward [ connect] read/ write [ disconnect] Forces read/ write mechanism Remote Procedure Calls Not how we generally program We usually use a procedure call To make

  1. Problems with sockets Sockets interface is straightforward – [ connect] – read/ write – [ disconnect] Forces read/ write mechanism Remote Procedure Calls – Not how we generally program – We usually use a procedure call To make distributed computing look more like centralized: – I/ O is not the way to go Paul Krzyzanowski • Distributed Systems RPC Digression: local procedure calls 1984: Birrell & Nelson j = f( i, “ mystring ”, 7); – Mechanism to call procedures on other call by value local vars machines – Process on machine A can call procedure call by reference i=999 on machine B SP • A is suspended call by value • Execution continues on B • When B returns, control passed back to A Rem ote Procedure Call 55441122 mystring Goal: it should appear to the programmer that a Code & normal call is taking place Static data Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Digression: local procedure calls Digression: local procedure calls j = f( i, “ mystring ”, 7); j = f( i, “ mystring ”, 7); local vars local vars 1. Prepare for call: 2. Call: i=999 put params on stack i=999 call f SP 7 7 55441122 55441122 999 999 Return addr SP SP SP mystring mystring 55441122 55441122 Code & Code & Static data Static data Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems 1

  2. Digression: local procedure calls Digression: local procedure calls j = f( i, “ mystring ”, 7); j = f( i, “ mystring ”, 7); local vars local vars 3. On entry to f: 4. Prepare to return: i=999 i=999 adjust SP to - return value in 7 7 allocate space for register 55441122 55441122 locals - adjust SP 999 999 Return addr Return addr SP - return SP f :local vars SP SP 55441122 mystring 55441122 mystring Code & Code & Static data Static data Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Digression: local procedure calls Implementing RPC No architectural support for remote j = f( i, “ mystring ”, 7); procedure calls local vars Simulate it with tools we have 5. Return: (local procedure calls) i=999 caller cleans up SP parameters Simulation makes RPC a language-level construct SP instead of an operating system construct 55441122 mystring Code & Static data Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Implementing RPC Stub functions 1. Client calls stub (params on stack) The trick: client functions server functions Create stub functions to make it appear to the user that the call is local server stub Stub function contains the function’s interface client stub (skeleton) network routines network routines client server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems 2

  3. Stub functions Stub functions 2. Stub marshals params to net message 3. Network message sent to server client functions server functions client functions server functions server stub server stub client stub client stub (skeleton) (skeleton) network routines network routines network routines network routines client server client server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Stub functions Stub functions 4. Receive message: send to stub 5. Unmarshal parameters, call server func client functions server functions client functions server functions server stub server stub client stub client stub (skeleton) (skeleton) network routines network routines network routines network routines client server client server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Stub functions Stub functions 6. Return from server function 7. Marshal return value and send message client functions server functions client functions server functions server stub server stub client stub client stub (skeleton) (skeleton) network routines network routines network routines network routines client server client server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems 3

  4. Stub functions Stub functions 8. Transfer message over network 9. Receive message: direct to stub client functions server functions client functions server functions server stub server stub client stub client stub (skeleton) (skeleton) network routines network routines network routines network routines client server client server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Stub functions Benefits 10. Unmarshal return, return to client code • Procedure call interface client functions server functions • Writing applications simplified – RPC hides all network code into stub functions server stub client stub – Application programmers don’t have to (skeleton) worry about details • Sockets, port numbers, byte ordering network routines network routines • RPC: presentation layer in OSI model client server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Parameter passing Pass by value – Easy: just copy data to network message Pass by reference RPC has issues – Makes no sense without shared memory Paul Krzyzanowski • Distributed Systems 4

  5. Pass by reference? Representing data 1. Copy items referenced to message buffer No such thing as 2. Ship them over incom patibility problem s on local 3. Unmarshal data at server system 4. Pass local pointer to server stub function 5. Send new values back Remote machine may have: – Different byte ordering To support complex structures – Different sizes of integers and other types – Copy structure into pointerless representation – Different floating point representations – Transmit – Different character sets – Reconstruct structure with local pointers – Alignment requirements on server Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Representing data Representing data IP (headers) forced all to use big endian byte Need standard encoding to enable ordering for 16 and 32 bit values communication between heterogeneous – Most significant byte in low memory systems • Sparc, 680x0, MIPS, G5 – e.g. Sun’s RPC uses XDR (eXternal Data • x86/ Pentiums use little endian Representation) main() { Output on a Pentium: unsigned int n; 44, 33, 22, 11 char *a = (char *)&n; Output on a G4: n = 0x11223344; 11, 22, 33, 44 printf("%02x, %02x, %02x, %02x\n", a[0], a[1], a[2], a[3]); } Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Representing data Where to bind? I m plicit typing Need to locate host and correct server process – only values are transmitted, not data types or parameter info – e.g., Sun XDR Explicit typing – Type is transmitted with each value – e.g., ISO’s ASN.1, XML Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems 5

  6. Where to bind? – Solution 1 Where to bind? – Solution 2 • Require client to know which host it Maintain centralized DB that can locate a host that provides a particular service needs to contact (Birrell & Nelson’s 1984 proposal) • A server on that host maintains a DB of • Server sends message to central locally provided services authority stating its willingness to accept certain remote procedure calls • Solution 1 is problematic for Sun NFS – (and sends port number) identical file servers serve different file systems • Clients then contact this authority when they need to locate a service Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems Transport protocol When things go wrong Which one? • Local procedure calls do not fail – If they core dump, entire process dies • More opportunities for error with RPC: • Some implementations may offer only one (e.g. TCP) – Server could generate error – Problems in network – Server crash • Most support several – Client might disappear while server is still – Allow programmer (or end user) to choose. executing code for it • Transparency breaks here – Applications should be prepared to deal with RPC failure Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems When things go wrong RPC semantics • Semantics of remote procedure calls • Most RPC systems will offer either: – Local procedure call: exactly once – at least once semantics – or at m ost once semantics • Exactly once may be difficult to achieve with RPC • A remote procedure call may be called: • Understand application: – 0 times: server crashed or server process – idem potent functions: may be run any died before executing server code number of times without harm – 1 time: everything worked well – non-idem potent functions: side-effects – 1 or more: excess latency or lost reply from server and client retransmission Paul Krzyzanowski • Distributed Systems Paul Krzyzanowski • Distributed Systems 6

Recommend

More recommend