Support functions in the tdi.sys library, along with definitions developers include in their drivers, make up TDI. This interface essentially provides a convention for the way network requests format into IRPs. In addition, TDI provides a means whereby a TDI client can register callbacks (i.e., functions that are directly invoked) with TDI Servers. For example, when a TDI Server receives data from across the network, it can invoke a registered-client-receive callback. This event-based callback feature of TDI eliminates some of the overhead associated with allocating and distributing IRPs, and clients can take advantage of the feature to achieve high performance.
As I hinted earlier, a network API might be able to use only certain protocols. For example, the Workstation and Server services do not know how to use TCP/IP. However, these services understand the NetBIOS interface, and NT provides a driver named netbt.sys that implements a TDI-compliant NetBIOS programming API on top of the TCP/IP driver. Thus, the Workstation and Server service can use either NetBEUI or NetBIOS over TCP/IP. Fortunately, all of NT's programming APIs can use either NetBEUI or TCP/IP directly or indirectly, achieving maximum flexibility on Windows networks.
NDIS Drivers
When a protocol driver wants to read or write messages formatted in its protocols' format from or to the network, the driver must do so using a NIC, which Microsoft calls a network adapter card (NAC). Because expecting protocol drivers to understand the nuances of every NIC on the market (proprietary NICs number in the thousands) is not feasible, NIC vendors provide device drivers that can take network messages and transmit them via the vendors' proprietary hardware. In 1989, Microsoft and 3Com jointly developed the network driver interface specification (NDIS), which lets protocol drivers communicate with NIC drivers in a device-independent manner. NIC drivers that conform to NDIS are called NDIS drivers or NDIS Miniport drivers.
On NT, the ndis.sys library implements the NDIS boundary that exists between TDI Servers (typically) and NDIS drivers. As is tdi.sys, ndis.sys is a helper library that NDIS driver clients use to format IRPs they send to NDIS drivers. NDIS drivers interface with the library to receive requests and send back responses.
One of Microsoft's goals for its network architecture was to let NIC vendors easily develop NDIS drivers and take a driver code and move it between Windows 9x and NT. Thus, instead of merely providing the NDIS boundary helper routines, ndis.sys provides NDIS drivers an entire execution environment. NDIS drivers aren't genuine NT drivers because they can't function without the encapsulation ndis.sys gives them. This insulation layer wraps NDIS drivers so thoroughly that NDIS drivers do not accept and process IRPs. Rather, ndis.sys receives IRPs from TDI Servers and translates the IRPs into calls into the NDIS driver. NDIS drivers also do not have to worry about reentrancy, in which ndis.sys invokes an NDIS driver with a new request before the driver has finished servicing a previous request. Exemption from reentrancy means NDIS driver writers do not need to worry about complex synchronization, which is made even more tricky because of the parallel execution possible on a multiprocessor.
Although ndis.sys's serialization of NDIS drivers simplifies development, serialization can hamper multiprocessor scalability. Standard NDIS 4 drivers (the NT 4.0 version of ndis.sys) do not scale well for certain operations on multiprocessors. Microsoft gave developers a deserialized operation option in NDIS 5, which will ship with Win2K. NDIS 5 drivers can indicate to ndis.sys that they do not want to be serialized; ndis.sys will then forward requests to the driver as fast as it receives the IRPs that describe the requests. Responsibility for queuing and managing multiple simultaneous requests falls upon the NDIS driver, but deserialization confers the benefit of higher multiprocessor performance. Microsoft debuted deserialization in the version of ndis.sys that ships with NT 4.0 Service Pack 4 (SP4), although the company has not publicly revealed this fact.
The NDIS model also supports hybrid TDI-NDIS drivers, called NDIS Intermediate drivers. These drivers lie between TDI Servers and NDIS drivers. To an NDIS driver, an NDIS Intermediate driver looks like a TDI Server; to a TDI Server, an NDIS Intermediate driver looks like an NDIS driver. Microsoft publicly introduced NDIS Intermediate drivers in NT 4.0 as a way for developers to write packet capture drivers. NDIS Intermediate drivers can see all network traffic taking place on a system because the drivers lie between protocol drivers and network drivers. Developers base software that provides fault-tolerant and load-balancing options for NICs on NDIS Intermediate drivers.
NDIS 5.0 introduces a new type of NDIS driver—a connection-oriented NDIS driver. Support for connection-oriented network hardware (e.g., ATM switches) is therefore native in Win2K, which makes connection management an establishment standard in NT's network architecture. Connection-oriented NDIS drivers use many of the same APIs that standard NDIS drivers use; however, connection-oriented NDIS drivers send packets through hardware network connections, rather than placing them on the network medium.
The interfaces that ndis.sys provides for NDIS drivers to interface with NIC hardware are available via functions that translate directly to corresponding functions in NT's Hardware Abstraction Layer (HAL). The HAL is a hardware-dependent library that computer vendors can supply to interface NT with proprietary motherboards with a standard API set and exposed hardware model.
Figure 3 illustrates a complete network driver stack. In Figure 3, you can see how Winsock components fit with the TCP/IP protocol and an NDIS driver. (The figure does not show the I/O Manager and HAL).
Binding
The final piece in the NT networking architecture puzzle is the way in which the components at the various layers—network API layer, TDI Server layer, NDIS driver layer—locate one another. The name of the process that connects the layers is binding. You've witnessed binding taking place if you've changed your network configuration by adding or removing a component with the Network applet.
When you install a networking component, you must supply an information (.inf) file for the component. This file includes directions NT must follow to install and configure the component, including binding dependencies or binding relationships. A developer can specify binding dependencies for a proprietary component so that the NT Service Control Manager will not only load the component in the correct order but will load the component only if other components the proprietary component depends on are present on the system. Binding relationships, which the bind engine determines with the aid of additional information in a component's .inf file, establish connections between components at the various layers. The connections specify which components a network component on one layer can use on the layer beneath it.
For example, the Workstation service (RDR) will automatically bind to the NBF (NetBEUI) and NetBIOS over TCP/IP (NetBT) protocols if both protocols are present on the system. The order of the binding, which you can examine on the Bindings tab on the Network properties page (as Screen 1 shows), determines the priority of the binding. When RDR receives a request to access a remote file, RDR submits the request to both protocol drivers simultaneously. When the response comes, RDR waits until it has also received responses from any higher-priority protocol drivers. Only then will RDR return the result to the caller. Thus, reordering bindings so that bindings of high priority are also the most performance-efficient (or applicable to most of the computers in your network) can be advantageous. You can also manually remove bindings with the binding editor.
The Bind value, in the Linkage subkey of a network component's Registry configuration key, stores binding information for that component. For example, if you examine HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\LanmanWorkstation\Linkage\Bind, you'll see the binding information for the Workstation service.
The Evolving Network
NT's network architecture provides a flexible infrastructure for network APIs, network protocol drivers, and NIC drivers. NT architecture takes advantage of I/O layering to give NT networking support the extensibility to evolve as computer networking evolves. When new protocols appear, developers can write a TDI Server to implement the protocol on NT. Similarly, new APIs can interface to NT's existing protocol drivers. Even less-major enhancements, such as the addition of support for connection-oriented hardware in Win2K, demonstrate that the NT networking model is flexible enough to keep pace with changing networking demands. You can learn more about NT's networking internals in the Microsoft Windows NT Server 4.0 Resource Kit's Networking Guide and the Windows NT Device Driver Kit.