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
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
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
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
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
Once it has the
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 andhtonl , 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 andntohl . 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.
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.
{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}
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
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-
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
On the other hand, I have recently been working on an application whose primary customers are mom-and-pop home healthcare companies. For this
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.