Fundamental Types Of Connectivity Architectures

There are three basic relationships between communicators on a network. Each type has its own specific performance and implementation characteristics. Connectivity Architectures are:

• Client-Server Architecture
  Client machine accessing data and programs on a Server machine
• Host-To-Terminal Architecture
  Terminal device providing a screen and keyboard to a Host machine
  X-Windows Terminal Protocol – a unique blend
• Peer-To-Peer Architecture
  Two similar machines operating in harmony as Peers on the network

The Client/Server relationship

The essence of a Client is the fact that it is running an application program. The program could be a word processor, database, or some custom application. The client is doing real processing ‘work’. For example, the word processor is reformatting a paragraph or checking spelling. The database is comparing a zip code to the zip codes in each of several thousand customer name records to select everyone in zip code 94301. The client is doing real processing work. The server is providing resources to the client. The most common resource to provide is simple disk service. The client is accessing data that is physically present on a remote file server. The ‘service’ that is provided is the management of the disk drive including the disk directory, file allocation table, and file read/write capabilities. In our database example, the client reads a single customer record from the server and compares zip codes in the record. It then continues, reading one record at a time from the server. The server ‘serves’, the client processes.

Let’s construct a more sophisticated ‘server’. Instead of simply reading and writing file data, let’s make this server smart enough to perform a search operation on the data. In this case, the workload is more ‘shared’ between the client and the server. The client program accepts data from the user. The client program now sends a zip code and a request to ‘search’ to the server. The server performs the search in its own memory and returns only the matching records to the client.

Here is a significant aspect of Client/Server communications. The predominant type of information being exchanged between the communicators is a set of commands and replies. Data is written to a disk is accompanied by a ‘write’ command. The client makes a ‘read’ request and the data being read is returned along with a ‘read reply’ indication.

CLIENT/SERVER = Commands and replies exchanged

The Terminal/Host relationship

In a Terminal/Host relationship, the processing work is occurring on the Host and the video display is managed by the Terminal. The terminal device doesn’t do any application processing; it simply displays the screen from the Host and accepts keystrokes from the user to be sent to the application that is running on the host machine.

In this case, the host-based word processor reformats the paragraph (in memory on the host machine) and redraws the video display on the terminal device in its reformatted structure. The database application runs on the host and only the characters of text are exchanged between the two machines.

The predominant information exchanged between communicators in a Terminal/Host conversation is character-oriented. Processing is done on the Host, characters are input from and displayed at the Terminal.

TERMINAL/HOST = Character-oriented information exchanged

Management Of Application Screens: A Different Type Of Client/Server

Suppose that a client/server conversation is set up between a client application and a server component. In this case, the server is going to perform processing on a video display. The ‘commands’ sent to the server will be things like ‘Move Cursor Up One Line’, or, perhaps, ‘Position The Cursor At Line 12, Column 18’. The server keeps a virtual copy of the ‘screen’ in memory so that it knows that a ‘Move Cursor Down One Line’ command received when the cursor is on Line 12, Column 18 results in the cursor now being positioned at Line 13 (one line down), and Column 18. The work performed by this ‘server’ is the management of the application program screen.

The ‘client’ component is this example is simply responsible for displaying the screen (that is managed by the ‘server’). This makes for a really simplistic ‘client’ program. It’s essentially a terminal device. The application program (the word processor or database) is running in the same machine as the ‘server’ program for the screen. The ‘client’ is simply a terminal program. The Telnet Server serves a single screen to the client. The Telnet Server software resides on the host computer, along with the application program. The Telnet Client resides on the user’s machine to display the screen and accept characters from the keyboard.

This is how the Telnet and RLOGIN programs operate in the world of TCP/IP protocols. Many UNIX-based boxes make use of Telnet client/server // host/terminal communications. As far as you and I are concerned, Telnet implements a terminal-to-host conversation. As far as the programmer writing the Telnet code is concerned, there is a Telnet client talking to a Telnet Server.

The predominant information exchanged in a Telnet conversation is CHARACTER-ORIENTED. At the beginning of the conversation the Client and Server do exchange some setup commands. The conversation is a Terminal-To-Host interaction but at the program level the connection itself is between a Client and a Server process. Only the programmer writing the Telnet (or RLOGIN, or other similar type) code need be aware of this relationship. To us, Telnet is a simple Host/Terminal conversation.

The SERVER component of a Telnet conversation resides in the HOST, along with the application program.

The CLIENT component of a Telnet conversation resides in the USER’S MACHINE, doing nothing except displaying the screen and accepting characters from the keyboard for transmission to the ‘host’.

X-Windows: A Unique Blend Of Client/Server and Host/Terminal

An oddity arises in the implementation of the X-Windows host-to-terminal protocol. X-Windows is implemented as a client and server to provide a graphic user interface for the user. In this environment, however, the ‘server’ component of the conversation resides on the users’ machine and not on the central host computer. The application program is running on the host. When the application wants to update the users’ window (which may be one of many windows on the users’ machine) it makes its request of a local ‘client’ program (running in the host). The client component then sends the request to the ‘server’ component (running on the users’ machine). The X-Server performs the appropriate update to the users’ screen. The reason for the ‘server’ being on the users’ machine is that it, in effect, ‘serves’ the multiple windows to (potentially) many different applications running on the host.

The predominant information exchanged between the X-Server and the X-Client consists of window and pointer device control commands along with character oriented information. Although a ‘X’ conversation does represent the essence of a Terminal-to-Host architecture (because the application is not running on the users machine; it’s running on the host) the frames of information exchanged between the processes are mostly commands and replies.

X-Windows doesn’t fit neatly into the Client/Server or Host/Terminal model. It truly has significant aspects of both types of interaction.

We refer to an X-Windows environment as being HOST/TERMINAL. The user is sitting at an X-Terminal and the host is running X-Windows. The Client/Server relationship is, as with Telnet, relegated to the world of the programmer.

The Peer-to-Peer Relationship

When two machines are communicating as equal partners we say they are in a Peer-to-Peer relationship. A true Peer-to-Peer relationship is hard to find. A true peer-to-peer relationship implies two processes (programs) that are exchanging data equally. For example, consider a pair of database programs that are working together to sort a large database. One program sorting half the data while the other program is sorting the other half. When the A-M program detects a data record that belongs to the N-Z program it sends it across the network for processing. When the N-Z program detects a data record that should be processed by the A-M program, that record, too, is sent across the network. The two database programs are doing similar work and they can exchange data with each other. They are peers. Neither one is a server and neither one is a client. The two programs have functionality that looks like both client and server.

The true peer-to-peer program relationship is almost non-existent in the real-world. The most common implementation of the peer-to-peer architecture is that involving peer machines as opposed to peer programs. When my computer shares files with the network and, at the same time, my computer uses files shared by other computers then I am both a client (of the other computers) and a server (to the other computers). If a network is built from this type of ‘dual client and server’ machines then we say we have a ‘peer-to-peer network’. The computers are peers, not the programs. Apple Macintosh computers are classic peer-to-peer machines. An Apple Mac can share its files and it can use other people’s files. The Windows For Workgroups / Windows 95 / and Windows-NT environments all implement peer-to-peer relationships. My Win95 machine is sharing it’s disk with an NT-client. The NT-client is sharing its disk with my Win95 machine. We are both clients are we are both servers. I am serving to my client and my client is serving to me. We are ‘peers’. The Apple and Windows peer-to-peer implementations are common real-world examples of the use of the term ‘peer-to-peer’.

In a true peer-to-peer implementation we would see blocks of data being passed between the processes. In the peer-to-peer machine architecture, we see what effectively amounts to a pair of client/server conversations working together. My client component is sending commands and receiving replies from your server component. Your client component is sending commands and receiving replies from your server component. We are implemented as a pair of back-to-back clients and servers. Any analysis of our interaction must be broken down into a one-way analysis of my client talking to your server, and vice-versa.