Can We Talk? How Clients and Servers Communicate

In addition to configuration, in most cases actually using a service requires communication between the client and the server. Clients and servers talk in a number of ways. Some of these ways are fairly complex and probably deserve a book all their own. I've listed several books in the annotated bibliography that cover Distributed COM (DCOM) and Remote Procedure Calls (RPC). A book that I wrote several years ago, Win32 Client/Server Developer's Guide (Addison-Wesley Publishing, 1996), still has reasonable coverage of RPC. Client/server interaction is not this book's main topic, but in this chapter I provide an overview of two of the simpler, most common protocols.

TCP/IP (WinSock)

Transmission Control Protocol/Internet Protocol (TCP/IP) is one of the most commonly used protocols today. Of course, TCP/IP is the protocol that fuels the Internet. Anyone reading this book is likely to use TCP/IP every daychecking e-mail, browsing Web pages, or chatting by using one of the many competing chat programs. Much of this interaction takes place transparently to us as users of the software. We load the browser, it establishes a connection, either through a LAN or a dial-up connection probably using RAS, and we do what we need to do.

Behind the scenes, however, a lot more goes on. When Microsoft Windows programmers talk about TCP/IP, they probably mean Windows Sockets, or WinSock. WinSock is a Windows-specific extension to Berkeley Sockets, developed in the early 1980s on the UNIX operating system. The idea behind sockets is simple: There are two endpoints, or sockets. One socket is the server, which is presumed to be always available. The other socket is the client, which intermittently transfers data to and from the server. Of course, the model is not always this simple. For instance, Hospital Level 7 (HL-7) is a common high-level, industry-specific protocol that uses TCP/IP as its underlying protocol. HL-7 is used in the healthcare industry to transfer standardized ASCII records from one system to another. Strictly speaking, it often appears that one of the systems is the client and the other is the server. In reality, each party to an HL-7 interaction isfrom a TCP/IP standpointboth client and server.

In the early 16-bit Windows days, WinSock was not part of the operating system. Competing TCP/IP "stacks" were used to allow Windows 3.x clients and MS-DOS clients to participate with the primarily UNIX computers that used TCP/IP sockets. In the early 1990s, several organizations got together to set the standards for what eventually became WinSock. Their goal was to create a standard that would allow applications written to the WinSock specifications to work on all WinSock implementations . They specified a binary standard that allowed any WinSock application to work with any WinSock implementation.

Extensions to the standard sockets interface in early versions of WinSock were primarily designed to address the weaknesses in the 16-bit Windows multitasking model. As I said in Chapter 2, 16-bit Windows used a cooperative multitasking model. This meant that applications had to agree to give up control periodically to allow the operating system to run other applications. Many sockets operations are typically blocking, meaning that they will wait for an operation to complete or time out. Blocking was not acceptable within a cooperative multitasking model. This gave rise to many asynchronous functions in WinSock: the function calls would return before the actual operation requested completed. In general, these asynchronous functions are much less important within the Win32 preemptive multitasking model.

Once it has the name of a server, how does a program connect to the right service? Every server that supports TCP/IP has a large number of socket numbers available. For instance, socket 80 is used for HTTP communication. Socket 80 is an example of what we call a well-known service. If a Web browser is looking to connect to a Web server, the browser knows to use socket 80. Similarly, a Telnet client will use socket 23. All socket numbers below 1024 are reserved for well-known services.

NOTE

---

Port numbers are one of the elements that can require byte-order swapping. Byte swapping is required because internally, some computers place the bytes that make up a number in different orders. Several WinSock functions support byte swapping. These include htons and htonl , which convert a short number and a long number, respectively, from host order to network order. To convert a short and a long from network to host order you would use ntohs and ntohl . Because we will be working with Windows Intel clients and servers, we won't need to do byte swapping. If we needed to support other clients who needed to do byte swapping, both client and server would be required to use these conversion functions.

Named Pipes

The other major contender in the client/server communication arena is named pipes. Named pipes also has a long history. It is sometimes known as FIFOs because of its first in, first out nature. Anonymous pipes are lighter weight but somewhat less useful pipes that rely on the passing of a handle to a child process. One limitation of named pipes is that the server must be a Windows 2000 or a Windows NT machine. A Windows 9x machine can act as a named pipes client but cannot act as a named pipes server.

Once created, a named pipe handle can be passed to most functions that expect a file handle, such as WriteFile and ReadFile . Named pipes instances are named in a specific format, \\Server\Pipes\PipeName. A named pipe named TEST on my machine, which is named DUAL , would be known as \\DUAL\Pipes\TEST. The name is used to identify the pipe on the network. This combination of server name and pipe name performs the same function as the server name and socket number in TCP/IP.

There are two important things to remember about named pipes. First, named pipes can work with the client and server on the same machinejust like TCP/IP. Unlike TCP/IP, named pipes communication on the same machine seems to have some speed advantages. Second, there is a security- related problem using named pipes within services running under the System account. Named pipes is an authenticated protocol, so Windows 2000 and Windows NT by default do not allow named pipes to connect to a service running under the System account. There are several Knowledge Base articles about this issue. Later in this chapter we will add the required registry changes to the service framework first introduced in Chapter 3.

WinSock or Named Pipes?

The choice of communication protocol depends upon the type of organization that will use the application. For instance, I have created applications for large organizations with extensive investment in TCP/IP-based networks. Each organization has a naming service in place, such as Windows Internet Naming Service (WINS) or Domain Name System (DNS). For all practical purposes, this naming service is a requirement of implementing a TCP/IP solution. These organizations are ideal candidates for a WinSock-based system.

On the other hand, I have recently been working on an application whose primary customers are mom-and-pop home healthcare companies. For this sort of environment, a named pipes solution is easier to implement. It requires nothing beyond whatever protocols are currently running on the network. In the best of all worlds , it would be useful to conveniently postpone the decision of whether to support WinSock or named pipes so the customer can decide. Later in this chapter I will discuss several alternatives to make protocol independent communication happen on the client side.

These two protocols have a couple more characteristics that can drive your decision. Named pipes let you set the number of connections that will be allowed. This can be useful in maintaining a level of service for the allowed number of active clients, although you end up with clients that cannot connect when the server is busy. Also, it is relatively easy to impersonate the client on the other end of the named pipe, allowing a server-based application to easily control a client's access to server resources.

On the other hand, WinSock will more easily allow a server-based application to interact with all types of clients. Any significant platform will allow a connection using TCP/IP, the default underlying protocol for WinSock.