Remote procedure call Clientserver architecture Manish Kumar MSRIT

Remote procedure call Client/server architecture Manish Kumar, MSRIT Software Architecture 1

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

Remote procedure call n A remote procedure call makes a call to a remote service look like a local call q q q RPC makes transparent whether server is local or remote RPC allows applications to become distributed transparently RPC makes architecture of remote machine transparent Manish Kumar, MSRIT Software Architecture 3

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

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

RPC vs. LPC n 4 properties of distributed computing that make achieving transparency difficult: q q Partial failures Concurrency Latency Memory access Manish Kumar, MSRIT Software Architecture 6

Partial failures n In local computing: q n In distributed computing: q q n if machine fails, application fails 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? Manish Kumar, MSRIT Software Architecture 7

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

Real solution: break transparency n Possible semantics for RPC: q Exactly-once n q More than once: n q Zero, don’t know, or once Zero or once n n Only for idempotent operations At most once n q Impossible in practice Transactional semantics At-most-once most practical q But different from LPC Manish Kumar, MSRIT Software Architecture 9

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

Summary: expose remoteness to client n Expose RPC properties to client, since you cannot hide them q n Consider: E-commerce application Application writers have to decide how to deal with partial failures Manish Kumar, MSRIT Software Architecture 11

RPC implementation n Stub compiler q q q Generates stubs for client and server Language dependent Compile into machine-independent format n q n n E. g. , XDR Format describes types and values RPC protocol RPC transport Manish Kumar, MSRIT Software Architecture 12

RPC protocol n n Guarantee at-most-once semantics by tagging requests and response with a nonce RPC request header: q q q n Request nonce Service Identifier Call identifier Protocol: q q Client resends after time out Server maintains table of nonces and replies Manish Kumar, MSRIT Software Architecture 13

RPC transport n Use reliable transport layer q q q n Flow control Congestion control Reliable message transfer Combine RPC and transport protocol q Reduce number of messages n RPC response can also function as acknowledgement for message transport protocol Manish Kumar, MSRIT Software Architecture 14

Example: NFSv 2 n Old file system API used in distributed computing q q n Inodes are named by file handles: q q n No current directory No file descriptors No streams (unnamed pipes) No close Opaque to client Servers stores inode and device number Open() RPC translates names to file handles Manish Kumar, MSRIT Software Architecture 15

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

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

NFS RPC summary n Remote service is not transparent q q API is different Failure semantics are different n n q Not specified File systems semantics are unspecified! Concurrency semantics awkard Manish Kumar, MSRIT Software Architecture 18

Any Question ? ? ? Manish Kumar, MSRIT Software Architecture 19

Thank you !!! Manish Kumar, MSRIT Software Architecture 20