Network Application Interfaces

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

There are a number of ways that network applications can communicate using the TCP/IP protocol stack. Some of them, such as named pipes, go through the network redirector, which is part of the Workstation service. Many older applications were written to the NetBIOS interface, which is supported by NetBIOS over TCP/IP.

The Windows Sockets interface is the most popular API for writing Windows network applications today. A quick overview of the Windows Sockets Interface and the NetBIOS Interface is presented here.

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. 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 (https://go.microsoft.com/fwlink/?linkID=68008).

The gethostbyname() or getaddrinfo() functions use the following (default) name look-up sequence:

1. Check the local host name for a matching 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, attempt NetBIOS name-resolution.

The gethostbyaddr() or getnameinfo() functions use the following (default) address look-up 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. 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 article. 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:

• Data arrives with the PUSH bit set

• 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/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.

NetBIOS over TCP/IP

NetBIOS defines a software interface and a naming convention, not a protocol. Early versions of Microsoft networking products provided only the NetBIOS Extended User Interface (NetBEUI) protocol with a NetBIOS application-programming interface. NetBEUI is a small, fast protocol with no networking layer; thus, it is not routable and is not suitable for internetworks. NetBEUI relies on multicasts for name resolution and location of services. NetBIOS over TCP/IP provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client and server programs to the WAN, and providing interoperability with various other operating systems.

The Workstation, Server, Browser, Messenger, and NetLogon services are all (direct) NetBT clients. They use TDI (described earlier in this article) to communicate with NetBT. Windows Server 2003 also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS applications and translates them to equivalent TDI primitives.

Windows Server 2003 still uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Windows 98. However, the Windows Server 2003 redirector and server components also support direct hosting to communicate with other computers capable of direct hosting. Direct hosting uses DNS for name resolution. No NetBIOS name resolution (WINS or broadcast) is used, and the protocol is simpler. Direct hosting uses TCP port 445, instead of the NetBIOS TCP port 139.

By default, both NetBIOS and direct hosting are enabled, and both are tried in parallel when a new connection is established. The first to succeed in connecting is used for any attempt. NetBIOS support can be disabled to force all traffic to use direct hosting.

To disable NetBIOS support

1. On the Start menu, point to Control Panel, and then double-click Network Connections. Right-click Local Area Connection (or the name of your LAN connection) and then click Properties.

2. Select Internet Protocol (TCP/IP) in the list of components, and click Properties.

3. Click Advanced.

4. On the WINS tab, select Disable NetBIOS over TCP/IP.

Applications and services that depend on NetBIOS no longer function after this is done, so it is important that you verify that any clients and applications no longer need NetBIOS support before you disable it. For example, computers that cannot direct host will be unable to browse, locate, or create file and print share connections to a Windows Server 2003 computer with NetBIOS disabled.

NetBIOS Names

The NetBIOS namespace is flat, meaning that all names within the name space must be unique. NetBIOS names are 16 characters in length. Resources are identified by NetBIOS names, which are registered dynamically when computers boot, services or applications start, or users log on. Names can be registered as unique (one owner) or as group (multiple owner) names. A NetBIOS Name Query is used to locate a resource by resolving the name to an IP address.

Microsoft networking components, such as Workstation and Server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the sixteenth character of the NetBIOS name to indicate a resource type (0x00-0xFF). Many popular third-party software packages also use this character to identify and register their specific services. Table 3 lists some example NetBIOS names used by Microsoft components.

Table 3. Examples of NetBIOS names used by Windows components

To see which names a computer has registered over NetBT, type the following from a command prompt:

nbtstat -n

Windows Server 2003 allows you to re-register names with the WINS server after a computer has already been started. To do this, type the following from a command prompt:

nbtstat –RR

NetBIOS Name Registration and Resolution

Windows TCP/IP systems use several methods to locate NetBIOS resources:

• NetBIOS name cache

• NetBIOS name server

• Broadcast NetBIOS Name Query Request messages

• Static Lmhosts file

• Local host name (optional, depends on EnableDns registry parameter)

• Static Hosts file (optional, depends on EnableDns registry parameter)

• DNS servers (optional, depends on EnableDns registry parameter)

NetBIOS name resolution order depends upon the node type and system configuration. The following node types are supported:

• B-node uses broadcasts for name registration and resolution.

• P-node uses a NetBIOS name server (such as WINS) for name registration and resolution.

• M-node uses broadcasts for name registration. For name resolution, it tries broadcasts first, but switches to p-node if it receives no answer.

• H-node uses a NetBIOS name server for both registration and resolution. However, if no name server can be located, it switches to b-node. It continues to poll for a name server and switches back to p-node when one becomes available.

• Microsoft-enhanced uses the local Lmhosts file or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and/or local Hosts files) in addition to standard node types.

Microsoft ships a NetBIOS name server known as the Windows Internet Name Service (WINS). Most WINS clients are set up as H-nodes; that is, they first attempt to register and resolve names using WINS, and if that fails, they try local subnet broadcasts. Using a WINS server to locate resources is generally preferable to broadcasting for two reasons:

• Routers do not usually forward broadcasts.

• All computers on a subnet process broadcasts.

NetBIOS Name Registration and Resolution for Multihomed Computers

As previously described, NetBT binds to only one IP address per physical network interface. From the NetBT viewpoint, a computer is multihomed only if it has more than one network interface card installed. When a name registration packet is sent from a multihomed machine, it is flagged as a multihomed name registration so that it does not conflict with the same name being registered by another interface in the same computer.

If a multihomed machine receives a broadcast name query, all NetBT-interface bindings receiving the query respond with their addresses, and by default the client chooses the first response and connects to the address supplied by it. This behavior can be controlled by the RandomAdapter registry parameter described in Appendix B.

When a directed name query is sent to a WINS server, the WINS server responds with a list of all IP addresses that were registered with WINS by the multihomed computer.

Choosing the best IP address to connect to on a multihomed computer is a client function. Currently, the following algorithm is employed, in the order listed:

1. If one of the IP addresses in the name query response list is on the same logical subnet as the calling binding of NetBT on the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those that match.

2. If one of the IP addresses in the list is on the same (classless) network as the calling binding of NetBT on the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those that match.

3. If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, that address is selected. If more than one of the addresses meets the criteria, one is picked at random from those.

4. If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, an address is selected at random from the list.

This algorithm provides a reasonably good way of balancing connections to a server across multiple network adapters, and still favoring direct (same subnet) connections when they are available. When a list of IP addresses is returned, they are sorted into the best order, and NetBT attempts to ping each of the addresses in the list until one responds. NetBT then attempts a connection to that address. If no addresses respond, a connection attempt is made to the first address in the list anyway. This is tried in case there is a firewall or other device filtering ICMP traffic. Windows Server 2003 supports per interface NetBT name caching, and the nbtstat -c command displays the name cache on a per-interface basis.

NetBT Internet/DNS Enhancements and the SMB Device

It has always been possible to connect from one Windows-based computer to another using NetBT over the Internet. To do so, some means of name resolution had to be provided. Two common methods were to use the Lmhosts file or a WINS server. Several enhancements were introduced in Windows NT 4.0 and carried forward in Windows Server 2003 to eliminate these special configuration needs.

It is possible to connect to a NetBIOS over TCP/IP resource in the following ways:

• Use the command **net use \\ip address\**share_name. This eliminates the need for NetBIOS name resolution configuration.

• Use the command **net use \\FQDN\**share_name. This allows the use of a DNS to connect to a computer using its fully qualified domain name (FQDN).

Examples of using new functionality to map a drive to ftp.microsoft.com are shown here. The IP address listed here is subject to change.

• net use f: \\ftp.microsoft.com\data

• net use \\131.107.232.1\data

• net view \\131.107.232.1

• dir \\ftp.microsoft.com\bussys\winnt

In addition, various applications, such as the Event Viewer Select Computer option on the Log menu, allow you to enter an FQDN or IP address directly. In Windows Server 2003, it is also possible to use direct hosting to establish redirector or server connections between computers running Windows Server 2003 without the use of the NetBIOS namespace or mapping layer at all. By default, Windows attempts to make connections using both methods so that it can support connections to lower-level computers. However, in Windows XP and Windows Server 2003–only environments, you can disable NetBIOS completely for each network connection in Network Connections.

The interface in Windows Server 2003 that makes NetBIOS-less operation possible is termed the Server Message Block (SMB) device. It appears to the redirector and server as another interface, much as an individual network adapter/protocol stack combination does. At the TCP/IP stack however, the SMB device is bound to ADDR_ANY, and it uses the DNS namespace natively, like a Windows Sockets application. Calls placed on the SMB device will result in a standard DNS lookup to resolve the (DNS) name to an IP address, followed by a single outbound connection request (even on a multihomed computer) using the best source IP address and interface as determined by the route table. Additionally, there is no NetBIOS session setup on top of the TCP connection, as there is with traditional NetBIOS over TCP/IP. By default, the redirector places calls on both the NetBIOS device(s) and the SMB device, and the file server receives calls on both. The file server SMB device listens on TCP port 445 instead of the traditional NetBIOS over TCP port 139.

NetBIOS over TCP Sessions

NetBIOS sessions are established between two names. For example, when a Windows XP Professional-based workstation makes a file-sharing connection to a server using NetBIOS over TCP/IP, the following sequence of events takes place:

1. The NetBIOS name for the server is resolved to an IP address.

2. The next-hop address for the IP address of the server is resolved to a MAC address.

3. A TCP connection is established from the workstation to the server, using port 139.

4. The workstation sends a NetBIOS Session Request to the server name over the TCP connection. If the server is listening on that name, it responds affirmatively, and a session is established.

When the NetBIOS session has been established, the workstation and server negotiate which level of the SMB protocol to use. Microsoft networking uses only one NetBIOS session between two names at any time. Any additional file or print sharing connections are multiplexed over the same NetBIOS session using identifiers within the SMB header.

NetBIOS keep-alives are used on each connection to verify that both the server and workstation are still able to maintain their session. Therefore, if a workstation is shut down ungracefully, the server eventually cleans up the connection and associated resources, and vice versa. NetBIOS keep-alives are controlled by the SessionKeepAlive registry parameter and default to once per hour.

If Lmhosts files are used and an entry is misspelled, it is possible to attempt to connect to a server using the correct IP address but an incorrect name. In this case, a TCP connection is still established to the server. However, the server rejects the NetBIOS session request (using the wrong name), because there is no listen posted on that name. An Error 51, “Remote computer not listening,” is returned.

NetBIOS Datagram Services

Datagrams are sent from one NetBIOS name to another over UDP port 138. The datagram service provides the ability to send a message to a unique name or to a group name. Group names may resolve to a list of IP addresses or a broadcast. For example, the command **net send /d:**mydomain test sends a datagram containing the text “test” to the group name mydomain[03]. The mydomain[03] name resolves to an IP subnet broadcast, so the datagram is sent with the following characteristics:

• Destination MAC address: broadcast (0xFF-FF-FF-FF-FF-FF).

• Source MAC address: The MAC address of the sending interface.

• Destination IP address: The local subnet broadcast address.

• Source IP address: The IP address of the local computer.

• Destination name: mydomain[03] (the messenger service on the remote computers).

• Source name: username[03] (the messenger service on the local computer).

All hosts on the subnet pick up the datagram and process it, at least to the UDP protocol. On hosts that are running a NetBIOS datagram service, UDP hands the datagram to NetBT on port 138. NetBT checks the destination name to see if any application has posted a datagram receive on it and if so, passes the datagram up. If no receive is posted, the datagram is discarded.

If support for NetBIOS is disabled in Windows Server 2003 (as described earlier in this section), NetBIOS datagram services are not available.