Exercise: a pair of simplified client-server sample programs

Comer textbook, Appendix 1, "A Simplified Application Programming Interface"

The client-sever model

The client-server model joins application programs in pairs so that they may communicate. The idea is that sometimes one program would benefit if another would give it something, or do some work for it. The model provides a mechanism for asking.

The worker program is called the "server," the beneficiary program the "client," and the request mechanism the "socket programming interface." The model says nothing about what the server should give the client or do for it. It only creates the framework enabling delivery-- of the request from client to server, and of fulfillment (whatever was requested) from server to client.

The distinction between different kinds of clients lies in what they trade with each other. The client might ask the server for something the server already has (a copy of an existing file). Or, something the server does not have but needs to produce on the fly (a map of current road traffic conditions). Or, a processed version of something the client first sends to the server (a current balance corresponding to a supplied bank account number). Example servers: file servers give out wholesale copies of entire disk files, mail servers supply short messages, web servers provide to-be-displayed information. But there is no distinction among them in their programming framework.

This socket programming interface is a programming architecture that is their common denominator, and gives them an identifiable, signature structural organization you can see if you glance at their source code. It is the "official" way that to code network programs. We will study it. But later. For now, in his textbook Douglas Comer introduces a simpler API that abstracts the "real" one. He calls it "a simplified API that allows a programmer to construct network applications without mastering the details of the socket interface. [It] is self-contained, and does not require an understanding of the Internet or TCP/IP." It allows us an introductory glimpse of how network applications are supposed to work, at the top of the network stack. Below, we'll take this short tour of a pair of sample programs, a client and matching server. Thereafter, we'll revert to the bottom of the network stack as we study our way in coming weeks back up to the application layer at the end of the course.

The server presented here is neither a file, mail, nor web server. Rather it's an echo server. The server's client is expected to send something to it. The client is free to send anything, there is no protocol with rules to prescribe what to send nor how (as most protocols do specify). Whatever is sent, the server then creates a copy of it and sends it to the client. The client experiences an "echo."

The general architecture these programs seek to show, representative of all clients and servers, is:

This architecture's manifest and unmistakable presence is seen in the source code of both the client and server samples, highlighted in yellow.

Exercising an echo server and echo client

In the linux GUI environment open a terminal window. In it become root user as follows:

su - 

(give root's password). Obtain the file that contains the client and server:

cd     (puts you in your home directory, which is /root)
scp public@<source machine>:/home/public/echoprograms-f15.zip .   (don't omit the final dot; it represents your "current directory", as destination))
unzip echoprograms-f15.zip

Two programs emerge into your current directory, echoserver and echoclient. You will run one (at a time), against another student or students who are running the other.

To be a server

First, determine your computer's IP address, so that you can tell it to another student who wishes to be your client. He'll need it.

ifconfig -a

and find your IP address in the output. Then, run the program as follows:

./echoserver

it will complain, demanding that you follow the rules and specify an "appnum." You need to give echoserver a number, by which it can be known to and within your computer. Give it some 4-digit number.

./echoserver 6789

but choose a distinctively arbitrary number of your own. Then tell other students what your computer's IP address number is, plus what echoserver's 4-digit application number is.

To be a client

Run the client program as follows:

./echoclient

it will complain, demanding that you follow the rules and specify both a computer name (or equivalently, IP address) plus and application number. By doing so you are "aiming" at the particular program, running in a particular machine, which is echoserver.

./echoclient <server's IP address>  <application number for "echoserver" there>

echoclient will give you a prompt, inviting you to type something. Do so then press enter. echoclient will send what you typed to the running echoserver that's at the server you specified. That echoserver will send a copy of same back to your echoclient, which will print it on the screen. Do this a few times. When you want to terminate echoclient press ctrl-C.

Switch roles. If you have been operating as a server, terminate the server (ctrl-C) and run the client, against some other student's server. And conversely.

Watch the data en route using Wireshark

Run Wireshark. Menu: Capture/Interfaces. Select the "Options" button for the interface that your computer uses to connect to the local network. In the "Capture filter:" text box type the application number of echoserver (on your machine if you are server, or on the target machine you're going to talk to if you are client) preceded by the word "port". If the appnum is 6789, type "port 6789". Press the "Start" button. Wireshark begins capturing but there is probably nothing to capture yet. Produce something to capture, by sending something to the server with echoclient if you're the client, or by asking another student to send something to you if you're the server. When that takes place, Wireshark will pick something up, probably 3 frames' worth. At that point, terminate the capture. Menu: Capture/Stop. Now look around in Wireshark at the frames you captured. Make sure to locate copies of the text that had been echoed, within the capture.