Client-Server Model

• Networking protocols are responsible only for data transmission
• No mechanisms for automatically starting processes
• No policies regarding who starts and who waits
• There is a need for an interaction model
• Goal:  enable 2 processes to synchronize in order to perform a cooperative computation
• One of the processes must wait for the other (server, or inetd)
• Client initiates interaction and server replies with results
• Requires 2 mandatory types of messages:
• request (client-2-server)
• reply     (server-2-client)
• Requires 2 types of system calls:
• send (dst, buf)
• recv (src, buf)
basic interaction:

    Client                          Server
                                         .
    send(request)                .
     .                                   .
     .                                  recv(request)
     wait                            process request
     .                                  send(reply)
     .                                  .
     recv(reply)                   .

Addressing:

• machine_ID:process_ID (location-dependent)
• machine_ID:port (e.g., sockets. location-dependent, process-independent)
• logical server name - location independent, but requires name server
• on recv, address may be ANY

• fully blocking send: wait until message arrived (ack.)
• blocking send (OS view): wait until message sent
• non-blocking send: copy to kernel space, wait only until copy completed (why?)
• fully non-blocking send: return immediately, interrupt when sent
• Unix Socket send:
• default: blocking with copy (if not enough buffer space, wait)
• non-blocking mode (via fcntl): return with EWOULDBLOCK, use poll or select
• blocking recv: wait until message arrived (common)
• non-blocking recv: return immediately, use select
• Unix Socket supports both modes (Java currently supports blocking only)

• To allow send before recv, message addressed to mailbox, not to process
• still, if buffer full, message might get lost

Client-Server Issues

• Conventional client-server:
• Blocking (but not fully-blocking) send, blocking and buffered recv
• Reply from server used as an ack.

• Another approach (ADA):
• fully blocking send, blocking recv
• after rendevouz, both processes know that message was received
• Also: non-fully-blocking send, non-blocking recv

 
• Stateless vs. stateful servers:
• stateless preferred
• if state is maintained, need idempotent operations

 
• Applications may involve components that are both clients and servers
• A server may need services of other servers
• A client may need to wait (act as a server)
• Care must be taken to avoid circular dependencies (deadlock)

 
• Multi-threading important for effective client-server applications (else need to use non-blocking I/O everywhere)

Remote Procedure Call (RPC)

• Client-server computing depends on I/O (sending messages)
• not natural in centralized computing, thus violates programming transparency
• Idea: allow programs to call procedures on remote machines as if they were local
• communication around procedure calls, as in centralized computing
• attempt to provide "programming transparency"
• Problems in masking distribution:
• different memory spaces
• parameter passing
• binding
• failures
• Various implementations exist:
• Xerox (as usual - first, but hardly heard of)
• Sun RPC (most widely used, used by NFS)
• ANSA
• DCE (OpenGroup)
• FireFly

Basic RPC Operation

• Calling procedure is not aware that called procedure executes remotely, and vice-versa.
• Similar to system call wrapper (e.g., read)
• put parameters on stack
• call read library function, which calls READ system call by trapping to the kernel and returns result to caller on the stack
• RPC read implemented as:
• put parameters on stack
• call client-stub of read, which packs a message and traps the kernel to send the message to server, then calls recv
• remote kernel passes message to (waiting) server-stub, which unpacks the message and puts parameters on stack, invoking server procedure normally
• when control returns to stub, packs message and sends back to client-stub, which unpacks results and returns control (and output) to caller
• Stub generation:
• an Interface Definition Language file contains RPC specification:
• program name, procedure number, version number
• procedure signatures (including in-out)
• specification of data structures, in standard representation (e.g., XDR)
• IDL compiler (e.g., RPCGEN) generates "matching" client and server stubs

Parameter Passing

• In procedure call, caller pushes parameters and return address on stack; at end, callee cleans-up and returns to caller
•  3 parameter passing methods
• call-by-value - copy of variable is passed  to stack
• to the called procedure, parameter is like a local initialized variable
• changes made in called procedure do not affect original variable
• call-by-reference - address of variable is passed to stack
• called procedure can modify contents pointed to by parameter
• call-by-copy-restore - variable copied to stack, and copied back on return


Parameter Marshalling (packing) Problems:

• different architectures
• byte-order : (solution: ntohs,ntohl, htons, htonl)
• representation of characters, floating-point, integers.
• need to specify types and size with parameters
• need to agree on canonical form (but may be inefficient)
• How to pass pointers ?
• RPC implements call-by-reference using copy-restore
• important to distinguish between in, out, and in-out parameters (why ?)
• How to pass arbitrary complex data structure ?
• server-stub dereferences pointers by calling client-stub - very  inefficient
• data structures specified in special notation and compiled by RPC compiler to generate pack/unpack code in stubs (e.g., Sun XDR)
• What about global variables ?

Dynamic Binding

 How does a client locate a server ?
• Stubs are generated from a formal specification of a server's interface:
• procedure names, signatures, in/out, version, etc.
• When server is initialized, it exports its interface by registering at a binder program with a handle (e.g., ip address and port)
• Upon a remote-procedure call, if client not-bound yet, it imports interface from binder
• Advantages:
• location independence
• can balance load
• fault tolerance
• authentication, version validation
• Disadvantage:
• costly (first lookup)
• bottleneck, single-point of failure
 

Failure Semantics

• client cannot locate the server
• similar to system calls (-1, "errno")
• more general solution is use of exceptions
• not all languages have them
• not transparent to the application programmer
• Lost request
• use timeout and retransmission
• Lost replies
• requires idempotency
• sequence numbers
• server crashes
• problem: can crash after processing of request, or before; client can't tell the difference (e.g., printer request)
• Solutions:
• at least once - retry until a reply is received (e.g., wait for reboot)
• at most once - return immediately
• client crashes
• problem: computation finished, but client crashed before return (orphan)
• solutions:
• write log record to disk, and exterminate after reboot - expensive
• Reincarnation - after reboot, broadcast new epoch