Windows Sockets

Windows Sockets specifies a programming interface 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. Windows 2000 supports version 2.2, commonly referred to as Winsock2.


There are many Windows Sockets applications available. A number of the tools that come with Windows 2000 are based on Windows Sockets, such as the Ping and Tracert tools, FTP and DHCP clients and servers, and Telnet client. There are also higher-level programming interfaces that rely on Winsock, such as the Windows Internet API (WININET) used by Microsoft® Internet Explorer.

Name and Address Resolution

Windows Sockets applications generally use the gethostbyname( ) function to resolve a host name to an IP address. By default, the gethostbyname( ) function uses the following name lookup sequence:

  1. Check to see if the requested name matches the hosts host name.

  2. Check the hosts file for a matching name entry.

  3. If a DNS server is configured, query it.

  4. If no match is found, try the NetBIOS name resolution sequence described in "NetBIOS Over TCP/IP" later in this chapter, up until the point at which DNS resolution is attempted.

Some applications use the gethostbyaddr( ) function to resolve an IP address to a host name. The gethostbyaddr( ) call uses the following (default) sequence:

  1. Check the hosts file for a matching address entry.

  2. If a DNS server is configured, query it.

  3. Send a NetBIOS Adapter Status Request to the IP address being queried, and 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 "Internet Group Management Protocol" earlier in this chapter. IP multicasting is currently supported only on IP family datagram and raw sockets.

Backlog Parameter

Windows Sockets server applications generally create a socket and then use the listen() function on the socket to receive connection requests. One of the parameters passed when using the listen() function is the backlog of connection requests that the application would like Windows Sockets to queue for the socket. The Windows Sockets 1.1 specification indicates that the maximum allowable value for backlog is 5; however, Microsoft® Windows NT® version 3.51 accepts a backlog of up to 100, Microsoft® Windows NT® 4.0 Server and Windows 2000 Server accepts a backlog of 200, and Microsoft® Windows NT® 4.0 Workstation and Windows 2000 Professional accepts a backlog of 5 (which reduces the memory footprint).

Push Bit Interpretation

By default, Windows 2000 TCP completes a Windows Sockets recv( ) function when one of the following conditions is met:

  • Data arrives with the push bit set. The push bit is used to indicate to TCP that the data in the TCP segment and all other data in the receive buffer (that is contiguous with this TCP segment) must be passed immediately to the application.

  • The user recv( ) buffer is full.

  • 0.5 seconds have elapsed since any data has arrived.

If a client application is run on a computer with a TCP implementation that does not set the push bit on send operations, response delays might result. It is best to correct this on the client computer, however setting the the IgnorePushBitOnReceives registry entry (HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters) to 1 can be used to treat all arriving packets as though the push bit were set.