Servers Deliver Services

In the preceding section, you found out that clients ask for services and that servers provide them. What handling requests on the server side really means is that a special bit of software, called a listener process , runs continuously on the server and listens for requests for a particular service. When a request arrives, the listener process handles it as quickly as possible.

Servers thread through a maze of requests

What usually happens on most server operating systems including Windows Server 2003 is that the listener process simply recognizes that a request has arrived. The listener process checks the identity and the associated permissions of the client, and if the client is who it says it is and has the correct permissions for the service, the listener process grants the request for service. It does so by starting a temporary process (called an execution thread in Windows-speak; think of this as a very small program) that exists just long enough to handle whatever service the client requests after which, the temporary process disappears. For example, a request for a particular file on a server would result in the creation of a temporary process that exists just long enough to copy the requested file across the network. As soon as the copy completes, the temporary process goes poof!

Using a listener process to create short-lived execution threads allows a server to handle large numbers of requests, because the listener process never stays busy for long handling individual requests. As soon as the listener process creates a thread to handle one request, it checks for other pending requests and handles them if necessary; otherwise , the listener process goes back to listening for new incoming requests. Typically, a server has one or more listener processes for each service that the server supports.

KEY CONCEPT 

Servers are demand-driven. That is, their job is to respond to requests for services from clients. A server rarely initiates activity. This reactive mode of server operation helps explain why the client/server model is also known as a request/response or a request/reply architecture, in which clients make requests and servers respond or reply to them.

Other than the necessary listener processes and a set of service applications that actually perform services, servers need the same hardware components that clients do. Servers need one or more NICs with a working connection to the network to allow data to enter and leave the server.

Software is similar on the server side

On the software side, servers also need the following elements so that their services can be available across the network:

• Network drivers enable the server to communicate with its NIC. This software lurks in the background and exists only to tie the computer to the NIC.

• Protocol stacks send and receive messages across the network. This software also lurks in the background and provides a common language shared with clients used to ferry information across the network.

• Service applications respond to requests for service and formulate replies to those requests. This software runs in the foreground and does the useful work. The service application includes the listener process, the temporary execution threads, and some type of configuration or management console so that it can be installed, configured, and altered as needed. Typical service applications include directory services (Active Directory), database engines (SQL Server or Oracle), and e-mail servers (Exchange).

REMEMBER 

Most, if not all, software that resides on a server is network aware because delivering information across a network is a server's primary function.