Decoding a ClientServer Conversation

Decoding a Client/Server Conversation

You may be wondering what the steps are in a conversation between a client and server. Examining the exact contents of such a message exchange wouldn't do you much good. However, the following sequence presents a typical request to print a file on a network printer (and, by necessity, through a print server) from a spreadsheet program:

1. A user requests print services in the spreadsheet program by clicking the printer icon or by choosing F ile P rint. Assume that a network printer is set as the default printer for the designated print job.

2. The spreadsheet program formats the spreadsheet and then builds an appropriate print file. A print file includes the text and graphics that make up a file's content. It also includes instructions on how (bold, italic, and so forth) and where (top, bottom, left, right) to place the elements to be printed.

3. The spreadsheet program sends the print file to the printer.

4. The local networking software ( assuming it's a Windows XP redirector) recognizes that the printer is on the network and sends a print request to print that file to the print server. The redirector accesses name and network address information through a Windows networking service (called the Browse Service, which talks to a browser server on the network) to figure out where to send the print file.

5. On the server side, the listener process recognizes and checks out the user's print request. We'll assume it's legal, so the listener process creates a temporary execution thread to handle delivery of the incoming print file packets from the client. This temporary thread tells the client to start sending the print file.

6. Having now obtained permission to start shipping the file, the protocol stack on the client chops the file up into small chunks (called packets ) that are delivered to the temporary thread on the server.

7. The temporary thread on the server oversees delivery of the file and places it into a temporary holding area (called a spool file ) where the print server stores all pending print jobs. The print server places the job in the print queue , which stores the print jobs in the order in which they are received.

8. When the print job reaches the head of the queue, the server creates another temporary thread to ship the job to the printer. In many cases, a different protocol carries data from the server to the printer than the one the client uses to ship data to the server in the first place.

9. In a final (and optional) step, the print server creates another temporary thread to send a message to the client computer stating that the print job is complete. Here, the same protocol used to transport the file from the client to the server is often used to send this message back to the client.

What's worth noting here is that a kind of conversation occurs between client and server. The client initiates this conversation when it asks for permission to print, and then it sends the print job to the print server. The server takes over from there, storing the incoming print file in its spool file, managing the queue, and then printing the file when its turn comes. The conversation ends when the server sends notification of job completion to the client.

Requests for other services, such as access to a database server, an e-mail server, or even a file server, are similar to the previous interchange. In such cases, the conversation usually ends when the server sends a data table, message, or file in reply to the client's initiating requests. This request/reply sequence is really what makes modern networks work.