Windows* Sockets 2 Application Programming Interface An Interface for Transparent Network Programming Under Microsoft Windowstm revision 2 August 7, 1997
Download 1.64 Mb.
|
- Navigate this page:
- 5 Document Version Conventions
- 6 New And/Or Different in Version 2.2.1
- 8 Summary of New Concepts, Additions and Changes for WinSock 2
- 9 WinSock 2 Architecture
- 10 Simultaneous Access to Multiple Transport Protocols
- 11 Backwards Compatibility For WinSock 1.1 Applications
- 12 Source Code Compatibility
- 13 Binary Compatibility
4 Status of This SpecificationVersion 2.2.1 of the API specification is considered final with respect to functionality. Future revisions of this specification are contemplated only for the purpose of correcting errors or removing ambiguity, not as a means of incorporating additional functionality. This document comprises only the API portion of the Windows Sockets 2 specification. The WinSock Group’s Generic API Extensions functionality group produced the initial versions of this document as well as the Windows Sockets 2 Protocol-Specific Annex. Constructive comments and feedback on this material are always welcome and should be directed towards: David B. Andersen Intel Architecture Labs andersen@ibeam.jf.intel.com
Note that gaps in the minor revision indicator (Z) between successive releases of a document are not unusual, especially during the early stages of a document’s life when many changes are occurring. 6 New And/Or Different in Version 2.2.1Version 2.2.1 is being released primarily to correct errors and omissions from earlier versions of the specifications. 7 New And/Or Different in Version 2.2.2Version 2.2.2 is being released to add new functionality for querying and receiving notification of changes in network and system configuration. This new functionality consists of one new function (WSAProviderConfigChange()) four new socket IOCTLs (SIO_ROUTING_INTERFACE_QUERY, SIO_ROUTING_INTERFACE_CHANGE, SIO_ADDRESS_LIST_QUERY, SIO_ADDRESS_LIST_CHANGE), and two new asynchronous network events (FD_ROUTING_INTERFACE_CHANGE and FD_ADDRESS_LIST_CHANGE) reported via existing functions (WSAAsyncSelect(),WSAEventSelect(), and WSAEnumNetworkEvents()). 8 Summary of New Concepts, Additions and Changes for WinSock 2The paragraphs that follow summarize the completely new architecture for WinSock 2 and describe the major changes and additions in going from WinSock 1.1 to WinSock 2. For detailed information about how to use a specific function or feature, please refer to the appropriate API description(s) in sections 3 or 4. 9 WinSock 2 ArchitectureA number of the features incorporated into WinSock 2 required that a substantial change in architecture occur. Foremost among these is the ability of an application to access multiple different transport protocols simultaneously. Other factors included the adoption of protocol-independent name resolution facilities, provisions for layered protocols and protocol chains, and a different mechanism for WinSock service providers to offer extended, provider-specific functionality. 10 Simultaneous Access to Multiple Transport ProtocolsIn order to provide simultaneous access to multiple transport protocols, the WinSock architecture has changed in Version 2. With WinSock Version 1.1, the DLL which implements the WinSock interface is supplied by the vendor of the TCP/IP protocol stack. The interface between the WinSock DLL and the underlying stack was both unique and proprietary. WinSock 2 changes the model by defining a standard service provider interface (SPI) between the WinSock DLL and protocol stacks. This makes it possible for multiple stacks from multiple vendors to be accessed simultaneously from a single WinSock DLL. Furthermore, WinSock 2 support is not limited to TCP/IP protocol stacks as is the case for WinSock 1.1. The Windows Open System Architecture (WOSA) compliant WinSock 2 architecture is illustrated as follows: 
Figure 1 WinSock 2 Architecture Note: for simplicity’s sake the WS2_32.DLL will be referred to simply as WinSock 2 DLL. With the above architecture, it is no longer necessary (or desirable) for each stack vendor to supply their own implementation of WinSock 2 DLL, since a single WinSock 2 DLL must work across all stacks. The WinSock 2 DLL and compatibility shims should thus be viewed in the same light as an operating system component. 11 Backwards Compatibility For WinSock 1.1 ApplicationsWinSock Version 2 has been made backward compatible with WinSock Version 1.1 at 2 levels: source and binary. This facilitates maximum interoperability between WinSock apps of any version and WinSock implementations of any version, and minimizes pain and confusion for users of WinSock apps, network stacks and service providers. Note that current WinSock 1.1 compliant applications are guaranteed to run over a WinSock 2 implementation without modification of any kind as long as at least one TCP/IP service provider is properly installed. 12 Source Code CompatibilitySource code compatibility in WinSock Version 2 means that with few exceptions, all the WinSock Version 1.1 API’s are preserved in WinSock Version 2. WinSock 1.1 applications that make use of blocking hooks will need to be modified as blocking hooks are no longer supported in WinSock 2. See section 3.3.2. Winsock 1.1 Blocking routines & EINPROGRESS for more information. This means that existing WinSock 1.1 application source code can easily be moved to the WinSock 2 system at a simple level by including the new header file “winsock2.h” and performing a straightforward re-link with the appropriate WinSock 2 libraries. Application developers are encouraged to view this as merely the first step in a full transition to WinSock Version 2. This is because there are numerous ways in which a WinSock 1.1 application can be improved by exploring and using functionality that is new in WinSock Version 2. 13 Binary CompatibilityA major design goal for WinSock Version 2 was enabling existing WinSock Version 1.1 applications to work unchanged at a binary level with WinSock Version 2. Since WinSock 1.1 applications were TCP/IP-based, binary compatibility implies that TCP/IP-based WinSock 2 Transport and Name Resolution Service Providers are present in the WinSock 2 system. In order to enable WinSock Version 1.1 applications in this scenario, the WinSock Version 2 system has an additional “shim” component supplied with it: a Version 1.1 compliant WINSOCK DLL. Installation guidelines for the WinSock 2 system ensure that the introduction of the WinSock 2 components to an end user system has no negative impact on users’ existing WinSock-based applications. 
Figure 2 WinSock 1.1 Compatibility Architecture WinSock 1.1 applications currently use certain elements from the WSAData structure (obtained via a call to WSAStartup()) to obtain information about the underlying TCP/IP stack.. These include: iMaxSockets, iMaxUdpDg, and lpVendorInfo. While WinSock 2 applications will know to ignore these values (since they cannot uniformly apply to all available protocol stacks), safe values are supplied to avoid breaking WinSock 1.1 applications. Download 1.64 Mb. Share with your friends:
|