Chapter 12. Network Programming with Windows Sockets

Chapter 12. Network Programming with Windows Sockets Named pipes and mailslots are suitable for interprocess communication between processes on the same system or processes on machines connected by a local or wide area network. The client/server system developed in Chapter 11, starting with Program 11-2, demonstrated these capabilities. Named pipes and mailslots (more simply referred to here as "named pipes," unless the distinction is important) have the distinct drawback, however, of not being an industry standard. Therefore, programs such as those in Chapter 11 will not port easily to non-Windows systems, nor will they interoperate with non-Windows systems. This is the case even though named pipes are protocol-independent and can run over industry-standard protocols such as TCP/IP. Windows provides interoperability by supporting Windows Sockets, which are nearly the same as, and interoperable with, Berkeley Sockets, a de facto industry standard. This chapter shows how to use the Windows Sockets (or "Winsock") API by modifying Chapter 11's client/server system. The resulting system can operate over TCP/IP-based wide area networks, and the server, for instance, can accept requests from UNIX and other non-Windows clients. Readers who are familiar with Berkeley Sockets may want to proceed directly to the programming examples, where not only are sockets used but new server features are added and additional thread-safe library techniques are demonstrated. Winsock, by enabling standards-based interoperability, allows programmers to exploit higher-level protocols and applications, such as ftp, http, RPCs, and COM, all of which provide different, and higher-level, models for standard, interoperable, networked interprocess communication. 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 have been incorporated in the initial Chapter 11 version, but doing so would have distracted from the development and understanding of the basic system architecture.) Finally, additional examples show how to create reentrant thread-safe libraries. Winsock, because of conformance to industry standards, has naming conventions and programming characteristics somewhat different from the Windows functions described so far. The Winsock 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.