Remote procedure call Client/server architecture

Remote procedure call Client/server architecture

Client-server architecture Client sends a request, server replies w. a response – Interaction fits many applications – Naturally extends to distributed computing Why do people like client/server architecture? – Provides fault isolation between modules – Scalable performance (multiple servers) – Central server: Easy to manage Easy to program

Remote procedure call A remote procedure call makes a call to a remote service look like a local call – RPC makes transparent whether server is local or remote – RPC allows applications to become distributed transparently – RPC makes architecture of remote machine transparent

Developing with RPC 1. Define APIs between modules Split application based on function, ease of development, and ease of maintenance Don’t worry whether modules run locally or remotely 2. Decide what runs locally and remotely Decision may even be at run-time 3. Make APIs bullet proof Deal with partial failures

Stubs: obtaining transparency Compiler generates from API stubs for a procedure on the client and server Client stub – – – – Marshals arguments into machine-independent format Sends request to server Waits for response Unmarshals result and returns to caller Server stub – Unmarshals arguments and builds stack frame – Calls procedure – Server stub marshalls results and sends reply

RPC vs. LPC 4 properties of distributed computing that make achieving transparency difficult: – – – – Partial failures Concurrency Latency Memory access

Partial failures In local computing: – if machine fails, application fails In distributed computing: – if a machine fails, part of application fails – one cannot tell the difference between a machine failure and network failure How to make partial failures transparent to client?

Strawman solution Make remote behavior identical to local behavior: – Every partial failure results in complete failure You abort and reboot the whole system – You wait patiently until system is repaired Problems with this solution: – Many catastrophic failures – Clients block for long periods System might not be able to recover

Real solution: break transparency Possible semantics for RPC: – Exactly-once Impossible in practice – More than once: Only for idempotent operations – At most once Zero, don’t know, or once – Zero or once Transactional semantics At-most-once most practical – But different from LPC

Where RPC transparency breaks True concurrency – Clients run truely concurrently client() { if (exists(file)) if (!remove(file)) abort(“remove failed?”); } RPC latency is high – Orders of magnitude larger than LPC’s Memory access – Pointers are local to an address space

Summary: expose remoteness to client Expose RPC properties to client, since you cannot hide them – Consider: E-commerce application Application writers have to decide how to deal with partial failures

RPC implementation Stub compiler – Generates stubs for client and server – Language dependent – Compile into machine-independent format E.g., XDR – Format describes types and values RPC protocol RPC transport

RPC protocol Guarantee at-most-once semantics by tagging requests and response with a nonce RPC request header: – Request nonce – Service Identifier – Call identifier Protocol: – Client resends after time out – Server maintains table of nonces and replies

RPC transport Use reliable transport layer – Flow control – Congestion control – Reliable message transfer Combine RPC and transport protocol – Reduce number of messages RPC response can also function as acknowledgement for message transport protocol

Example: NFSv2 Old file system API used in distributed computing – – – – No current directory No file descriptors No streams (unnamed pipes) No close Inodes are named by file handles: – Opaque to client – Servers stores inode and device number Open() RPC translates names to file handles

NFS implementation Uses RPC – Marshals data structures in XDR format Pointers for directories – Generates stubs at client and server State-less protocol – Client maintains no state (No close() RPC!) – Server has no crucial runtime state File handles contain info to recover from server reboots NFS semantics: – Soft mounting: zero or more – Hard mounting: one or more

Implementation of write Semantics of writes: – Write-through (no close() RPC) What are possible outcomes after server failure: – Failed (stale file handle, I/O error) – Succeeded (NFS OK) – Don’t know (Client cannot tell!) Rename() example – Might happen multiple times

NFS RPC summary Remote service is not transparent – API is different – Failure semantics are different Not specified File systems semantics are unspecified! – Concurrency semantics awkard