Windows Sockets
Windows Sockets specifies a programming interface that was originally based on the familiar socket interface from the University of California at Berkeley. It includes a set of extensions designed to take advantage of the message-driven nature of Microsoft Windows. Version 1.1 of the specification was released in January 1993, and version 2.2.0 was published in May of 1996.7 Windows Server 2003 supports version 2.2, commonly referred to as Winsock2.
Applications
There are many Windows Sockets applications available. A number of the utilities that ship with Windows Server 2003 are based on Windows Sockets, including the FTP and DHCP clients and servers, Telnet client, and so on. There are also higher-level programming interfaces that rely on Winsock, such as the Windows Internet API (WinInet) used by Internet Explorer.
Name and Address Resolution
Traditionally, Windows Sockets applications use the gethostbyname() function to resolve a host name to an IP address and the gethostbyaddr() function to resolve an IP address to a host name. The gethostbyname() and gethostbyaddr() functions are specific to IPv4. To accommodate the use of either IPv4 or IPv6, these functions have been deprecated in RFC 2553 and replaced by the new functions getaddrinfo() and getnameinfo(). Both getaddrinfo() and getnameinfo() are independent of whether IPv4, IPv6, or both are installed on the computer.
To allow applications to run over both IPv4 and IPv6, application developers must modify their applications to use getaddrinfo() and getnameinfo() and make other modifications. For more information about modifying applications to run over both IPv4 and IPv6, see the IPv6 Guide for Windows Sockets Applications at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/ipv6_guide_for_windows_sockets_applications_2.asp.
The gethostbyname() or getaddrinfo() functions use the following (default) name look-up sequence:
-
Check the local host name for a matching name.
-
Check the Hosts file for a matching name entry.
-
If a DNS server is configured, query it.
-
If no match is found, attempt NetBIOS name-resolution.
The gethostbyaddr() or getnameinfo() functions use the following (default) address look-up sequence:
-
Check the Hosts file for a matching address entry.
-
If a DNS server is configured, query it.
-
Send a NetBIOS Adapter Status Request to the IP address being queried. If it responds with a list of NetBIOS names registered for the adapter, parse it for the computer name.
Support for IP Multicasting
Winsock2 provides support for IP multicasting. Multicasting is described in the Windows Sockets 2.0 specification and in the IGMP section of this paper. IP multicasting is currently supported only on AF_INET and AF_INET6 sockets of the types SOCK_DGRAM and SOCK_RAW.
Winsock2 and Windows Server 2003 also support IP multicasting on SOCK_RDM sockets, which provide reliable multicast delivery using the Pragmatic General Multicast (PGM) protocol. Installing the Reliable Multicast Protocol through Network Connections enables PGM and reliable multicast support. The Reliable Multicast Protocol installs a driver, Rmcast.sys, which communicates directly with the TCP/IP protocol to provide its own transport layer. Windows XP does not include the Reliable Multicast Protocol. PGM is described in RFC 3208.
Backlog Parameter
Windows Sockets server applications generally create a socket, and then use the listen() function on it to listen for connection requests. One of the parameters passed when calling listen() is the backlog of connection requests that the application would like Windows Sockets to queue for it. This value controls the number of unaccepted connections that can be queued. Once an application accepts a connection, it is moved out of the connection request backlog and no longer counts. The Windows Sockets 1.1 specification indicates that the maximum allowable value for a backlog is 5; however, Windows NT 4.0, Windows 2000 Server, and Windows Server 2003 accept a backlog of 200. Windows XP Professional accepts a backlog of 5.
Push Bit Interpretation
By default, Windows Server 2003 TCP/IP completes a recv() call when one of the following conditions is met:
If a client application is run on a computer with a TCP/IP implementation that does not set the push bit on send operations, response delays may result. It is best to correct this on the client; however, a configuration parameter (IgnorePushBitOnReceives) was added to Afd.sys to force it to treat all arriving packets as though the push bit were set.
ConnectEx/TransmitPackets and TCP/IP
The following two functions are Microsoft-specific extensions to the Windows Sockets 2 specification:
-
The Windows Sockets ConnectEx() function establishes a connection to another socket application and optionally sends the block of data after the connection is established.
-
The Windows Sockets TransmitPackets() function transmits in memory and/or file data over a connected socket (either datagram or stream). The operating system’s cache manager is used to retrieve file data and locks memory for the minimum necessary time required to transmit it. This provides high performance and efficiency for file and memory data transfer over sockets.
Windows Sockets Direct Path for System Area Networks
The Windows Server 2003 family contains substantial performance improvements to Windows Sockets Direct (WSDP) for System Area Networks (SANs). WSD enables Windows Sockets applications written for SOCK_STREAM to obtain the performance benefits of SANs without having to make application modifications. The fundamental component of this technology is the WinSock switch that emulates TCP/IP semantics over native SAN service providers. For the Windows 2000 Server family, WSD support was only available for Windows 2000 Advanced Server and Windows 2000 Datacenter Server. WSD support is included for all members of the Windows Server 2003 family.
|
