Client/Server Computing

The expression client-server has become one of the biggest buzzwords of the 90's...

The basic idea:


Reasons For Client Server

Many opinions exist as to why client/server computing is attracting so much interest. The following seem important to your lecturerÉ

More Definitions


Middle-Ware

A moderately mis-used term, in general this means any software which eases the integration of desktop systems with traditional big-iron database applications. For example: A key phrase in middle-ware is the API (Application Programming Interface) which it provides: programmers can "write to the API" regardless of the final OS on which the software will run, or the DBMS with which it will interact.

Communications Architecture

As stated previously, the LAN is the underlying basis of client/server.

Atop the LAN, two communications models are common:

Connection-oriented
the comms subsystem guarantees reliable transfer, and messages are sent and received as Òencoded byte streamsÓ. This is the type of service provided by TCP in the Internet protocol architecture. Most other network architectures have an equivalent transport layer service.
Remote Procedure Calls
this is an alternative way of thinking about the transport layer (or, more correctly, the session layer!) as a means of data transfer.

TCP-based Client/Server

Recall that in TCP, the terms client and server already have well-defined meanings. This makes discussion of client/server computing somewhat problematic in this context :-)

A typical TCP-based client/server system relies on a database "front end" on the server system, which acts as a TCP server process, accepting connections from client systems at some port number. Some interesting aspects of this include:

Nevertheless, such connection-oriented systems are very popular for client/server.

Remote Procedure Calls in TCP/IP

The Internet standard RPC system was developed by Sun Microsystems as part of their NFS (Network File System) specification. Other architectures may provide an RPC system, but the Internet RPC is now pretty well standard.

RPC is based on the conventional programmer's view that a procedure call contains the name of the procedure, and a parameter string, thus:

call thatProc(x, y, z);
This call does not return until the procedure has completed execution. The return value(s) are read from the parameter string upon return.

A key problem is the representation of parameters. If the client and server are not identical machines running identical software, then internal representations may be different. In Sun RPC, this is solved by running every RPC call/return through the XDR (eXternal Data Representation) libraries.

Note that XDR is another approach to the problem that ASN.1/BER also solves.


Other Client/Server Applications

Whilst the majority of "real world" (ie, commercial) applications of client/server are in database applications, there are some other nice examples on the Internet:
This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #20.
Phil Scott