Getting Ready for Windows Sockets Version 2
Martin Hall
November 1, 1995
Windows Sockets architecture
Windows Sockets—or "WinSock" as it has become known—is the open, transport-level network API standard for the Windows operating system. Designed by the WinSock Group, a coalition of independent software vendors (ISVs), Windows Sockets are now utilized by most Internet and client/server TCP/IP applications as their key to the network.
Windows Sockets version 1.1 was published in January 1993. It focused on providing a Berkeley Software Distribution (BSD) 4.3 sockets API for TCP/IP. Developers of TCP/IP and Internet applications use this as a standard programming interface to create software capable of running on any vendor's Windows-based implementation of TCP/IP. Network stack vendors providing implementations of Windows Sockets today include Microsoft, CompuServe, Novell, WRQ, FTP Software, NetManage, SunSoft, Beame & Whiteside, Wollongong, Persoft, and many more.
As remote connectivity has become more important for mobile corporate and home users, dial-up Windows Sockets implementations have become increasingly prevalent from vendors such as NETCOM, Quarterdeck, CompuServe, and Netscape.
The Windows Sockets version 2 spec
The Windows Sockets Group, which was formed in 1991, meets several times each year to refine and extend the specification and to hold interoperability testing sessions—forums in which software developers test the interoperability of their applications with vendors' Windows Sockets-enabled transports.
For the past 18 months, the Windows Sockets Group, which consists of application, network, and operating system software vendors and developers, has been working on expanding the specification to support many additional communications capabilities. The Windows Sockets version 2 provisional specifications were published several months ago, and the beta software development kit (SDK) is scheduled for availability in early December.
Today, several hundred developers contribute to the definition of the specification by means of the winsock2@mailbag.intel.com mailing list. Some of the key contributors to version 2 are Microsoft, Intel, Stardust Technologies, FTP Software, Novell, Motorola, DEC, and ICL.
As the specification process nears completion, communications software developers should start to examine the ways in which they can exploit the new features of Windows Sockets version 2. This article introduces the new features and architecture of version 2, and discusses some of the opportunities it creates for developers.
New architecture
To provide backward compatibility, the version 2 architecture includes 16-bit and 32-bit dynamic-link library (DLL) implementations of Windows Sockets version 1.1. The APIs are a superset of the previous version, which means that a simple relink is the first step in migrating from version 1.1 to version 2.
Because of the support for multiple network transports and name/service resolution mechanisms, the Windows Sockets 2 architecture has changed. As the figure at the top of this file shows, the architecture for Windows Sockets 2 divides the Windows Sockets subsystem into two general layers: the DLLs providing the Windows Sockets APIs and the service providers that plug in underneath the DLLs through the Service Provider Interface (SPI).
The Windows Sockets 2 definition includes three separate specifications: Windows Sockets 2 API definition, Windows Sockets 2 SPI definition, and the Transport Protocol-specific Annex.
The Windows Sockets 2 DLL (WS2-32.DLL) incorporates all the APIs used by application developers. This includes the existing Windows Sockets 1.1 APIs, semantically unchanged, plus new APIs for enhanced data communication facilities and generalized name service APIs.
Multiple vendors now provide concurrent access to their own transports by creating a service provider that conforms to the Windows Sockets 2 SPI definition. This means that you can develop an application that can access, for example, both TCP/IP and IPX/SPX simultaneously through the new API.
The name space SPI allows multiple name resolution services to be accessed through a uniform API. As vendors create service providers for DNS, NetWare Directory Services, and X.500, all their name resolution capabilities will be accessible through the Windows Sockets 2 name space APIs.
New functionality
New functionality in Windows Sockets 2 includes:
Advanced performance capabilities. Version 2 enables the development of very fast 32-bit client and server applications. Support for overlapped I/O cuts down on buffer transfers and CPU cycles, and provides substantial performance benefits. Used in conjunction with Win32 event objects, it provides extremely fast, multithreading-capable data transfer capabilities.
Name resolution. Many name and service resolution mechanisms are currently in place for different network protocols. In Windows Sockets 2, the protocol-independent name resolution APIs allow client and server applications to resolve these service and host names in a protocol-independent fashion. The new APIs in this category provide capabilities for services to be registered within a name space, and give a client the ability to find a particular service within the name spaces available to it.
Concurrent access to multiple network transports. Unlike version 1.1, which focused entirely on TCP/IP, the new API is transport-independent. Developers can access any network transport that has been plugged into the Windows Sockets 2 subsystem. The interface definition provides a homogeneous and comprehensive set of APIs for programming to multiple network transports concurrently. To enable esoteric, transport-specific features to be accessed though Windows Sockets, the Windows Sockets 2 Transport Protocol-specific Annex provides small sections that cover transport-specific details. TCP/IP, IPX/SPX, DECnet, and OSI are already included within Windows Sockets 2.
This facility means that developers no longer have to code a separate module for multiple transport interfaces. Instead, developers can now create and maintain a single Windows Sockets 2-based interface module in their networked Windows-based application software.
Quality of Service (QoS). Windows Sockets 2 provides access to QoS capabilities in new network media such as ATM and ISDN. Multimedia application developers can now request specific transfer rates and details of latency characteristics, and can responsively set up and tear down connections based on the throughput characteristics of the underlying network. In the wireless arena, applications can be notified when the network has become temporarily unavailable—for example, when an interface has lost contact with its base station.
Multipoint/multicast. Also new in version 2 is protocol-independent multipoint/multicast support. Applications can now use the multipoint communication method supported by a given protocol and join a multipoint group.
Stepping stones
The new specification has been designed to incorporate a series of straightforward transitional steps to its new functionality. Creating a Windows Sockets version 2 application does not require substantial effort.
The following is a suggested transition path.
Step 1. Verify the binary compatibility of your existing 16-bit and/or 32-bit Windows Sockets version 1.1 application with the new subsystem. Test it.
Step 2. Bypass the version 1.1 compatibility DLLs by relinking directly to the Windows Sockets version 2 DLL, WS2-32.DLL. Test it.
Step 3. Speed up your application by exploiting the new 32-bit performance functionality.
Step 4. Identify additional new areas that add value to or simplify your software and its architecture. Look at:
• Supporting multiple transports.
• QoS capabilities, especially if you're a multimedia software developer.
• New architectural possibilities in your code based on, for example, socket sharing capabilities.
Availability timeline
The following schedule for the availability of Windows Sockets 2 is subject to change: