Communication Primitives

Message passing
Communication primitives send(destination-process, message) receive(source-process, message) blocking vs. non-blocking primitives a message is copied at least three times: sender (user buffer -1-> kernel buffer) -2-> receiver(kernel buffer -3-> user buffer) non-blocking - faster, harder to code, riskier, requires additional OS support o send - return as soon as message copied to kernel buffer o receive - provide a (user) buffer for message to be copied to and return blocking - safer, easier to think about, slower o unreliable - block until message is sent/received o reliable - receipt is confirmed by acknowledgement, block until ack is sent/received

message passing model communication primitives o blocking vs. non-blocking o synchronous vs. asynchronous o direct vs. indirect remote procedure calls motivation overview binding parameter and result passing stub generation execution semantics

Message passing (cont.)

Direct vs. indirect communication

synchronous vs. asynchronous primitives synchronous (also called randezvous) send blocks until receive executes on receiving computer - safer, easier, less concurrent asynchronous -multiple sends can be executed before receives (messages buffered) - more dangerous (what to do with messages to crashed receiver?), complex, concurrent

Direct communication explicitly name the process youre communicating with o send(destination-process, message) o receive(source-process, message)

Link is associated with exactly two processes o Between any two processes, there exists at most one link o The link may be unidirectional, but is usually bidirectional

Indirect communication communicate using mailboxes (ports) (usually) owned by receiver o send(mailbox, message) o receive(mailbox, message)

Link is associated with two or more processes that share a mailbox o Between any two processes, there may be a number of links o The link may be either unidirectional or bidirectional

Why is message-passing not ideal?

Remote Procedure Call (RPC)

Disadvantages of client-server communication via message passing:

RPC mechanism:

Hides message-passing I/O from the programmer Looks (almost) like a procedure call but client invokes a procedure on a server

Message passing is I/O oriented, rather than request/result oriented Programmer has to explicitly code all synchronization Programmer may have to code format conversion, flow control, and error control

RPC invocation (high-level view):

Calling process (client) is suspended Parameters of procedure are passed across network to called process (server) Server executes procedure Return parameters are sent back across network Calling process resumes

Goal heterogeneity support different machines, different OSs

Portability applications should be trivially portable to machines of other vendors Interoperability clients will always get same service, regardless of how vendor has implemented that service OS should handle data conversion between different types of machines

Invented by Birrell & Nelson at Xerox PARC, described in February 1984 ACM Transactions on Computer Systems

Remote Procedure Call (RPC)

I/O protection

Each RPC invocation by a client process calls a client stub, which builds a message and sends it to a server stub

pack call parameters client client stub return unpack results

kernel

unpack parameters call server stub server

To prevent illegal I/O, or simultaneous I/O requests from multiple processes, the OS typically performs all I/O via privileged instructions

pack return results

kernel

User programs must make a system call to the OS to perform I/O

When user process makes a system call:

The server stub uses the message to generate a local procedure call to the server

network

A trap (software-generated interrupt) occurs, which causes: o The appropriate trap handler to be invoked using the trap vector o Kernel mode to be set The trap handler: o Saves process state o Performs requested I/O (if appropriate) o Restores state, sets user mode, and returns to calling program

If the local procedure call returns a value, the server stub builds a message and sends it to the client stub, which receives it and returns the result(s) to the client

RPC Invocation (more detailed)

Binding
Binding = determining the server and remote procedure to call Static binding addresses of servers are hardwired (e.g., Ethernet number)

1. Client app. procedure calls the client stub 2. Client stub packs parameters into message and traps to the kernel 3. Kernel sends message(s) to remote kernel 4. Remote kernel passes message(s) to server stub 5. Server stub unpacks parameters and calls server app. procedure 6. Server app. executes procedure and returns results to server stub 7. Server stub packs result(s) in message(s) and traps to kernel 8. Remote kernel sends message(s) to local kernel 9. Local kernel passes message(s) to client stub 10. Client stub unpacks result(s) and returns them to client app.

Inflexible if a server changes location Poor if there are multiple copies of a server

Dynamic binding dynamically assign server names

Broadcast a where is the server? message, wait for response from server Use a binding server (binder) o Servers register / deregister their services with the binding server o When a client calls a remote procedure for the first time, it queries the binding server for a registered server to call

Parameter and result passing

nr_hits = query(key, 10, result); int query (int key, int number, tuple values) { return (num_hits); } unmarshal

Parameter passing (cont.)

Handle different internal representations ASCII vs. EBCDIC vs. 1s comp. vs. 2s comp. vs. floating-point Little endian vs. big endian Establish a canonical (standard) form? What types of passing are supported? Remote procedure cant access global variables must pass all necessary data Call-by-value (procedure gets a copy of data) pass parameters in message Call-by-reference (procedure gets a pointer to data) o Cant do call-by-reference o Do call-by-copy / restore instead Instead of pointer, pass item pointed to Procedure modifies it, then pass it back o Inconsistency if client doesnt block

marshal

network int query (int key, int number, tuple values) { return (num_hits); } marshal

nr_hits = query(key, 10, result);

unmarshal

network

Generating stubs

C and C++ may not be descriptive enough to allow stubs to be generated automatically
typedef struct { double item1; int item2; char *annotation; } tuple; char add(int key, tuple value); char remove(int key, tuple value); int query(int key, int number, tuple values[ ]);

Error handling, semantics

Which are in, in-out, and out parameters? Exactly what size are parameters (e.g., integers, arrays)? What does it mean to pass a pointer?

long to specify boolean add ( inerface db Using OSFs DCE Interface Definition Language (IDL) query ( [in] long key, [in] long key, { procedure { [in] long number, [in] tuple value typedef struct signatures for stub generation: [out, size_is(number)] ); double item1; tuple values[ ] long item2; ); boolean remove ( [string, ptr] [in] long key, ISO_LATIN_1 [in] tuple value *annotation; ); } tuple;

RPC call may fail due to computer or communications failure what to do if RPC call fails? three execution semantics at least once o if call succeeds at least one execution of remote procedure happened o if fails none, partial, multiple executions exactly once o if succeeds exactly once o if fails none, partial, one at most onceo if succeeds exactly once o if fails - none

Stateful vs. stateless server

Stateful server server maintains state information for each client for each file

Connection-oriented (open file, read / write file, close file) Enables server optimizations like read-ahead (prefetching) and file locking Difficult to recover state after a crash

Stateless server server does not maintain state information for each client

Each request is self-contained (file, position, access) o Connectionless (open and close are implied) If server crashes, client can simply keep retransmitting requests until it recovers No server optimizations like above File operations must be idempotent