Lecture notes for CS 537, Client-Server Interfaces

Lecture Notes for CS 537

Low-level client-server transport is hard.
- The syntax is primitive.
  - The Sockets communication model and API.
- The semantics is primitive.
  - Reliability (TCP) vs. message delivery (UDP).
  - Proper operation at the boundaries.
  - Even finding the boundaries is hard.
Client-server protocol design is hard
- You have to start from scratch every time.
- You have to deal with some hard problems.

When the going gets tough, the smart start abstracting.
- What kind of toolkit can I build?
What client-server features are amenable to abstraction?
- What things remain the same across client-server applications?
Request-response transport is mostly boilerplate.
- The only things that really change are the messages involved.
Client-server communication is also stylized.
- The client requests and waits;
  the server replies;
  the client continues.

Requests and replies are messages, discrete, fixed-format data units.
- The exact details don't matter, as long as both sides agree.
Request-reply communication is a lot like calling a subroutine.
- The request is the call, the reply is the return.

The remote procedure call (RPC) abstraction combinations the client-server transport and communication abstractions.
- See Birrell and Nelson, Implementing Remote Procedure Calls, in ACM Transactions on Computer Systems, February 1984.
The RPC abstraction hides the transport and turns communication into procedure calls.
Pile on enough abstraction and you get middleware.
The remote procedure call is a key abstraction for middleware.
- The basis for implementing publish-subscribe and callbacks.

RPC exploits the procedure call-return model.
- The model is familiar, understood, and useful.
The key is the procedure implementation-interface separation.
- The caller needs the interface, not the implementation.
elements - single threaded, argument passing, value return
Division into pieces can be delayed until late in the design.

The subroutine call-return model extends easily to client-server computing.
- Request-reply maps naturally to call and return.
- Client-server maps naturally to caller and called.
The subroutine call-return model is embedded in a transport protocol.
- Only the specific payloads are left to the application designer.
- Almost.
  - There's error semantics, data semantics and infrastructure issues.

A natural and easy way to extend non-communicating programs.
- Just write the program, then send the called procedures elsewhere.
- A late design decision.
- Not good for distributed programs, though (too much synchrony).
A simple and natural extension to most programming languages.
- And to most programmers too.
- But extending a language for RPC isn't easy.
End-to-end language independence.
- Clients and servers need not be in the same language.

RPC communication is asymmetric.
- The caller and the called.
- Reciprocal RPC servers help here.
  - But the asymmetry extends to the software structure.
RPC communication is synchronous.
- No-reply RPC calls are expensive.
The extension isn't quite natural.
- Differences in data behavior, error semantics.
Losing control over low-level issues.
- The abstraction trade-off.

Defined by Sun in rfc 1057 and rfc 1831.
- Other RPC systems include OSF DCE (Microsoft COM-DOM), Java RMI.
The remote program is the server.
- Similar to non-static file scope in c-c++.
- The remote procedures are externally visible.
- Static global data is shared in the server.
- The server can be concurrent or not.

Remote programs are identified by 32-bit unsigned numbers.
- Assigned by some authority; sun, local management, ad-hoc.
Each remote procedure is numbered from 1 by the RPC software.
RPC assigns version numbers to remote programs.

Choice of UDP or TCP.
RPC reliability under UDP.
- Timeout retransmission with retry limits.
- Timeouts don't provide semantically meaningful reliability.
Weak communication semantics under UDP.
- An error cannot be interpreted.
- No error results in at least one call.
- Idempotent operations and repeated executions.
- Exactly one semantics is expensive and hard.

A client has host id and a RPC server id, and needs a port number.
The RPC port mapper is a per-host server to resolve server information.
- The port mapper is called RPCbind these days.
RPC servers allocate a port and register with the local port mapper.
- Registered information includes program number, protocol port number, version.
Clients query the remote port mapper for the protocol port number.

This page last modified on 20 March 2003.