CHAPTER 12 NETWORK PROGRAMMING WITH WINDOWS SOCKETS
In this chapter, the client/server system is used as a vehicle for demonstrating
Winsock, and, in the course of modifying the server, interesting new features are
added. In particular, DLL entry points (Chapter 5) and in-process DLL servers are
used for the first time. (These new features could hav
e been incorporated in the
initial Chapter 11 version, but doing so would have di stracted from the d evelop-
ment and understanding of the basic system architecture.) Finally, additional
examples show how to create reentrant thread-safe libraries.
Winsock, because of conformance to ind
ustry standards, has naming
conventions and programming characteristics somewhat different from the
Windows functions described so far. T he W insock API is not strictly a part of Win32/
64. Winsock also provides additional functions that are not part of the standard;
these functions are used only as absolutely required. Among other advantages,
programs will be more portable to other systems.
The Winsock API was developed as an extensi on of the Berkeley Sockets API into
the Windows environment, and Winsock is supported by all Windows systems.
Winsock’s benefits include the following.
•Porting of code already written for Berkeley Sockets is straightforward.
indows systems easily integrate into TCP/IP networks, both IPv4 and the
emerging IPv6. IPv6, among other features, allows for longer IP addresses,
overcoming the 4-byte address limit of IPv4.
•Sockets can be used with Windows overlapped I/O (Chapter 14), which, among
other things, allows servers to scale when there is a large number of active cli
•Sockets can be treated as file
s for use with , ,
a nd, with some limitations, other Windows functions, just as UNIX allows
sockets to be used as file descriptors. This capability is convenient whenever
there is a need to use asynchronous I/O and I/O completion ports (Chapter 14).
•Extended, nonportable extensions are also available.
The Winsock API is supported by a DLL ( ) that can be accessed by
with your program. The DLL needs to be initialized with a
nonstandard, Winsock-specific function,
, which must be the first
Winsock function a program calls.
should be called when the pro-
gram no longer needs to use Winsock functionality. Note: The prefix
“Windows Sockets asynchronous. . . .” The asynchronous capabilities will not be
used here because threads can and will be used where asynchronous operation is
and , while always required, may be the only non-
standard functions you will use. A common practice is to use
to test the
macro (normally defined at compile time by Visual C++) so that
functions are called only if you are building on Windows. This approach
assumes, of course, that the rest of your code is platform-independent.
indicates the highest version of the Winsock DLL that you
need and can use. Version 1.1 is generally adequate and ensures the widest possi-
ble Windows interoperability. Nonetheless, Version 2.0 is ava i lable on all Windows
systems, including 9x, and is used in the examples. Versi
on 1.1 is obsolete.
The return value is nonzero if the DLL cannot support the version you wa nt.
The low byte of
specifies the major version; the high byte
specifies the minor version. The
macro is usually used; thus,
represents Version 2.0.
points to a structure that returns information on the
configuration of the DLL, including the highest version available. The Visual
Studio on-line help shows how to interpret the results.
can be used to get the error, but also
works, as does the
function developed in Chapter 2.
When a program has completed or no longer needs to use sockets, it should
so that , the sockets DLL, can free resources
allocated for this process.
Creating a Socket
Once the Winsock DLL has been initialized, you can use the standard (i.e., Berkeley
Sockets) functions to create sockets and connect for client/server or peer-to-peer
data type is a nalogous to the Windows and can
even be used with
and other Windows functions requiring a .