Previous Table of Contents Next


Hour 18
“Lots of Different People in Your Neighborhood”: In-Depth Application Troubleshooting

Sadly, most problems won’t be reported to you as “I can’t update my customer database due to insufficient file permissions” or “A network checksum error due to bad router code is making my print file garbled.” (I only wish!) Most times, in addition to the generic troubleshooting mechanisms we discussed in Part II and the initial application investigation techniques we discussed in Hour 17, “Where Do I Start?,” you’re going to have to do some specific application-level investigation.

This hour, you’re going to grab a backhoe and do some major digging in your network neighborhood to aid you in specifically determining where an application’s network problem is coming from. We’re going to talk about file and print networking, further define its difference from client/server networking, and talk about common problems and diagnostic techniques for both.

Service Definitions

There are two ways to think of the services that a workstation gets from a server:

  File and print
  Client/server

These are the topics of the next sections.

File and Print Services

When most folks think about the common ways that people network and share files, they’re thinking of file and print services. This is the typical way Windows users share a hard drive with other users and allow remote users to map a drive letter on their PCs to the hard drive on the network.

File and print services allow a user to transfer entire files over the network—and that’s it. There are no “smarts” behind the server at the other end; it cannot search a file or files for you the way Yahoo or AltaVista can. File and print networking offers a simple and basic file transfer service.

For example, all application programs that can be run from the network using file and print services require that the application files themselves be transferred to your computer’s memory.

Likewise, if you want to search the contents of a file while using file and print networking, you must load the entire file over the network and then use a program at your end to do the actual search. Sort of inefficient, huh?


Just as a point of interest—and as a confession to Geeks Anonymous—I once measured how much network traffic loading the workstation files for a version of WordPerfect caused: about 4MB. Yikes!


In truth, some file and print database programs can identify and ask for slices of files (or records), but they still need to comb through these slices—no matter how much of an index the program has—in order to find data for you.

Client/Server Computing

In contrast, client/server computing depends on the server having more intelligence than the simple ability to lump the file onto the network conveyor belt and shove it off to you. As we discussed in Hour 12, “UNIX Networking Basics,” client/server systems can answer specific pricing questions about a catalog of items, for example. Rather than shoving the catalog in your face the way a file and print server might do, a client/server system would listen politely to your inquiry about widget pricing, perform a lookup on its local database, and then send the response back to you, as illustrated in Figure 18.1.


Figure 18.1  You can think of client/server computing as two intelligent people sitting on two ends of the phone. The client is the one asking the questions, and the server is the one providing the answers.

What else can a client/server system do? Well, take your Web browser for starters. It’s the client of a client/server relationship. Your client says, “Hey, give me your default Web page,” and the server spits it out at the client. (We’ll look at this more later in the chapter.)

In addition, client/server is what you’re using to submit information to a Yahoo search. If you use X Window, thin client, or Java applications, you’re using client/server on the bottom line. Of course, the programming on the server end can be rather complex and demanding on the server. (I’m not really going to get deep into this, but it helps to know that—whatever the buzzword involved—any socket-level communication between a client and a server can be fundamentally classified as a client/server relationship.)


With that said, there are higher-level, more complex relationships that depend on client/server underpinnings. For example, you know the file and print clients you load on your workstation? The Client for Microsoft Networks and the Novell IntranetWare Client32? They obviously communicate with the server, ask it questions, and get replies. That means they’re client/server, right? Indeed they are, but they’re an important enough and complex enough method of networking that they deserve their own treatment. This stuff gets somewhat slippery, doesn’t it? Don’t worry, that’s about as weird as we’re going to get.


Previous Table of Contents Next