When it comes to bedrock, ubiquitous PC networking terms, few are as ubiquitous as client and server. Client or server can refer to either a piece of software (e.g., Windows Server 2008, Windows Vista) or to hardware (e.g., the PCs that run those or other OSs), but in general, it’s the software definition that’s the more important of the two.
A server is a piece of software that is network-aware and that provides some sort of function. Clients are their partners—pieces of software that are also network-aware and that know how to ask for and utilize the output of those functions. The oldest example in Microsoft networking is probably the file-server software, which allows a system (the server) to share one or more folders of its local hard drives with a file-server client, a piece of software that lets a computer connect over a network to a file server and use those shared folders as if they were locally attached hard disks. Client and server software exists as pairs of software that implement some protocol, which is just a set of communication rules. For example, Microsoft’s file-server software wouldn’t be of much value without a file-server client, so Microsoft provides both of those routines in almost all of their OSs. Some networking protocols, such as Microsoft’s file-server service, are vendor-specific, but that’s slowly dying out. For example, whenever you surf the Web, you start up a Web browser—either Microsoft Internet Explorer (IE) or the open-source world’s Mozilla Firefox—and communicate with a Web server that might be running Microsoft’s Internet Information Server (IIS) Web server software, or perhaps the open-source world’s Apache software, and only a close examination of the network packets between your browser and the Web server would allow you to tell the difference.
Examples of the most essential client/server systems include email systems, Web servers, DNS servers (which let us refer to servers by English-like names rather than less-friendly numerical addresses), file- and print-sharing systems, and their cousins, the so-called peer-to-peer file-sharing networks used to—ahem—“share” movies and music.
All networking happens as client-server interaction, and as a result you’ll notice the same characteristics of every file/server interaction. First, the client initiates all conversations, and the server responds. That’s interesting because it lets most Internet-connected systems get a bit of protection from malware through the simplest firewall imaginable: the network address translating (NAT) router. In short, a NAT router acts as a sort of firewall by blocking all incoming communications from the Internet to your PC except for the ones that are responses to client requests from your computer.
Second, clients have to somehow find servers, a notion called client-server rendezvous, and there are many ways to accomplish that. When you try to connect your Windows box to a file server in your organization, you must know the name of the file server holding the data that you want. You find your data either by simply knowing the server’s name or by searching for the data in Active Directory (AD). On the Internet, you use a search engine to find Web servers with information that interests you. When you first start up your PC, it needs an IP address from something called a DHCP server, and it finds one by simply broadcasting to all within earshot, “Is there a DHCP server in the house?”
Third, client/server systems work only because they agree on a set of rules for communication. Most client/server systems have a well-defined language that clients can use to make requests and that servers can use to respond. For example, the just-mentioned DHCP server and its client follow a well defined four-step dance to supply the client with an IP address. Clients and servers must agree also on whether they’ll use UDP or TCP, and what port numbers to employ. DHCP clients talk to servers by directing their communications to UDP’s port 67 on a DHCP server, and the server responds to the client on the client’s UDP port 68.
But you might be saying, “Wait, what about those peer-to-peer networks? Aren’t those an example of network communication without clients or servers?” No, it just means that every participant in the communication acts as both client and server, as needed. They’re sort of like the slipper shells found on most Atlantic beaches that, when alive, alternate gender between male and female as needed.
Anyone wanting to become adept in troubleshooting a network service must first understand how to set up and configure the client and server pieces of a service, that service’s client-server rendezvous approach, and the inter-network underpinnings of that service. In fact, that’s how to attack almost any network problem, in a nutshell!
